How Do You Track Trial-to-Paid Conversions Weeks Later?

A trial-to-paid conversion is two events, not one. The signup happens in a browser you can see. The payment happens weeks later inside your billing system, with no browser, no click ID and no session attached. You connect them by storing the first touch against the person at signup, then matching the payment back to that record when the card clears.

The plumbing is the easy half. The decisions — which event you optimise against, when a cohort’s numbers are final, and whether you rank campaigns on trials or on paid conversions — are where most subscription attribution quietly goes wrong.

Which event is the conversion: the trial start or the first payment?

Both, for different jobs. The trial start is your optimisation event: it fires minutes after the click, it carries a real email, and it gives the ad platform something to learn from while the click is still fresh. The first payment is your measurement event: it is the only one with money attached.

Send only trial starts and the algorithm optimises for people who are willing to type a card into a form. That is not the same population as people who keep paying, and on some channels it is nowhere near it. Send only payments and you starve the algorithm — a campaign gets its first feedback thirty days after it started spending, by which time you have either wasted the budget or turned it off.

The working setup is both, named differently, with only one of them carrying revenue. A lead or signup event at day zero with no value on it. A purchase or subscribe event at first payment with the actual amount and currency. Two events, two purposes, no double counting, because they describe different moments in the same journey rather than the same moment twice.

The trap is sending both with a value and reading the total — your dashboard then shows revenue for trials nobody has paid for. Put the money on the payment event, and give the algorithm the free one too, through the Conversions API, so it arrives whether or not the browser cooperated.

Why is your trial cohort’s ROAS wrong until the cohort matures?

Because part of the cohort has not decided yet. On the last day of the month, a campaign that started spending three weeks ago has trials still sitting inside their trial window. Their payments have not happened, so its revenue column is structurally incomplete — not wrong in a way you can fix with better tracking, just early.

This is the single most expensive reporting mistake in subscription marketing. Someone compares September spend against September revenue, sees a bad ratio, and pauses a campaign whose trials convert on day 30. Half of them convert a week after the decision is made, on a campaign that is no longer running.

The fix is discipline, not software. Report by cohort — the month the trial started, not the month the payment arrived — and mark cohorts as immature until every member has passed the trial length plus a few days of dunning. A 14-day trial means September’s cohort is readable around 25 September for its first week and honest only in early October. Say the maturity date out loud on the report.

Your own lag distribution sets that date. Trials convert in a cluster around the trial end with a tail behind it, so pull the distribution once, find the day by which most paid conversions have landed, and make that your maturity rule. The same structural gap shows up outside subscriptions whenever you are attributing a purchase weeks after the ad click — the difference with a trial is that the delay is a fixed, known, billable number, so you have no excuse for being surprised by it.

How do you carry the first touch from the signup to the invoice?

Write the attribution onto the person at signup, not onto the payment. The signup is the last moment the browser still holds the campaign data: UTM parameters, the referrer, the landing page, and click IDs like gclid, fbclid and msclkid. Store those against the account record the moment it is created, and the payment can join back to them through the account weeks later.

Doing it the other way around — looking for the campaign at payment time — cannot work. The charge is a server-side event created by a billing schedule; there is no browser in the room to ask, and identifiers you did not save at signup are not retrievable later.

Three things make the carry survive:

• Persist server-side, not in the browser. A cookie or localStorage entry is not a thirty-day storage medium. Safari’s tracking prevention caps script-written cookie lifetimes, ad blockers remove tags, and people clear browsers and switch devices. Attribution that matters for a month belongs in your database, on the user row.
• Key on something that survives the gap. A normalised email, a normalised phone, and your own first-party visitor ID all outlive a session. Match on canonical values — lowercased and trimmed email, E.164 phone — so the same person is one person.
• Keep first touch and last touch separately. A trial user typically has several sessions before signing up. First touch tells you which campaign created the relationship; last touch tells you which one closed it. Storing only one is throwing away half the answer.

The dispatch side of this — capturing Meta’s identifiers at the first visit and firing the delayed event server-side with a shared event ID — is covered in tracking SaaS trial conversions to Meta Ads. The reporting-side join, from a payment object back to a browsing session, is the same machinery described in attributing Stripe payments to campaigns.

Can you backdate the paid conversion to the day of the ad click?

No. Meta’s Conversions API accepts an event_time only within a seven-day window, so a payment that happens thirty days after the click cannot be timestamped back to the click. It is sent with the time it actually happened, and the platform uses the identifiers in the payload — not the timestamp — to decide which click it belongs to.

That surprises people, so it is worth being blunt about the consequence. Attribution of a delayed conversion is an identity problem, not a timestamp problem. The click ID, the hashed email and the hashed phone in the payload are what tie the event back to an ad. A perfectly accurate event_time with no identifiers attributes nothing.

