GA4 key events dropped to zero: what to check

When GA4 key events fall to zero, do not begin by rewriting the landing page or changing ad bids. First determine whether people stopped completing the action or whether the action stopped reaching GA4.

The fastest check is to put three independent observations beside one another:

Commercial outcome:  Stripe payments, new customers, or the applicable order ledger
Measured traffic:     GA4 sessions and users
Measured action:      the raw GA4 event and its key-event count

If commercial outcomes and sessions continue while one GA4 action disappears, a measurement break is more plausible than a sudden collapse in demand. That is still a hypothesis: the records are associated by period unless a deterministic identifier connects them.

Read the shape of the zero

Not every zero points to the same failure. Match the observation to the first explanation worth testing:

• Sessions, raw events, and all key events are zero: wrong property, missing tag, consent change, or sitewide collection failure.
• Sessions continue, but one raw event is zero: the event trigger, route, checkout, form, or tag-manager release broke.
• The raw event continues, but its key-event count is zero: the event is no longer marked as a key event, or the report is scoped incorrectly.
• DebugView receives the event, but standard reports do not show it yet: processing delay, report scope, filters, or thresholding.
• GA4 actions and commercial outcomes both decline: a real funnel or demand problem is possible; continue the business diagnostic.

This gives you an investigation order, not a verdict. Consent, ad blocking, low volume, delayed payment completion, and implementation differences can affect each branch.

Google defines a key event as a collected event that the property has marked as particularly important. That creates two separate questions:

1. Did GA4 receive the underlying event?
2. Did GA4 count it as a key event?

Do not collapse those questions into “conversion is broken.”

Run the ten-minute verification path

Work from independent evidence toward the tag implementation.

1. Confirm the business outcome

Check the system that owns the real outcome. For a Revinho workspace, Stripe is the revenue and customer truth. Compare successful payments, new customers, refunds, and net revenue with the last complete equivalent period.

Do not compare GA4 key events directly with MRR. MRR is a subscription snapshot, while a key event is an analytics action. Use the commercial fact closest to the event: a new paid customer for a completed signup, or a successful payment for a purchase event.

If the commercial outcome also fell, the incident may be real. If it continued, measurement becomes the leading hypothesis—but not proof.

2. Check whether GA4 traffic also disappeared

Compare sessions and users across the same complete dates. Then split the movement by page, source, country, and device.

• If all GA4 traffic vanishes on one date, inspect the property ID, sitewide tag, consent behavior, and release history.
• If traffic remains but the action disappears, move downstream to the event trigger.
• If only one page, device, or browser segment is affected, reproduce that path before touching the global setup.

Google's tag-setup troubleshooting guide lists missing or incorrectly installed tags, an incorrect tag ID, unpublished Tag Manager changes, absent traffic, and unfinished processing as distinct causes. Keep them distinct in your incident notes too.

3. Look for the raw event

In GA4, inspect the underlying event by its exact name. Event names are contracts: sign_up, generate_lead, and purchase are not interchangeable, and a renamed event creates a new series.

Check whether the event count stopped on the same date as the key-event count. If the raw event still appears but key events do not, skip tag debugging for the moment and audit the key-event configuration.

4. Test one real journey live

Use Google Tag Assistant to confirm that the intended Google tag is detected and sends the event. Then enable debug mode and inspect GA4 DebugView while completing the journey yourself.

Record four facts:

page or route tested
tag and GA4 property ID detected
event name and important parameters sent
time the event appeared in DebugView

Test the success condition, not just the button. A click event can fire even when account creation or payment later fails. For a purchase, also confirm that retries or page refreshes do not send duplicates.

If this followed Shopify's August 2026 checkout upgrade

The current Shopify deadline is specific and easy to misstate.

Shopify says non-Plus stores must upgrade deprecated Thank You and Order Status pages by August 26, 2026. Its official upgrade guide says existing incompatible apps, additional scripts, and pixels must be replaced with compatible blocks, web pixels, or app pixels. Stores that do not upgrade are auto-upgraded after the deadline.

Shopify's current GA4 setup instructions direct merchants to install the Google & YouTube sales channel and follow Google's Shopify tag setup. Meanwhile, Google's own troubleshooting documentation still describes both gtag.js and Google Tag Manager as supported installation routes. The accurate conclusion is:

Shopify is replacing a deprecated checkout-page customization surface. Google is not generally sunsetting Google Tag Manager.

Before the Shopify upgrade:

1. Open Settings → Checkout and review the generated upgrade report.
2. Inventory every analytics or advertising script on the old Thank You and Order Status pages.
3. Confirm which installed apps are compatible and which scripts need an app pixel, web pixel, or replacement app.
4. Record the GA4 property, event names, transaction identifiers, and current baseline.

After the upgrade:

1. Place a test order using Shopify's supported test flow.
2. Verify the new event once in Tag Assistant and DebugView.
3. Check that the transaction is not sent through both the old and new paths.
4. Compare the first complete post-change day with the baseline and annotate the deployment time.

