Technical Guide
GA4 can technically track Stripe and SaaS revenue — but only after wiring together three separate integrations: client-side ecommerce events, the Measurement Protocol API, and a BigQuery export pipeline. This guide walks through the actual code for each step and shows exactly where GA4 revenue attribution falls apart.
Source: Composite of CHI 2025, TWIPLA, Apple WebKit, AdFixus, MarTech, and Backlinko measurements
Google's documentation makes GA4 revenue tracking sound straightforward: fire a purchase event with a value, and revenue shows up in your reports. For a simple e-commerce store with a thank-you page, that's mostly true.
For Stripe-powered SaaS products, the reality is different. Stripe payments happen server-side after checkout. Subscriptions renew automatically — no browser session involved. Trials convert days or weeks after the initial visit. None of these fit the client-side event model GA4 was designed around.
Here are the three implementation layers GA4 requires for reliable Stripe revenue attribution. Each snippet includes annotations for the exact failure points.
The most common starting point: fire a purchase event from your checkout confirmation page using the gtag() function.
// On your /thank-you or order confirmation page
gtag('event', 'purchase', {
transaction_id: 'ch_3abc123', // Stripe charge ID
value: 49.00, // Revenue amount
currency: 'USD',
items: [{
item_id: 'pro_monthly',
item_name: 'Pro Plan',
price: 49.00,
quantity: 1
}]
});You must pass the Stripe charge ID and amount into the page — this means your backend needs to inject them into the HTML or expose them via an API call before the page loads.
Firing on page load risks duplicate events if the user refreshes. You need deduplication logic using the transaction_id — which GA4 does not enforce automatically.
Subscription renewals, webhook-triggered charges, and any payment not tied to a browser session are invisible to this event entirely.
To capture server-side Stripe webhook events (renewals, upgrades, delayed conversions), you need to hit GA4's Measurement Protocol endpoint directly from your backend.
// Called from your Stripe webhook handler
await fetch(
`https://www.google-analytics.com/mp/collect` +
`?measurement_id=G-XXXXXXXXXX` +
`&api_secret=YOUR_API_SECRET`, // Store this in env vars
{
method: 'POST',
body: JSON.stringify({
client_id: session.ga_client_id, // Must retrieve from DB
events: [{
name: 'purchase',
params: {
transaction_id: charge.id,
value: charge.amount / 100,
currency: charge.currency.toUpperCase(),
items: [{ item_id: plan.id, item_name: plan.name }]
}
}]
})
}
);
// No response body on success — 204 No ContentYou must generate a Measurement Protocol API secret in GA4 and store it securely. Rotating this secret invalidates all existing integrations.
GA4 uses a client_id (stored in the _ga cookie) to link server events to browser sessions. You must capture this ID at checkout and store it in your database — which means additional engineering work before you even write this code.
The Measurement Protocol returns a 204 with no body on success and no indication of validation errors. Malformed payloads silently fail. You need your own retry and logging infrastructure.
Events sent via Measurement Protocol are not real-time. GA4 processes them with up to a 15-minute delay, and they appear in a separate "unassigned" bucket until session stitching completes — which can take longer.
When Measurement Protocol session matching fails — which it often does — the fallback is exporting raw GA4 data to BigQuery and joining it manually with your Stripe charges.
-- Join GA4 events with Stripe charges by transaction_id
SELECT
ga.traffic_source.source AS channel,
ga.traffic_source.medium AS medium,
SUM(stripe.amount / 100) AS revenue_usd,
COUNT(DISTINCT stripe.id) AS payment_count
FROM
`project.analytics_XXXXXXX.events_*` AS ga -- GA4 export table
JOIN
`project.stripe_export.charges` AS stripe
ON JSON_VALUE(
(SELECT ep.value.string_value
FROM UNNEST(ga.event_params) ep
WHERE ep.key = 'transaction_id'),
'$'
) = stripe.id
WHERE
ga._TABLE_SUFFIX BETWEEN '20260101' AND '20260228'
AND ga.event_name = 'purchase'
AND stripe.status = 'succeeded'
GROUP BY
channel, medium
ORDER BY
revenue_usd DESC;GA4's BigQuery export is only available on Google Analytics 4 properties linked to a Google Cloud project. BigQuery charges for storage and queries — costs scale with data volume and query frequency.
GA4's BigQuery schema uses nested RECORD fields (like event_params) that require UNNEST operations. The schema is not intuitive and differs from the GA4 UI, so every query requires deep familiarity with the raw data structure.
BigQuery exports are processed daily, typically with a 24-72 hour lag. You cannot use this for same-day or same-week optimization decisions.
Google occasionally updates the GA4 BigQuery export schema. When fields are renamed or restructured, every query that references them silently returns null or throws an error — with no alerting.
Even after implementing all three layers above, GA4 revenue attribution has structural limitations that make it unreliable for subscription businesses.
GA4 has no built-in way to receive Stripe webhooks. Every subscription renewal, failed charge retry, upgrade, and refund requires a custom backend handler that transforms the Stripe event payload into a GA4 Measurement Protocol call — and correctly matches it to a historical client_id.
GA4's ecommerce model is transaction-based. Monthly recurring revenue, annual plan renewals, seat expansions, and trial conversions all happen outside any browser session. You can log them via Measurement Protocol, but they will never have source/medium attribution — they land as "(direct) / (none)".
Under GDPR, GA4 requires a consent banner. When visitors reject cookies, GA4 Consent Mode v2 switches to "modeled" (estimated) data. For sites with European traffic, 30-40% of revenue events are estimates, not measurements. The model's accuracy degrades for low-traffic channels.
GA4's default attribution model uses machine learning to distribute credit across touchpoints. You cannot audit the model, explain why a channel received credit, or override it for specific conversions. For compliance-sensitive businesses or investor reporting, this is a significant problem.
GA4 does not expose Revenue per Visitor (RPV) as a built-in metric. To compare channel quality by RPV, you need a custom Exploration or a BigQuery query. Neither updates in real time.
Attrifast was built specifically for the Stripe-and-SaaS use case that GA4 handles poorly. Instead of client-side events and session matching, it connects directly to your Stripe account and links each payment to the visitor session that preceded it — no data layer, no Measurement Protocol, no BigQuery.
Authorize Attrifast to read your Stripe data. All payments — one-time, subscriptions, renewals — are pulled automatically. No webhook code to write.
Attrifast identifies sessions without cookies, so consent banner rejections don't create data gaps. Revenue from all visitors is attributed, not just those who accept cookies.
RPV by source/medium is available the moment payments arrive. No BigQuery export, no SQL, no 24-hour lag.
GA4 remains valuable for behavioral analytics, funnel analysis, and audience building. The recommendation is not to replace GA4 — it's to stop asking GA4 to do something it wasn't designed for. Use GA4 for behavior, Attrifast for revenue attribution.
Source: AdFixus and OWOX analyses of GA4 channel attribution; Digiday on AI referrer-strip
Every numbered citation in this article links to its primary source below.
No GTM, no Measurement Protocol, no BigQuery. Just connect Stripe and see revenue by channel.
Skip the GA4 setup →Loved by 500+ users