GA4 says X, the commerce platform says Y, surfaces broken purchase tag, AdBlock prevalence, or cross-domain tracking gaps before they corrupt every attribution call.
At a glance
The percentage gap between GA4-measured revenue and commerce-platform revenue (Shopify, BigCommerce, or Adobe Commerce). A stable 10, 25% gap is normal and healthy (the structural GA4 tracking gap from ad blockers, consent rejection, and tag-fire failures). A gap above 25%, or a gap that suddenly widens, is the cleanest signal of a broken purchase tag, before any other card visibly degrades.
| What it counts | 1 − (GA4 totalRevenue ÷ Commerce-platform total revenue) over the same 30-day window, expressed as a percentage. The “missing revenue” share that GA4 didn’t see. |
| Sample basis | Aggregated revenue totals from both sides. GA4 side: runReport with totalRevenue metric, no dimension. Commerce side: indexed orders summed in OpenSearch. Both windows aligned to the property’s timezone. |
| Sampling threshold | None for the 30D window. GA4 only samples on date ranges >14 months or with high-cardinality dimensions; this card uses a metric-only query that’s never sampled in standard windows. |
| Bot traffic filter | GA4’s built-in IAB Tech Lab bot filter applied on the GA4 side. Commerce side has no bot filter (orders are real money). The asymmetry is fine; the gap signal is what matters. |
| Time zone | The GA4 property’s timezone. Both sides aligned to this zone for windowing. |
| Currency | Both sides converted to a single currency (the GA4 property’s reporting currency, which equals the commerce platform’s primary currency for ~98% of merchants). FX-converted at event time. |
| Refunds | Excluded on both sides for apples-to-apples. GA4 totalRevenue excludes refunds natively; commerce side uses gross revenue. |
| Tax / shipping | Both sides include them by default (depends on tag setup; assumes standard purchase event with value = order total). |
| Tracking-gap framing | Healthy stores sit at 10, 25% gap. Below 10% means either a sophisticated server-side tagging setup OR a duplicate-firing tag (each order counted twice in GA4); above 25% means tag-fire failure, consent rejection too high, or a serious ad-blocker population. |
| Time window | 30D vsP (30 days vs the prior 30 days). The window must be long enough to smooth daily noise. |
| Alert trigger | >25% gap GA4 revenue vs commerce-sibling revenue, OR a sudden week-over-week widening of the gap by >10 pp. |
| Roles | owner, marketing, finance |
Calculation
Calculated automatically from your Google Analytics 4 data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK fashion brand on Shopify with GA4 connected. Two snapshots: 30 days ending 12 Apr 26, and 30 days ending 02 May 26.| Window | Shopify Total Revenue | GA4 totalRevenue | Gap (£) | Gap (%) | Status |
|---|---|---|---|---|---|
| 30D ending 12 Apr 26 | £412,600 | £348,900 | £63,700 | 15.4% | Healthy (within 10, 25% band) |
| 30D ending 02 May 26 | £441,200 | £308,400 | £132,800 | 30.1% | Alert tripped (>25%) |
- The gap widened by 14.7 pp in 20 days, that’s the alert. The April number sat comfortably within the “normal” band; the May number is outside it. Crucially, Shopify revenue grew by 7%, but GA4 revenue fell by 12%. This is the exact pattern that says “the real business is fine, but GA4’s measurement of it has degraded”. Without this card, the merchant might believe revenue dropped (looking only at GA4) or might never notice the measurement regression at all.
- The cause is almost always a tag regression. Triage workflow: (a) check GA4 GTM Tag Fire for the hourly tag-fire ratio, look for the inflection point; (b) Preview Mode test the GTM container; (c) check Admin → Events that
purchaseis still a Key Event; (d) review the consent-banner version history; (e) check the Shopify theme update history. For this brand, the cause was a Shopify theme auto-update on 22 Apr 26 that swapped the custom GA4 e-commerce snippet for a vanilla one missing thepurchaseevent. - The fix is fast; the data won’t backfill. Once the merchant restores the correct snippet, the gap returns to ~15% within 24h. But the missing 14.7 pp of late-April revenue is gone from GA4 forever, GA4 doesn’t backfill historical events that didn’t fire. Channel attribution for that 10-day window will look distorted permanently. Treat this card’s red state as a fire alarm.
- The structural gap is real. Even with a perfectly-configured tag, this brand’s “healthy” gap is 15%, not 0%. That’s ad blockers (5%) + consent rejection (6%) + slow-network tag fails (3%) + occasional B2B order bypassing storefront (1%). No amount of engineering work brings a client-side GA4 setup below ~7%. Server-side tagging plus Consent Mode v2 modelling can get the gap to 8, 10%, never zero.
- GA4 is for channel attribution, not revenue. Even at 30% gap, GA4’s relative channel breakdown (Email vs Paid Search vs Direct) is still informative because the bias affects all channels. Use Shopify for the revenue total; use GA4 to see which sources contributed to it.
Sibling cards merchants should reference together
| Card | Why pair it with Traffic-to-Revenue Divergence |
|---|---|
| GA4 Property Health | The composite real-time view. Property Health goes amber before this 30-day card visibly widens; this card confirms the regression is sustained. |
| GA4 GTM Tag Fire | The hourly view of the tag-fire ratio. Use this to find the exact inflection moment when the gap widened. |
| GA4 Revenue Trend | The GA4 side of the comparison. |
| GA4 Conversion Rate | A widening revenue gap usually correlates with a CR drop in GA4. The two cards corroborate each other. |
| GA4 Tracking Gap vs Commerce | Sister card with a different time window (typically 7-day rolling). This is the canonical merchant-facing gap card. |
| Shopify / BC / Adobe Total Revenue | The commerce side of the comparison. The truth side. |
| GA4 Bot Traffic Share | A gap narrowing unexpectedly might be a bot wave inflating GA4 sessions and (rarely) firing fake purchase events; check bot share. |
| Cross-channel: Ad Attribution Consistency | When this card alerts, downstream attribution to Google Ads and Meta Ads is also corrupted. They tell the same story. |
Reconciling against the vendor’s own dashboard
Where to look in GA4 (this card is a Vortex IQ-only metric): GA4 doesn’t compute or display this gap. The reconciliation requires both GA4 and your commerce platform connected; no GA4-native screen does it. The closest manual rebuild:Reports → Monetization → Ecommerce purchases → Total revenue for the GA4 side, then compare against your Shopify Admin → Analytics → Reports → Total sales (or BigCommerce Analytics → Orders → Sales, or Adobe Commerce Reports → Sales → Sales).Other GA4 views that look like reconciliation but aren’t:
- Acquisition → Traffic acquisition → Total revenue (per channel): GA4 attributes revenue to channels using its data-driven model; the totals can drift from the headline
totalRevenuedue to attribution interactions. - Explorations → Cohort exploration: custom date logic; not directly comparable.
- Realtime → Revenue: 30-min lookback only; useful for tag-fire validation, not for gap measurement.
| Reason | Direction of divergence |
|---|---|
| Late-arriving event ingestion. GA4 ingests events with up to 4-hour delay. We snapshot at sync time; manual checks done minutes later may pick up slightly more GA4 revenue. | Our gap appears slightly larger for the most recent 24h |
| Currency conversion lag. Multi-currency stores see micro-drift between GA4’s daily FX rate and the commerce platform’s order-time FX rate. | <0.5% |
| Refund timing. Vortex IQ’s gap calculation excludes refunds on both sides; if a manual check uses gross-of-refunds on Shopify, the manual gap will look larger. | Manual gap may be 1, 3 pp larger |
| Time-zone alignment. We align both sides to the GA4 property timezone; manual checks done in Shopify’s store timezone may pick a slightly different day boundary. | Boundary days only |
| Card | Expected gap (healthy) | Causes of expected gap | What out-of-band signals |
|---|---|---|---|
shopify.total_revenue | 10, 25% | Ad blockers (~5%), consent rejection (~5, 10%), tag-fire failures (~2, 5%), B2B/draft orders bypassing storefront (~0, 5%). | <10% gap = duplicate-firing tag OR sophisticated server-side setup. >25% gap = tag regression. |
bigcommerce.total_revenue | 10, 25% | Same shape. BC’s Incomplete orders aren’t in either side. | Same thresholds. |
adobe_commerce.total_revenue | 10, 25% | Same shape. Adobe’s pending_payment orders aren’t in either side. | Same thresholds. |
stripe.stripe_total_revenue | Variable by payment mix | If 100% Stripe-routed, gap matches above. If mixed (PayPal, AmazonPay, BNPL), Stripe is lower; GA4 vs Stripe gap is misleading. | Use the commerce platform comparison, not Stripe directly. |
klaviyo.email_attributed_revenue | Klaviyo > GA4 Email channel | Different attribution windows (Klaviyo: 5-day last-touch; GA4: last-non-direct click within session). | This is normal; not part of the gap calculation. |
Known limitations / merchant FAQs
Why does GA4 always show less revenue than my Shopify? Is GA4 broken? GA4 isn’t broken; it’s structurally undercounting. Thepurchase event must fire from the customer’s browser at the order-confirmation page. That event fails when ad blockers run, when cookie banners are rejected, when networks are slow, or when GTM containers are mis-configured. The aggregate miss rate is 10, 25% for healthy ecommerce stores. The commerce platform is the source of truth for revenue; GA4’s job is channel attribution.
Can I fix the gap?
Partially. Server-side tagging via Google Tag Manager Server (or a Cloudflare Worker proxy) bypasses ad blockers on the client. Consent Mode v2 with modelled conversions narrows the gap further (Google fills in some of the missing data using machine-learned models). Realistically you can shrink the gap from 25% to 7, 10% with a serious tag-side investment, but never to zero.
The gap suddenly jumped from 15% to 35%, what happened?
Almost always a tag regression. Check (1) your GTM container is publishing correctly (Preview Mode test will confirm), (2) purchase is still marked as a Key Event in GA4 Admin, (3) your consent banner hasn’t started defaulting to Reject, (4) your ecommerce JavaScript hasn’t been swapped (Shopify theme update, headless redeploy), (5) Apple’s Safari ITP rolled an update that breaks the event. One of those five causes accounts for ~95% of sudden gap-widenings we see. GA4 GTM Tag Fire is the next stop in triage.
My gap is suddenly 5%, that’s better than ever, right?
Probably not. A gap below the structural floor (~10%) is suspicious. Two scenarios: (a) you deployed server-side tagging and it’s working brilliantly (great), (b) you have a duplicate-firing purchase event (each order counted twice in GA4). The second is more common. Test by clicking through a real test order and watching the GA4 DebugView; if purchase fires twice, that’s the cause. The fix: find and remove the duplicate (usually a legacy GA4 snippet still living in the theme alongside a new GTM-managed snippet).
Why does the alert use a 30-day window? Can I see hourly?
The 30-day window smooths out daily noise so the alert only fires for sustained regressions, not single-day blips. For hourly visibility, use GA4 GTM Tag Fire, which compares hourly purchase events vs commerce orders. Property Health uses a 1-hour window for the same reason; this card uses 30 days.
My multi-currency store, does this card work?
Yes, both sides are converted to the GA4 property’s reporting currency using daily FX rates. For multi-currency stores GA4 is cleaner than the commerce platform in this dimension because GA4 normalises to one currency at event time; commerce platforms typically sum original-currency totals and need a separate conversion step. The gap calculation handles this correctly.
Does Klaviyo-attributed revenue contribute to GA4 here?
Yes. Every order with a purchase event contributes regardless of channel. Klaviyo’s email-attributed revenue claim is separate (different attribution model) and is reconciled in the Klaviyo email-attributed share cross-channel card, not here.
Can I trust today’s gap reading?
Less than the rolling 30-day. GA4 has up to 4-hour event-ingestion delay, plus today’s data is incomplete. Wait until the day rolls over before reading the daily figure. The 30-day window is the trustworthy view.
My GA4 gap is healthy but my GA4 channel mix changed dramatically, is the gap card lying?
No, channel mix can shift while the aggregate gap stays stable. Channel-mix shifts are tracked by Cross-channel: Ad Attribution Consistency, which compares GA4 channel attribution against Google Ads / Meta Ads first-party data. Use that card for channel-shift triage; this card only tells you the aggregate gap is healthy.