How to connect Google Analytics to Stripe revenue, and where it breaks

To connect Google Analytics to Stripe revenue, your server sends a purchase event to Google Analytics 4 each time Stripe confirms a payment, tagged with the visitor's client ID so the sale joins the visit that earned it.

The 6 steps below work for a first payment made on the day of the click.

They become unreliable for the first charge of a trial longer than 2 days and for every renewal, because Google says Measurement Protocol events arriving more than 48 hours after the browser event may not be processed as expected for conversion attribution.

Google Analytics 4 records only what its tag or the Measurement Protocol sends it, and Stripe files payments under IDs of its own, so one identifier has to travel from the browser into Stripe and back.

Stripe's guide to analyzing the Checkout funnel with Google Analytics 4 uses this route, but its server-side sample sends an empty params object, which records no value.

Connect Google Analytics to Stripe in 6 steps

You need the Editor role on the property, a webhook endpoint, and a server route that creates Stripe Checkout Sessions.

Step 1: Exclude checkout.stripe.com from referrals

Customers returning from Stripe Checkout arrive with checkout.stripe.com as the referrer, so a new session can be filed under it instead of the campaign. Stripe's funnel guide says to exclude it.

In Google Analytics 4, open Admin, Data streams, your web stream, Configure tag settings, then List unwanted referrals, and add the domain. A stream holds up to 50, and past sessions keep their source.

Step 2: Create a Measurement Protocol API secret

Secrets belong to a Google Analytics 4 data stream, so open Measurement Protocol API secrets in the web stream from step 1, create one, and copy it with the measurement ID that starts with G-.

Posts go to https://www.google-analytics.com/mp/collect, or to region1.google-analytics.com for EU collection. Keep the secret server-side, because anyone holding it can send arbitrary events to your property.

Step 3: Read the client ID and session ID in the browser

The gtag.js get command returns client_id and session_id for a Google Analytics 4 measurement ID. Call it when the visitor clicks checkout and post both values to the route that creates the Session.

A client ID is 2 numbers joined by a period, which matters in step 4. A blocked tag can leave the callbacks silent, so the sample starts checkout after 1.5 seconds regardless.