It also explains why the trial-start event earns its place. The signup happens while the click is fresh and well inside every reporting window, so it is the event that reliably lands in the platform’s own attribution. The payment event arrives late, carries the money, and is credited on the strength of its identifiers.

One more consequence: backfilling historical conversions after installing tracking gets the timestamps clamped, not accepted. Backfill is useful for your own reporting and for matching customers, not for retroactively crediting campaigns that ran months ago.

How do you compare campaigns on trial-to-paid rate instead of trial volume?

Divide paid conversions by trials started, per campaign, per cohort. Two campaigns with the same cost per trial can differ by a factor of three on the share that ever pays, and the cheaper one is often the worse one. Cost per trial is a measure of your landing page. Trial-to-paid rate is a measure of the traffic.

Worked with round illustrative numbers: campaign A produces 100 trials at $20 each, campaign B produces 50 trials at $40 each. On cost per trial, A wins by double. Then the cohort matures — 12% of A’s trials pay, 34% of B’s do. A produced 12 customers for $2,000, or $167 each. B produced 17 for $2,000, or $118 each. The campaign that looked twice as expensive acquires customers a third cheaper, and you would only ever see it by waiting for the cohort.

Three rules keep that comparison honest:

1. Group by cohort start, always. Paid conversions belong to the month the trial started, not the month the money moved.
2. Compare mature cohorts only. Put the immature ones on the same report greyed out, with the maturity date beside them, so nobody reads a half-finished number as a verdict.
3. Keep the denominator stable. Count trials the same way every month — deduplicated by person, excluding your own team and obvious junk — or the rate moves for reasons that have nothing to do with the campaign.

Once you have that rate by campaign, the budget question answers itself, in the same way as any other attribution channel you are deciding whether to scale: the channel with the best mature cost per paying customer gets the money.

How does PartialLeads track a trial-to-paid conversion weeks after signup?

By treating the payment as a purchase that arrived late, and having kept the identity that connects it to the click. Stripe connects as a purchase source over OAuth, alongside Shopify, WooCommerce, GoHighLevel and a universal webhook. Every payment then runs through one pipeline: normalise identity, deduplicate, match to a session in tiers, attach revenue to the lead, and write both a first-touch and a last-touch attribution row.

The pieces that matter for a delayed conversion specifically:

Identity that outlives the trial. The visitor ID is a first-party cookie set by the server rather than by script, so it is not subject to the seven-day cap Safari applies to script-written cookies. Behind it, a cluster resolver unions a person’s sessions across visitor ID, email, phone, IP plus user agent, a device fingerprint and shared click IDs. A person who clicked on a phone in August and paid on a laptop in September is one person, not two rows.

First touch and last touch, both written. Every matched payment writes both rows, each snapshotting UTMs, click IDs, referrer, landing page and time to purchase. That is what makes cohort reporting possible after the fact — the signup’s campaign is still attached to the payment a month later.

Deduplication that survives retries. Payments are idempotent on client, source, order ID and status phase, and dispatched events carry a deterministic event ID, so a redelivered webhook cannot double-count a conversion. Refunds get their own row that nets against the paid one, which matters when a converted trial refunds in its first week.

Dispatch back to the platforms. Matched payments fan out server-side to Meta, Pinterest, TikTok and Google Ads with hashed contact details attached — inside the platform’s event-time window, at the time the payment actually happened.

Where you see it working: the Attribution report’s Time to Purchase panel, which plots first-touch and last-touch lag side by side in buckets from under an hour to over 28 days, so a trial cohort’s shape is visible rather than assumed; the Avg Lag column on the channels table, where a channel whose buyers take 30 days is immediately distinguishable from one whose buyers take a day; and the first-touch model beside last-touch and resolved, which how to read an attribution report walks through in detail.

The honest constraints. There is no trial-state model in the product — no in-trial, converted or churned status, and no subscription cohort report. What exists is the payment, the lag between first touch and that payment, and the attribution rows on both ends; the cohort view is a computation you run on top of that, or in your billing system. And matching has a ceiling nobody controls: a person who signed up through a channel where the tag never ran has no session to match to, so their payment lands as unmatched revenue rather than a campaign row. Capture more of the person earlier and more of the revenue resolves.

Sources

1. Meta for Developers — Conversions API overview: https://developers.facebook.com/docs/marketing-api/conversions-api
2. Meta for Developers — Server event parameters (including the event_time window): https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event
3. Meta for Developers — Customer information parameters: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters
4. Meta for Developers — Deduplicate Pixel and Conversions API events: https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events