Revinho does not currently ingest Shopify order data. If Shopify is your commercial ledger, validate orders there or in the payment processor. The Stripe comparison in this Guide applies only when connected Stripe data owns the outcome you are investigating.

Audit the event-to-key-event boundary

When the raw event continues but its key-event count does not, inspect configuration before code.

Verify that:

• the exact event is still marked as a key event;
• the expected property and data stream are selected;
• the event name did not change in a recent release;
• report filters and comparisons include the intended event;
• the key-event counting method still matches the business question;
• the key-event setting existed throughout the period being compared.

Google's current Data API schema notes that marking an event as a key event affects reporting from that point forward; it does not rewrite historical data. Toggling the setting inside a comparison window can therefore manufacture an apparent collapse or recovery.

Do not repair that history in a spreadsheet and present it as provider data. Record the configuration change, preserve the gap, and restart interpretation from the first complete period with a stable definition.

Check releases, consent, and route ownership

If the event itself stopped, work backward from the first missing timestamp.

Look for changes to:

• tag-manager container versions or direct tag snippets;
• single-page-app navigation and success-route rendering;
• checkout provider, form provider, or authentication callbacks;
• consent-management defaults and regional rules;
• Content Security Policy, script loading, or ad-blocker behavior;
• event names, parameters, transaction IDs, or trigger conditions;
• domain, subdomain, redirect, or cross-domain configuration.

An annotation at the same time as the drop is a strong lead, not causal proof. Reproduce the affected path or isolate the affected segment before blaming the release.

Allow for processing without waiting to investigate

GA4 standard reports are not live incident consoles. Google's data-freshness documentation says processing can take 24–48 hours and recent report data can change. Realtime and DebugView are faster but expose narrower evidence.

Use both time horizons:

• Now: Tag Assistant and DebugView answer whether one controlled journey sends the event.
• After processing: complete daily reports answer whether production traffic recovered across segments.

Exclude the incomplete current day from period comparisons. If yesterday is still moving, keep the incident open until the provider's reporting window settles.

Work through one example

Suppose a seven-day comparison shows:

                              Previous 7d   Current 7d
GA4 sessions                        3,200        3,150
GA4 sign_up event count               164            0
GA4 sign_up key events                164            0
Stripe new customers                   42           39
Stripe net revenue                 €8,400       €8,100

Sessions changed by -1.6%, Stripe new customers by -7.1%, and net revenue by -3.6%, while the measured signup event fell 100%.

That pattern does not prove that 39 Stripe customers came through the missing GA4 path. It does show that commercial outcomes continued during the same period while one analytics event vanished. The rational next action is to test event delivery and the release boundary, not redesign acquisition.

Now suppose Tag Assistant detects the correct property but DebugView never receives sign_up. The problem is upstream of key-event classification. If DebugView receives sign_up and standard event reports later show it while the key-event column remains zero, investigate the classification and report scope instead.

Use this decision path

GA4 key events dropped to zero
|
+-- Did the applicable commercial outcome continue?
|   +-- Yes -> measurement failure becomes more plausible
|   `-- No  -> investigate the real funnel and measurement in parallel
|
+-- Did GA4 sessions also disappear?
|   +-- Yes -> check property, sitewide tag, consent, and processing
|   `-- No  -> inspect the specific raw event
|
+-- Did the raw event continue?
|   +-- Yes -> check key-event marking, counting, filters, and dates
|   `-- No  -> reproduce the journey with Tag Assistant and DebugView
|
`-- Does the live test send the event?
    +-- Yes -> inspect production segments and wait for settled reports
    `-- No  -> fix the narrow trigger, route, checkout, or tag release

The tempting but misleading conclusion is “conversions stopped.” The evidence may only say “GA4 stopped counting a configured key event.” Preserve that distinction until the commercial system and a live journey agree.

What Revinho automates—and what still needs judgment

Revinho compares sessions, users, configured GA4 key events, Stripe revenue, and Stripe customer outcomes across equivalent complete periods. Growth and Pages can narrow GA4 evidence by acquisition and page dimensions, while saved Funnels query journeys already configured in the connected property. Deterministic rules can surface a falling visitor-to-key-event rate or a page gaining traffic while losing key-event efficiency.

Those views can reveal the shape and timing of a break. They do not inspect browser requests, change GA4 configuration, repair tags, or prove that a Stripe outcome belongs to a specific session. Cross-source context remains associated unless a deterministic join exists. See the Revinho evidence and attribution methodology for that boundary.

A responsible incident note sounds like this:

GA4 sessions remained within 2% of the previous period, while the sign_up event and its key-event count fell to zero on August 18. Stripe recorded 39 new customers during the same seven days. The evidence is consistent with a GA4 measurement break, so we are testing the signup success path and the August 18 release before changing acquisition or conversion strategy.

That statement is cautious, testable, and useful. It names what disappeared without pretending the first chart already explains why.