Why does my purchase event show in DebugView but not in reports?

DebugView shows events in real time; standard reports can take 24–48 hours to process. If DebugView shows the event with correct parameters, your tracking is working — wait a day before concluding anything is broken. Realtime reports are the middle ground: they update within minutes.

Does GA4 deduplicate purchase events?

Yes. If GA4 receives two purchase events with the same transaction_id from the same user, it keeps the first and discards the second. If your confirmation page can be reloaded or revisited, this is working as intended — but if your transaction_id generation is broken (e.g., every order sends the same ID), nearly all purchases get silently dropped.

Can consent mode block purchase events?

Yes. With Consent Mode v2, if analytics_storage is denied, GA4 either drops the hit or sends a cookieless ping depending on your configuration. If your consent banner defaults to denied and users complete checkout without interacting with it, your purchase events can quietly disappear for that whole segment.

Do I need the items array for a purchase event to count?

The purchase event will be recorded without items, but revenue and item-level reports will be empty or wrong. If purchases appear in event counts but ecommerce reports show no revenue, a missing or malformed items array (or missing currency/value parameters) is the usual cause.

How do I test a purchase event without making real purchases?

Use GTM Preview mode plus GA4 DebugView on a test order (many stores support 100% discount codes or a payment sandbox). Avoid testing only on staging — cross-domain settings, consent tooling, and payment redirects often differ from production, which is exactly where purchase tracking breaks.

How does Kickin catch this before I do?

Kickin learns how often your purchase event normally fires in GA4 and Meta, then alerts you when it stops or falls out of sync with the other tracker. A purchase event that dies after a deploy or a consent-tool update becomes an incident within minutes instead of a surprise in next month's reporting.

GA4 purchase event not firing? Find the cause fast

Missing purchase events are the most expensive tracking failure there is — every ad platform and report downstream depends on them. Seven causes account for nearly every case. Check them in this order.

8 min read

First: is it actually broken?

Before debugging, rule out the two situations where nothing is wrong. Standard GA4 reports lag 24–48 hours behind reality, so a purchase made this morning legitimately won't show in yesterday-style reports yet. And GA4 deduplicates by transaction_id, so a re-sent test order with a reused ID is dropped by design.

The fast check: open Reports → Realtime and make a test purchase. If purchase appears there with the right parameters, your tracking works and you were looking at processing lag. If it doesn't appear, keep reading.

The seven causes, in the order to check them

The first three are configuration problems you can see in your tag manager. The last four are environmental — they only show up on real production checkouts.

The tag trigger no longer matches the confirmation page

The single most common cause after a site change. Your GTM purchase tag fires on a trigger — a URL pattern like /order-confirmation, a dataLayer event, or an element click. A checkout redesign, a URL change, or a renamed dataLayer event silently orphans the trigger. The tag is still there; it just never fires.

Fix: Open GTM Preview, complete a test purchase, and watch whether your purchase tag shows under "Tags Fired" on the confirmation step. If it shows under "Tags Not Fired," inspect which trigger condition failed.

The dataLayer push happens after the tag reads it

On many stores, the platform pushes the ecommerce object to the dataLayer asynchronously. If your tag fires on page load but the purchase data arrives a moment later, the tag sends nothing — or sends an event with no transaction data.

Fix: Trigger the tag on the specific dataLayer event that carries the ecommerce object (e.g., purchase or a platform-specific equivalent), never on page load. In GTM Preview, check the dataLayer tab at the moment your tag fired.

Duplicate or broken transaction_id generation

GA4 keeps the first purchase event per transaction_id and silently discards repeats. If a bug makes every order send the same ID — or your confirmation page re-fires the event on every reload with the same ID counted once — reported purchases fall far below actual orders with no error anywhere.

Fix: Compare purchase counts in GA4 against your order database for the same period. If GA4 is consistently lower by a similar percentage, sample a few orders and verify each sent a unique transaction_id.

Consent mode suppresses the hit

With Consent Mode v2, denied analytics_storage means dropped or anonymized hits depending on configuration. Users who complete checkout without touching the consent banner can default to denied — making purchases invisible for exactly the users most focused on buying.

Fix: Test a purchase in a fresh browser profile without interacting with the consent banner. If the event fires only after accepting, review your consent tool's default state and whether "denied until interaction" is really what you intend.

The payment flow never reaches your confirmation page

External payment redirects (PayPal, Klarna, bank redirects, 3-D Secure) sometimes return users to an app, close the tab, or land on a processor-hosted receipt. Your confirmation page — and the tag on it — never loads for those orders.

Fix: Segment missing purchases by payment method in your order database. If one method dominates the gap, fire the purchase server-side from the payment webhook (the processor tells your backend about every completed payment, browser or not).

Ad blockers and privacy browsers drop the request

A meaningful share of buyers use browsers or extensions that block google-analytics.com requests outright. The tag fires; the network request dies. This loss is invisible in tag manager previews because your own browser isn't blocking anything.

Fix: This is a floor you can't fix client-side. Server-side tracking via the GA4 Measurement Protocol recovers these purchases — the event goes from your backend to Google directly.

The event fires but the payload is malformed

A purchase with no currency, a value sent as a string, or a missing items array is accepted by GA4 but produces empty revenue reports — which reads as "purchases not tracked" even though events arrive.

Fix: In DevTools, filter Network for "collect", complete a test purchase, and inspect the request payload: en=purchase should be accompanied by currency, value, and item parameters. Fix whatever the payload is missing at the dataLayer source.

The 15-minute diagnosis

Step 1: Realtime report + test purchase

Open Reports → Realtime, complete a test order, and watch for the purchase event. Appears with correct parameters: you have processing lag or a reporting question, not a tracking failure. Doesn't appear: continue.

Step 2: GTM Preview on the confirmation step

Run GTM Preview through the full checkout. Check whether the purchase tag fired, which trigger matched (or didn't), and what the dataLayer contained at that moment. This catches causes 1, 2, and 7.

Step 3: Network tab, filtered to "collect"

On the confirmation page, verify the actual GA4 request left the browser with en=purchase and full ecommerce parameters. A fired tag with no network request points to consent mode or a blocker (causes 4 and 6).

Step 4: Compare GA4 against your order database

Pull a week of orders and compare with GA4 purchase counts. A consistent percentage gap suggests blockers/consent (expected: roughly 5–20%). A gap concentrated in one payment method points to redirect flows (cause 5). Near-total loss points to triggers or transaction_id bugs.

Catching the next break before it costs you

Whatever caused this break, the uncomfortable part is how long it ran before anyone noticed — purchase tracking usually dies quietly during a deploy, a consent-tool update, or a checkout change, and surfaces weeks later as "why did ROAS fall off a cliff?"

Kickin watches your purchase event continuously across GA4 and Meta. When it stops firing — or keeps firing in one platform but not the other — you get an alert within minutes, with the affected pages and the last time the event was seen.

FAQ

Frequently Asked Questions

Never lose a week of purchase data again

Kickin alerts you within minutes when your GA4 or Meta purchase event stops firing.