1function startCheckout() {2  let started = false;3  const ids = { clientId: "", sessionId: "" };4 5  const go = () => {6    if (started) return;7    started = true;8    fetch("/api/checkout", {9      method: "POST",10      headers: { "Content-Type": "application/json" },11      body: JSON.stringify(ids),12    })13      .then((res) => res.json())14      .then(({ url }) => { window.location.href = url; });15  };16 17  setTimeout(go, 1500); // a blocked tag never calls back18  if (typeof gtag !== "function") return go();19 20  gtag("get", "G-XXXXXXXXXX", "client_id", (clientId) => {21    ids.clientId = String(clientId);22    gtag("get", "G-XXXXXXXXXX", "session_id", (sessionId) => {23      ids.sessionId = String(sessionId);24      go();25    });26  });27}

Step 4: Store both IDs on the Stripe objects

Put the 2 IDs in metadata on the Checkout Session. Subscriptions also need subscription_data.metadata, which Stripe writes to the Subscription and snapshots onto every invoice at parent.subscription_details.metadata, so a renewal webhook can find the client ID months later.

Payment Links fix their metadata when you create the link, so append client_reference_id instead. Per Stripe's URL parameters page, it takes up to 200 characters of letters, digits, - and _, and silently drops anything else.

A client ID has a period, so swap it before sending and restore it in the webhook. The guides to Payment Links attribution and Stripe metadata attribution cover those routes without Google Analytics 4.

1// POST /api/checkout2export async function POST(req: Request) {3  const { clientId, sessionId } = await req.json();4  const ga = { ga_client_id: clientId, ga_session_id: sessionId };5 6  const session = await stripe.checkout.sessions.create({7    mode: "subscription",8    line_items: [{ price: "price_XXXXXXXX", quantity: 1 }],9    success_url: "https://example.com/welcome",10    cancel_url: "https://example.com/pricing",11    metadata: ga,                       // stays on the Session12    subscription_data: { metadata: ga } // copied onto every invoice13  });14 15  return Response.json({ url: session.url });16}17 18// Payment Links: a client ID like 1234567890.1700000000 has a period,19// which client_reference_id would drop, so swap it before appending20function paymentLink(clientId: string, sessionId: string) {21  const ref = clientId.replace(".", "_") + "-" + sessionId;22  return "https://buy.stripe.com/XXXX?client_reference_id=" + ref;23}24// In the webhook, reverse it:25//   const [cid, sid] = session.client_reference_id.split("-");26//   const clientId = cid.replace("_", ".");

Step 5: Send purchase and refund events from a webhook

Subscribe an endpoint to 2 events, invoice.paid for subscriptions and checkout.session.completed for one-time payments, and verify each signature before acting. The Google Analytics 4 purchase event takes a value without tax and an items array, so the sample reads total_excluding_tax.

Stripe amounts are in the smallest currency unit.

Stripe retries failed deliveries for up to 3 days in live mode and may deliver the same event more than once, while Google Analytics 4 deduplicates purchases that share a transaction ID, so the invoice ID goes in that field.

An empty ID makes every purchase look like a duplicate. Refunds use the refund event with the original invoice ID, sent from a charge.refunded handler.

1const MP_URL =2  "https://www.google-analytics.com/mp/collect" +3  "?measurement_id=" + process.env.GA_MEASUREMENT_ID +4  "&api_secret=" + process.env.GA_API_SECRET;5 6export async function POST(req: Request) {7  const event = stripe.webhooks.constructEvent(8    await req.text(),9    req.headers.get("stripe-signature")!,10    process.env.STRIPE_WEBHOOK_SECRET!,11  );12 13  if (event.type === "invoice.paid") {14    const invoice = event.data.object as Stripe.Invoice;15    const meta = invoice.parent?.subscription_details?.metadata ?? {};16 17    if (meta.ga_client_id && invoice.amount_paid > 0) {18      await fetch(MP_URL, {19        method: "POST",20        body: JSON.stringify({21          client_id: meta.ga_client_id,22          events: [{23            name: "purchase",24            params: {25              transaction_id: invoice.id,26              currency: invoice.currency.toUpperCase(),27              // two-decimal currencies only; GA4 value excludes tax28              value: (invoice.total_excluding_tax ?? invoice.amount_paid) / 100,29              session_id: meta.ga_session_id,30              engagement_time_msec: 100, // lets the event show in Realtime31              items: [{ item_id: "starter-monthly", item_name: "Starter plan" }],32            },33          }],34        }),35      });36    }37  }38  return new Response(null, { status: 200 });39}

Step 6: Validate before trusting the numbers

Post the payload to https://www.google-analytics.com/debug/mp/collect first. It returns an empty validationMessages array for a valid Google Analytics 4 event and does not check the API secret.

The live endpoint returns no HTTP error code even for a malformed event, so a handler that watches status codes never sees a failure. Test in a separate property, then compare purchases sent with paid Stripe invoices after 30 days.

Limits that matter for this build

How much revenue Google Analytics 4 can credit to a channel

Take a $39 monthly plan sold to a visitor who clicks a Google ad on day 0 and pays the same day. Year one is 12 payments, $468 in all.

The first payment arrives within an hour of the browser event, and each later one arrives a month further out.

Without a trial, 1 payment in 12 sits inside the window: $39 of $468, or 8.3% of year-one revenue.

Google says only that later events may not be processed as expected for attribution, and does not say what Google Analytics 4 does with them.

Send one late test event and check which source it lands under before you build a report on it.

Where the connection breaks

Trials and renewals

Stripe's Checkout Session object reports a subscription with a free trial as paid once its $0 trial invoice is processed, so the session completes with amount_total at 0.

Send that moment as a custom trial_start event marked as a key event, while the visit is inside the 48-hour window. Renewals carry no session Google can credit.

I would let Google Analytics 4 judge acquisition up to the signup and leave the money after it to Stripe or a billing-side tool, as subscription LTV attribution describes.

Cookies, blockers and consent

Google's cookie documentation sets the _ga cookie to expire after 2 years by default and says browsers cap first-party cookies for visitors who do not return.

WebKit's policy adds a 24-hour cap for Safari Intelligent Tracking Prevention when it detects link decoration on the landing page.

A visitor who clicks an ad on day 1 and returns on day 9 with no visit between arrives as a new client, so the campaign is gone before Stripe is involved.

A blocked tag or a consent banner leaves no client ID at all, and the Session carries empty metadata.

Skip those events and log how many you skip, since an invented ID would credit the sale to a visit that never happened. The Safari ITP guide covers the browser side.

Retention

The setting affects Explorations and funnel reports and leaves standard aggregated reports alone, so a 24-month lifetime value comparison by channel cannot come from Explorations in a standard Google Analytics 4 property. The BigQuery export is the way around it.

Four ways to join the two systems

Pick the first row for one-time or same-day sales, the second for teams with a warehouse, and the fourth when most revenue is renewals. The third feeds Google Ads bidding.

Reading the channel from Stripe instead

Billing-side attribution reverses the order: the click is recorded first, on a tracked link, and the payment is read from Stripe afterward, so no browser ID has to survive until checkout.

TrackRev, SaaS affiliate software with revenue attribution built in, works this way. Setup is a read-only restricted Stripe key and a one-line pixel.

TrackRev joins each paid charge to a click through the customer's email, which the pixel binds to the visitor at signup or checkout.

It syncs hourly, backfills 90 days on the first sync, credits renewals to the original click, and nets refunds and chargebacks out of channel revenue.

The same join covers 6 processors: Stripe, Paddle Billing, Polar, Lemon Squeezy, Creem and Dodo Payments.

Last-touch is the default, with first-touch and linear one dropdown away. Revenue by channel needs a paid plan from $29 a month on Indie, with no limit on tracked revenue; the free plan covers link tracking only.

Email is the join key, so test the buyer who pays under a different address than the one they signed up with.

TrackRev does not replace Google Analytics 4 for page engagement or content performance, and a team that wants only a standalone attribution product may prefer another tool.

For the reporting side, see GA4 not showing revenue by channel and attributing Stripe revenue to marketing channels.