GA4 is free, everywhere, and quietly wrong in the exact ways that matter when you are making commerce decisions. It samples, it lags a day or two, it drops sessions to consent and bot filtering, and it fundamentally does not know your order truth — it knows what a browser told it. The fix is not to rip it out; it is to run a first-party event pipeline beside it that you own end to end, and to join those events to the orders in your own database. This is the stack we run, and the reasons each piece exists.
Why GA4 alone under-reports
GA4 is a fine top-of-funnel instrument and a poor system of record. Four properties trip up store owners who trust its numbers as truth:
- Latency. Standard reports lag roughly 24–48 hours; only the realtime view is instant. If you are debugging "did the change I shipped an hour ago help", GA4's daily tables cannot answer yet.
- Exclusions. Consent-denied visitors, bot and spider filtering, and internal/test traffic are all removed — usually correctly, but it means the count is a filtered sample, not a census.
- Thresholding and modelling. To protect privacy, GA4 withholds and models sparse data, so small segments can be blurry or blank.
- It never sees the order settle. A purchase event fires from the browser at checkout; a refund, a failed capture, or a payment that completes on a provider's page can all diverge from what GA4 recorded.
None of that makes GA4 useless — it makes it one witness. For anything you will act on financially, you want a second witness you control. The realtime-versus-report lag alone is why "low numbers" so often means "tracking is fine, you're reading a partial, delayed view", a trap we also flag in ecommerce observability.
A first-party event pipeline you own
The second witness is a first-party pipeline: your own endpoint receiving your own events, writing to your own database. The shape is unglamorous and durable — a session is initialised, then typed events stream in (product viewed, search performed, checkout step reached, page viewed), each landing in a table you can query directly. Because it is first-party and server-received, it is resilient to the ad-blockers and third-party cookie loss that erode GA4, and it is consent-aware on your terms. Two design rules matter: make ingestion idempotent (clients retry, so dedupe on an event id) and gate behavioural events on consent exactly as GA4 is gated, so the two witnesses agree on who they are allowed to count.
The event schema that pays off
Keep the schema small and join-friendly. Every event carries a session id; commerce events also carry the domain key that lets you reconcile against reality later.
| Event family | Fires on | Key fields | Answers |
|---|---|---|---|
| Session | First interaction | session id, source/UTM, consent state | Where traffic comes from |
| Product | PDP view, add to cart | session id, product SKU | What gets looked at vs bought |
| Search | Query + result click | session id, query, result rank | Zero-results, skipped position one |
| Checkout | Each checkout step | session id, step, order id | Where carts stall |
Note the search family keys on the product's SKU, not a transient web id, so it survives re-indexing — and it feeds the query-to-click join we detail in site-search analytics. The point of a shared session id on every row is the join in the next section.
The order-to-session join: true attribution
The single highest-value thing a first-party pipeline unlocks is joining a completed order back to the session that produced it. Stamp the order's identifier onto the session (and vice versa) at checkout, and suddenly you can answer questions GA4 structurally cannot: which article drove the session that led to this purchase, which search query preceded it, how long the consideration took, and whether the customer had visited before. This is real attribution built on your own records rather than a modelled, sampled guess — and because it is anchored to the order that actually settled, it reconciles with your bookkeeping rather than fighting it. It is also the spine that lets session replay jump straight to "the recording of this failed checkout", as covered in session replay for ecommerce.
Verify impressions in the database, not the browser
Some of our counters — like product-card impressions from content embeds — are recorded by an endpoint that is internal-only by design: hit it from outside and it returns 404, on purpose. The reason is a hard-won one. Client-side impression counting lies constantly: ad-blockers drop the beacon, viewability observers never fire in a hidden or backgrounded tab, prefetching double-counts. When we need the real number, we do not open a browser and watch — we read the row in the database. The instrumentation is client-side; the source of truth is server-side. Confusing the two is how teams end up "optimising" against a metric that never reflected reality.
The general rule that falls out of this: any metric you will make money decisions on should be verifiable in a store you control, not inferred from a beacon that a dozen things can silently swallow. Browsers are lossy narrators. Your database is the ledger.
Content-to-commerce attribution
If your commerce lives next to content — articles, a blog, a media site sending buyers to a storefront — the pipeline is what proves the content is working. Tag in-content links and embeds with a campaign parameter, record the resulting impressions and clicks first-party, and carry the session through to the order join. Now "this article produced these carts and this revenue" is a query, not a hopeful correlation. That measurement is exactly what makes the content-to-commerce model defensible, and it is the KPI backbone behind the numbers in marketplace KPIs. GA4 gives you the shape of the funnel; your own events give you the receipts.
Key takeaways
- Treat GA4 as one witness, not the system of record — it lags 24–48 hours, filters consent and bots, models sparse data, and never sees the order settle.
- Run a first-party event pipeline you own — your endpoint, your database, idempotent and consent-gated, resilient to ad-blockers and cookie loss.
- Put a session id on every event and the order id at checkout so you can join a purchase back to the session, search and content that produced it.
- Verify money-decision metrics in the database, not the browser — client-side impression counts are lossy; the server row is the truth.
- Key commerce events on stable ids like SKU so the data survives re-indexing and reconciles with bookkeeping.
- Tag content links first-party to turn "this article drives sales" from a hope into a query.
Frequently asked questions
Is GA4 accurate enough for ecommerce?
What is a first-party analytics pipeline?
How do I attribute an order to the session that produced it?
Why don't my GA4 numbers match my order count?
Own your numbers, not just your traffic.
The marketplace we run for you ships GA4 plus a first-party event pipeline with the order-to-session join already wired.
Request early access See the live marketplace →