Run a campaign

Start one campaign

1. Sign in with the configured account service. Local operators may use the explicit local credential; that is a testing path, not public email signup.
2. Create an organization if your account has no workspace.
3. Open Campaigns and create an offer. Give it a name, one qualifying event, reward amount, total budget, and per-referrer cap.
4. Write the offer and rules: eligibility, what counts, review conditions, and an owner contact route.
5. Open the campaign's public offer and check it before inviting participants.
6. Have a participant join, share their link, and refer another participant. Record the real qualifying action, then inspect its reward in Reward review.

Creating a campaign records its rules. It does not purchase a subscription, load a cash balance, or send a payment. Treat local test accounts and rewards as test data.

Define audience and qualification

The qualifying event is a stable name such as signup or purchase. It is chosen when creating a campaign. A later campaign edit does not change that event or retroactively change the base reward.

Record an action only after checking it happened in your product. The event form asks for the participant and a unique source reference. Use the same reference when retrying an action so a duplicate does not create another reward.

Optional audience assessments use three explicit owner fields: target audience, product or campaign offer, and content review policy. Describe these separately. A provider assessment cannot replace the published qualifying rule.

A profile assessment is not evidence that a purchase happened. Avoid sensitive targeting or promising that an assessment proves someone's identity, finances, or future behavior.

Create, pause, and end

Use the campaign detail page to edit its name, rules, audience fields, budget, and cap. The service validates changes against existing commitments. Do not reduce a cap or budget and assume that already reviewed obligations disappear.

Scheduled starts, automatic campaign dates, and advanced lifecycle automation are not controls in this beta.

Understand first attribution and direct rewards

A participant's first campaign join fixes attribution. A valid referral code links that join to its direct referrer. Joining again with another code does not move credit. A public code is for attribution, not sign-in.

Do not promise cross-device matching, a tracking cookie window, or automatic credit when someone joins without the code. The beta attributes an authenticated join carrying the code; it does not infer credit from clicks or browser history.

The implemented ledger records a direct referral reward. The two-level and influence-weighted examples describe future product options; they are not silently applied to real rewards.

Know what determines the amount

The current campaign specifies a fixed direct referral amount in USD cents. An attributed participant completing the campaign's qualifying action can create one pending reward for the direct referrer. The same qualifying event must not create duplicate rewards.

The sample formula on the landing page—base reward, audience weight, conversion estimate, and a bonus—is illustrative. A missing AI assessment does not become an invented score or change the implemented fixed reward.

Approval checks the campaign budget and per-referrer cap and reserves the amount. A held or rejected reward is not paid. Provider transfer and bank settlement are separate evidence boundaries; approving a ledger item alone never moves money.

Use evidence without overclaiming

Participants may consent to collection of a public Bluesky profile and recent public posts. This uses a supplied handle and does not verify account ownership. Private-network OAuth connections are not automatically available.

Audience assessment needs both collection consent and separate AI consent, fresh usable evidence, and a configured assessment service. Review the source, observation time, missing posts, judgement, and confidence. An unsupported or unavailable service remains unavailable.

The owner can request an assessment from the campaign detail page when the service is configured. Your audience, offer, and content policy provide its campaign context. An estimate can help review; it cannot prove a qualifying action, justify an unexplained hold, or decide someone's worth.

Weight sliders, rank badges, and the forecast card on the landing page remain samples. No assessment should be invented to fill an empty UI.

Forecast only when outcomes support it

A forecast estimates future captures, conversion, or value using completed campaign outcomes. A new campaign lacks that evidence. The beta reports unavailable forecasting rather than pretending that a public profile alone produces a calibrated campaign prediction.

“4.2 captures in 30 days” is an expected count over a time window, not a score out of 100 or a promise of four referrals. Percentiles describe uncertainty and require supported provider output; the landing-page band is illustrative.

Keep forecasts separate from observed conversions. A forecast is an association learned from available outcomes, not proof that a person's profile caused a result. Do not use a predicted fraud probability as an automatic rejection rule.

Review rewards and record reasons

1. Open Reward review and identify the campaign, participant, event, and amount.
2. Check the qualifying evidence and campaign rules.
3. Choose approve, hold, or reject and write a specific reason.
4. For a hold, state what needs checking. A shared network or model warning alone is not a complete explanation.
5. Read any participant appeal and review the reward again when appropriate.

An appeal records the participant's explanation on their held or rejected reward. It does not automatically reverse a decision or promise a response deadline. Paid records require provider evidence and cannot be turned into a fictional unpaid review item.

Example reason: “Purchase reference X does not yet show a completed payment; review after confirmation.” Avoid unexplained labels such as “fraud” when you have not established the issue.

Separate budgets, plan limits, and cash

The campaign budget limits approved reward commitments. The per-referrer cap limits what one referrer can receive from that campaign. Neither is a bank account balance. Owner subscription allowances limit new campaign participants per calendar month; annual billing does not turn those allowances into yearly totals.

Annual billing is the default and costs ten monthly payments for twelve months. There is no free hosted entry plan. More than 100,000 new participants per month requires a custom quote. Proposed overage is $2.03 per extra 1,000, subject to approval and live billing support.

Do not infer spike insurance, automatic allowance increases, or approved overage from an illustration. The service must show the applicable configuration and actual subscription evidence before live charges.

Use the workspace and check integrations

The web workspace provides an overview, campaigns, participants, qualifying-event recording, reward review, billing, and settings. The desktop client uses the same service; UI availability and a compiled client are separate from a proven device installation.

Settings reports account, assessment, subscription, and payout availability. Local operator access is explicit and does not fabricate a paid plan. Local participant invitations are one-use test sign-in links; no email is sent.

Configured checkout opens the payment provider and shows the annual amount before authorization. A return URL is not payment proof. Subscription state and invoices use verified provider records; cancellation ends renewal at the end of the purchased period and does not invent a refund.

CRM, commerce, automation, team invitations, SSO, advanced graphs, automatic payout setup, and support messaging need additional supported integrations. Do not promise them from the proposed plan table.

Measure actions and explain decisions

Track joins, attributed referrals, qualifying actions, pending rewards, approved amounts, holds, and provider-confirmed payments separately. These describe different steps. A large signup count does not establish quality, revenue, or completed settlement.

Start with one unambiguous qualifying event and verify its duplicate behavior. Review a small campaign's evidence before changing the offer. Editing the next campaign's rules is safer than silently changing a commitment already made.

The local service records real campaign relationships and review states. Landing-page cascade motion, K-factor, reach, and whale alerts are simulations, not measurements of your account.

Prepare a real participant launch

• Publish the owner's identity and a working contact route in the offer.
• State eligibility, qualification, review, budget, caps, payout timing, and applicable terms.
• Configure real account sign-in; keep local test invitations local.
• Publish operator privacy details, retention, relevant rights, and contact information. The local privacy notice identifies unresolved publication details.
• Verify a complete join, share, qualifying action, review, and reload with separate accounts.
• Verify payment-provider setup, subscription webhooks, destination requirements, and settlement evidence before promising payments.
• Keep provider outages and missing evidence visible. Do not replace them with sample data.

Use the campaign owner's published contact route for offer questions. The beta has no live support inbox or guaranteed response deadline. Cap recording integration is deferred.