Subscription Conversion Events: Mapping a Recurring Funnel

At their core, subscription conversion events solve a problem one flat Purchase never can: a recurring funnel produces money moments again and again - trial start, first payment, every monthly rebill - and each moment means something different to the optimizer. Mapping them properly is the difference between a pixel that counts subscribers and one that counts signups while the churn quietly eats the budget. This guide maps the whole funnel: which stages become which events, how rebills keep their identity without double-counting, where cancellations land, and how far platform attribution can see into a recurring relationship.

Delivery underneath - postbacks, statuses, and their break points - belongs to the network postback to CAPI guide; here the funnel itself takes the stage.

The Funnel Has Four Money Moments, Not One

A subscription offer's lifecycle looks like this from the buyer's chair:

Meta's standard event set natively covers the first two: the documented pixel reference lists StartTrial and Subscribe among standard events (Meta pixel reference), and the same names ride the Conversions API as event_name values. TikTok's Events API carries its own standard set with the same subscribe-style stage. The stages after the first payment are where the wiring gets interesting - and where most setups silently stop.

Trial and Subscribe: Two Signals, Not Two Names for One

The trial stage exists because it converts hesitant users cheaply, and the platform should see both ends of that bargain:

1. Fire the trial event at trial start. It is the volume signal - the moment the user relationship began, with zero money attached. As a custom conversion or a plain event, it is how campaigns get judged on qualified entry rather than raw clicks.
2. Fire Subscribe - with value - at first payment. This is the acquisition truth: the trial survived its churn cliff and converted. Everything about value passing works here as in any paid funnel: the payout as value with its currency in custom_data (custom data parameters).

Campaigns optimizing directly on trial events buy volume that may never pay; campaigns optimizing on Subscribe buy confirmed money with less volume. Buyers with enough of both events usually optimize on Subscribe and read StartTrial as the diagnostic layer - the same two-stream logic as COD approve rate tracking, with the churn cliff playing the call center's role.

Rebills: Identity, Value, and Fresh Timing

The recurring part of the funnel is where identity discipline pays:

1. Each rebill gets its own transaction identity. Keitaro's tid-style parameter "records separate conversions instead of overwriting the previous one" (postback URL) - exactly the behavior rebills need. Without it, month three's postback overwrites month one's conversion row and the funnel's history collapses.
2. Each rebill carries its own value. Price changes, discounts, and plan upgrades all ride the postback's payout field; the event's value and currency follow it (custom data parameters).
3. Rebills are sent fresh. The platform's event_time acceptance window - seven days for Meta's Conversions API - measures from the event's own timestamp to send time, and a rebill's timestamp is the moment it charged. Send it the same day and timing is a non-issue; the rebill does not inherit the original click's age.

Whether the platform joins a month-three rebill back to the original ad click is a different question - attribution windows decide that, and they are the platform's rules, not the delivery layer's. The tracker's record is unconditional either way, which is why recurring-money truth lives in tracker reports first (the three-systems picture).

Cancellations and Failed Payments: Where They Land

Subscriptions end, and the ending has no standard platform event:

• Cancellation at renewal. The network simply stops rebilling - the cleanest case. Your tracker's conversion stream ends; platform events already sent stand as counted.
• Refund or chargeback mid-cycle. Keitaro's payout parameter "supports positive and negative values," so the tracker's books correct; the platform side keeps the original event, per the correction rules in the payout guide.
• Failed payment then recovery. A dunning recovery is a new rebill with its own identity and value - not an overwrite of the failed cycle.

The reporting consequence is structural: platform-side numbers count money events sent; tracker-side numbers count money kept. Reconciling the two is the standing job of the hold and status policy applied to a recurring timeline.

Building the Funnel in the Platform

The platform-side assembly:

1. Send each stage under its decided name - standard StartTrial/Subscribe where the standard event fits, custom names for cycle events.
2. Build custom conversions per stage so each appears in reporting and, where relevant, the optimization dropdown (the custom-conversions walkthrough).
3. Choose the optimization target by margin: Subscribe for acquisition campaigns, trial events only where trial-to-paid conversion is high enough to trust.
4. Feed every stage steadily - the warming discipline from the practical sequence guide applies per event, not per pixel.

Verification closes the build: one test user through trial, first payment, and a simulated rebill - each visible in Test Events and Events Manager within about 20 minutes (get started), each with its own value in the tracker.

Subscription Conversion Events: Frequently Asked Questions

Sources