Skip to main content
Pick this if you sell a subscription, bill through Stripe, and can’t tell which campaign produced a paying customer. When you finish, a trial that started from an ad reports the campaign, and the paid subscription attributes to the same person.

Before you start

  • You can add a script tag to your marketing site and your app.
  • You have a Stripe test environment.
  • You have decided which event marks a new customer: signup, trial start, or first payment.

The path

Most SaaS checkouts need no backend work: steps 1 to 3 are the whole setup. Read Bridge the visitor into Stripe for the two checkout shapes that need one extra field.

Bridge the visitor into Stripe

Datalyr must connect the browser that clicked your ad to the Stripe customer that pays you. The SDK does this on its own for Stripe Checkout.

What happens automatically

When your server creates a Checkout Session and your page sends the browser to it, the SDK reads the session ID (cs_live_… or cs_test_…) and reports it before the browser leaves the page. The Stripe webhook matches that session and recovers the visitor. That covers the common shape, with no extra code from you. The SDK also records the customer email from your signup and checkout forms, a second way to match the payment.

When you must set metadata.visitor_id

Two shapes stay invisible to the browser. Add the field yourself in each case. Read the value in the browser:
Then attach it when your server creates the object: A value you set always wins. Your own client_reference_id is never overwritten.
The SDK never decorates a checkout.stripe.com URL, because Stripe ignores these parameters on a session that already exists. The session ID it reports at redirect time is what carries the visitor instead.
Create every Stripe object on your server. A Stripe secret key in browser code lets anyone charge your account.

Pick the conversion event deliberately

Never send a renewal invoice through a new-customer rule. The ad platform then counts one customer many times, and bids toward an audience that already pays you.

Renewals inside Datalyr

Datalyr reports a renewal against the campaign that acquired the customer. A subscriber who arrived from a Google ad in January credits their March renewal to that ad, even though the click is older than the attribution window. Revenue and ROAS keep the meaning they always had: all the cash in the range, with the renewals moved onto the campaign that won the customer. Conversions is the column that changes, and three optional ones explain it. Turn the optional columns on in the metrics picker. Datalyr reads Stripe’s own billing_reason: subscription_cycle is a renewal, and subscription_create is the acquisition.
Meta and Google credit a conversion only inside their own attribution windows, and a renewal lands outside them. Keep renewals out of every new-customer rule. Renewal crediting changes what Datalyr reports, never what we send to an ad platform.
Read Subscription revenue for the renewal marker on every other billing source and the 90-day limit on how far back a renewal reaches.

Verify

  1. Open the marketing site in a private window with ?utm_source=stripetest.
  2. Sign up with a test email address.
  3. Complete a Stripe test checkout.
  4. Open Users and find the account.
  5. Confirm the pre-signup pageviews sit on the same profile.
  6. Open Conversions and confirm utm_source reads stripetest.
  7. Trigger a test renewal and confirm it does not create a second acquisition.

When it doesn’t work

Next

  • Stripe revenue: every webhook and its Datalyr event name.
  • Identity: how the email bridge rescues an unattributed payment.
  • Subscriptions: trials, renewals, and cancellations.