Qualified Trials
Defer trial forwarding to ad networks until user intent is proven, improving ROAS.
The Problem#
Ad networks optimize toward the events you send them. If you forward every trial start, the network optimizes for users who start trials -- but most of those users cancel before converting to paid. This leads to wasted ad spend and inflated trial metrics that don't reflect real revenue.
The Solution#
Qualified Trials defers trial forwarding by a configurable delay (default: 2 hours). Only trials where the user is still subscribed after the delay period are forwarded to ad networks. This teaches the ad network to find users with genuine purchase intent.
How It Works#
The qualified trial system operates as a state machine:
| Step | What Happens |
|---|---|
| 1. Trial starts | RevenueCat sends INITIAL_PURCHASE webhook with trial period. AppRefer holds the event instead of forwarding immediately. |
| 2. Hold period | The event sits in the qualified_trials queue for the configured delay (default 2 hours). |
| 3a. Still subscribed | Cron job checks the trial status. If user is still subscribed, the event is forwarded as qualified_trial. |
| 3b. Cancelled | If a CANCELLATION webhook arrives during the hold period, the trial is marked as disqualified and never forwarded. |
Forwarded Event#
When a trial qualifies, it is forwarded as qualified_trial to the configured ad networks:
| Ad Network | Mapped Event |
|---|---|
| Meta (CAPI) | StartTrial |
| Google Ads | qualified_trial |
| TikTok | Subscribe |
Setup#
- Go to Settings → Qualified Trials in the AppRefer dashboard.
- Enable qualified trial forwarding.
- Set the delay hours (default: 2 hours). Choose a window that balances signal quality with timeliness.
Impact on ROAS
Cron Processing
/api/cron/qualified-trials endpoint, which runs on a schedule. Trials that pass the delay window are forwarded in batch.