Building campaigns

A campaign defines your referral offer end to end: what counts as a successful referral, what each side earns, and how the invite experience looks. This guide walks through the Campaigns section of the dashboard. For the underlying model, see Campaigns.

Start from a template or recipe

Creating a campaign never starts from a blank rule builder. Pick one of two entry points:

• Templates — four built-in starting points, each pre-filling a valid qualification gate and a sensible default reward configuration:

  Template	Referral validates when the referred user…
  Signup	Creates an account
  Signup + verification	Creates an account and verifies their email or phone
  Paid subscription	Starts a paid subscription (pairs with RevenueCat, Adapty, or Stripe Billing events)
  Custom	Completes any combination of events and gates you define

• Referral Gallery recipes — every recipe in the Referral Gallery has a Use this recipe button that pre-fills a complete campaign in your dashboard: qualification gate, reward configuration, and page copy, ready to customize. Templates and recipes use the same prefill mechanism — one is in-product, the other is public.

The qualification gate builder

The gate builder is where you define what counts as a referral — no JSON to write and no schema to learn. You add one condition per event you want to require, and configure each in place:

• Event pickers are populated from events Invitebase has actually seen from your app (per mode) — you select real event names, not free-text guesses. You can also pre-register event names before instrumentation ships.
• Required or optional — mark each condition required (all required conditions must be met) or optional (any one optional condition suffices), so a single gate can express both "all of these" and "any of these" logic.
• Target — set a number the condition must reach. If the event carries a value or count, those sum toward the target across occurrences; otherwise each occurrence counts as one, so a target of 3 means "happened at least 3 times."
• Property restriction — narrow a condition to events matching the properties that matter, e.g. only subscription_started where plan is paid.
• Qualification window — how long the referred user has to qualify before the referral expires.

A "Paid subscription within 14 days" gate is one required condition on subscription_started, restricted to plan: paid, with a 14-day window.

Invalid conditions — an unknown event, a missing target — are flagged inline before save, so a gate never fails at evaluation time. Per-condition progress against a live gate is visible on the referral (gate_progress) in the dashboard and on the API.

Score-based qualification

Instead of (or alongside) boolean gates, you can assign point values to tracked actions — add a profile picture = 2 points, complete a workout = 8 — and validate when the referred user's total crosses a threshold. The action catalog lists every event type your app has tracked; assign points, set the threshold, mark any steps as mandatory, and cap how much any single event type can contribute.

Test the rule before saving

The builder includes a live rule tester: pick a sample user (a seeded test participant or any real test-mode user) and see pass/fail per gate for the current draft, updating as you edit. For deeper step-by-step evaluation — matched events, actual vs required property values, window state — use the rule inspector.

Eligibility and grace period

Two settings next to the gate builder decide the edge cases of who can enter the funnel at all:

• Eligibility — whether the referred user can qualify in the first place, checked before the gates run: restrict qualification to new users only or allow returning users, set how old an existing account can be and still count as "new," and choose whether users with prior paid-subscription history qualify. Ineligible referrals are rejected before validation — never billed, never counted toward a referrer's totals.
• Grace period — how long after signup a late code still attributes (24 or 48 hours is the common choice). This rescues the friend who installs, signs up, and only then remembers the code — the referral is attributed as if the code had been present at signup. Longer forgives more honest mistakes but widens the window for existing-user abuse, so keep it in hours or a couple of days, not weeks.

Choose your rewards walks through picking these values.

Reward configuration

The reward step defines what each side earns when a referral reaches validated — rewards never fire on merely linked referrals. See Rewards and payouts for the model.

• Method — app grants (free access for any number of days, weeks, or months; or an in-app unlock), money rewards (gift cards, and cash rails via the prefunded balance), or manual fulfillment (tier-triggered rewards a human delivers, like swag — Invitebase detects the tier and tracks fulfillment state).
• Sided-ness — single-sided or double-sided, with independent config per side (referrer and referee).
• Amounts and currency — fixed value per validated referral.
• Milestones and tiers — "after 5 referrals, unlock X"; tier crossings can trigger manual-fulfillment rewards and owner alerts.
• Caps — maximum rewards per referrer, per campaign, and per rolling month. Caps are also a structural fraud control.
• Expiry — how long an earned reward stays claimable.

Copy and appearance

The Appearance step themes every end-user surface from one place: the refr.link offer page, the in-app invite screen, the referrer status page, and notification email templates. One theming model (logo, colors, typography accents) is shared across surfaces, with per-surface copy overrides — headline, offer copy, share text, email subject lines.

Every surface has a live preview as you edit, and defaults derive from your app icon and campaign config so surfaces look right with zero editing. Appearance changes have their own draft/published state, and publishing is versioned and audit-logged.

Draft, test, go live

Campaigns move through a deliberate lifecycle:

1. Draft — the campaign exists but attributes no referrals. Build gates and rewards freely.
2. Test — activate the campaign in test mode. Use the event simulator to walk a synthetic referral through clicked → signed_up → in_progress → validated → reward and confirm your webhook receiver handles the lifecycle.
3. Live — activate in live mode. Real referrals start being attributed immediately.

From the campaigns list you can pause any campaign — new referral attribution stops immediately, existing referrals keep evaluating — and reactivate it later. Every state change is confirmed and audited.

Editing a live campaign

Campaigns aren't versioned. Saving a change to a qualification gate or reward configuration takes effect immediately and applies to everyone right away, including referrals already in flight. Rewards already paid out never change; any pending, not-yet-fulfilled reward is re-evaluated against the new criteria. There's no version history and no rollback — to undo a change, edit the campaign back.

What's next