Skip to main content
Version: v2

Offer launch checklist and examples

Offer campaigns pay for verified events. A saved draft is not ready for delivery, and a click or client screen is not proof that a reward was earned. Work through the four Campaign Studio steps, then validate tracking and review status.

Example A: verified signup​

Campaign Studio decisionExample configurationWhy it matters
OutcomeVerified signup, web platformA registration page view alone must not approve a reward.
Destinationhttps://advertiser.example/join?rr_click_id={click_id}The server stores the resolved click ID with the registration.
User-facing task“Create an account and verify your email”The requirement must match what the advertiser verifies.
GoalTracking event ID signup_verified, goal type eventThe postback uses this exact stable goal_id.
FinanceGross revenue and publisher payout in USD, payout no higher than revenueCheck the displayed values and total campaign budget.
EligibilitySupported countries, web traffic, compatible offer surfacesInventory must match both campaign and publisher slot policy.
TrackingCustom S2S credential and campaign callback endpointOnly the advertiser server sends the signed outcome.

The advertiser should send a pending callback only if manual verification is still underway, then send approved or rejected for the same transaction and goal. For an immediately verified signup, send the approved outcome according to your tracking setup. Keep the transaction ID stable across retries.

Example B: install plus tutorial​

Create two independently verified goals, for example install_verified and tutorial_complete. Make the tutorial depend on the install goal if completing it first would be invalid. Give each goal its own user-facing description, gross revenue, publisher payout, event mapping, completion window, and pending period. Estimate the maximum possible campaign cost assuming an eligible user completes both goals; check the total budget, daily and monthly conversion caps, and per-user limit accordingly. A tracking provider or advertiser server must verify the install; the store URL and app open alone do not create a reward.

Launch gates​

  1. Step 1 — outcome and property: Confirm owner, structure, objective, platform, public URL, and package or property ID. Validate the advertised asset. A template supplies starter values that you must review.
  2. Step 2 — user experience: Match title, CTA, description, completion requirements, instructions, disclosure, and support URL to the actual action. Check the offer on a small screen. Attach validated creative tied to the asset. Production creative provisioning currently has a limitation.
  3. Step 3 — reward and money: Give every goal a unique tracking event ID. Review gross revenue, publisher payout, dependencies, availability windows, pending time, completion deadline, budget, and caps.
  4. Step 4 — delivery and security: Select countries, offer surfaces, compatible traffic, dates, device or browser rules, attribution window, and tracking partner. Keep advanced filters broad enough for eligible users. Configure the Custom S2S credential and an IP allowlist only if your callback egress IPs are stable.
  5. Development test: Open a real test launch in a matching country and platform. Record its click ID, complete the task, and send a signed callback with a stable transaction ID. Inspect the response, postback log, conversion state, and reward. Test a retry with the same ID; it must not create another reward. Test an invalid goal or signature and a user who should not be eligible.
  6. Review and live: Save the draft, resolve every item in Readiness, submit for review, and verify approval. Only LIVE campaigns can enter eligible publisher feeds. Check reporting once live and pause quickly if destination, creative, payout, or verification is wrong.

The in-memory Test custom S2S control only verifies local credential handling; it reports no external delivery or accounting writes. It does not replace the development click and callback test. See the tracking guide and offer API reference.

When a revision is needed​

Editing produces a new draft revision that needs review again. Recheck asset and creative validity, goal IDs, payout, budget, destination macro, callback credential, and eligible surfaces. Historical clicks retain the financial terms captured with their revision; keep a mapping of campaign revision to your own order and event records.