Before diagnosing anything, establish whether traffic fell or whether measurement did. Those are different emergencies, and the shape of the drop tells you which: a vertical cliff is almost always tracking, a slope over days is almost always real. That distinction takes about ten minutes and eliminates most of the search space.
The instinct when a chart falls 40% overnight is to start changing things. It is the worst available move, because a tracking break and a demand collapse look identical in the report and need opposite responses. What follows is the order to check in, arranged so the cheapest and most likely causes are ruled out first.
The newsletter
Join our KISS newsletter
One short read a week on what actually moves revenue, in a free email. Read by 10,000+ operators and founders.
No spam. Unsubscribe in one click.
I.The shape of the drop names the cause
Two facts before any hypothesis: is it real, and what does the curve look like. Together they eliminate most causes for free.
A.Check a source that cannot be blocked
GA4 is a client-side measurement of reality, not reality. The first question is whether the thing being measured moved or the measurement did, and answering it requires a source with a different failure mode.
Server logs, CDN request counts and orders in the billing system all qualify. None depends on a script executing in a browser, so none can be affected by a broken tag, a consent decision or an ad blocker.
If revenue is flat and GA4 is down 40%, you have a measurement incident. That is a different investigation from a demand incident and a far more common one. Establish it in the first ten minutes, because the alternative is a week of emergency meetings about a chart.
B.Find the exact hour, then read the curve
Switch to an hourly view and locate the precise moment. The shape of the transition is the most informative single piece of evidence available and it costs one report.
A vertical cliff, normal to near-zero inside an hour, is a tracking break. Human demand does not do that. Something stopped firing.
A step down that holds, losing a consistent share and then running flat, is usually a filter, a consent change, or one broken page template. Part of the site stopped reporting and the rest carried on.
A slope over several days is real: an algorithm update, seasonality, a competitor, or genuine loss of demand.
C.Read the change log before the data
With the hour established, ask what happened in the 48 hours before it. Deployments, tag manager publishes, consent platform updates, CMS changes, DNS changes.
This is the highest-yield step in the process and it gets skipped because it feels less rigorous than analysis. In practice a timestamp in a deploy log matching a timestamp in a traffic chart is the answer more often than any query will be.
II.Three families, and the diagnostic that separates them
Tracking, privacy, demand. Each leaves a signature in the segments, and reading segments is faster than reading code.
A.Tracking failures
The most common family and the fastest to confirm. A tag manager publish removed or broke a tag. A deployment changed the data layer so variables resolve as undefined. A new third-party script throws before the analytics snippet runs, or a Content Security Policy update blocks the request outright.
Signature: the drop is total or near-total, starts on an exact boundary, and affects all segments equally. Realtime shows nothing.
Confirm: load the site with the browser console open and watch for the outbound request. If it is not being sent, no report configuration is relevant. Related: tags fire in GTM preview but GA4 does not record them.
B.Privacy and consent
A consent banner changed its default, a browser shipped stricter tracking prevention, or your audience's blocker usage moved. These reduce collection without breaking anything.
Signature: partial, and uneven across segments. It concentrates by browser, by region, and by audience technical sophistication. Safari and Firefox fall further than Chrome. European regions fall further after a consent change.
Confirm: segment by browser and by country. A cause that is invisible in one segment and severe in another is not a broken tag, because a broken tag does not know which browser it is in. Our breakdown of ad blocker impact covers sizing your own share.
Which family, read from the segments
Diagnosis view| Evidence | Tracking | Privacy | Demand |
|---|---|---|---|
| Shape of the transition | Vertical cliff | Step or slope | Slope |
| Across browsers | Equal | Very uneven | Equal |
| Across regions | Equal | Uneven | Often uneven |
| Across channels | Equal | Fairly equal | Concentrated in one |
| Did revenue move too? | No | No | Yes |
| Realtime | Empty | Reduced | Reduced |
C.Filters, bots and processing
A smaller family, worth ruling out because the fixes are trivial where they apply.
An internal traffic filter applied too broadly removes legitimate sessions. A newly activated developer filter does the same. Improved bot filtering removes traffic that was never human, which reads as a drop and is actually a correction: if your volume fell and your conversion rate rose, you probably lost bots rather than customers. See identifying and filtering bot traffic.
Processing delay is the trivial case. Data can lag by many hours, so a drop confined to the last day or two may simply not have finished arriving. Never diagnose on today.
4.Genuine demand loss, and why it comes last
Reachable only once the first three are excluded, which is the point of the ordering.
Signature: revenue moved with it, the decline is a slope, and it concentrates in one channel. Organic falling while paid and direct hold is a search visibility problem. Everything falling together is more likely seasonal or macro.
Check Search Console independently. It measures impressions and clicks at Google's end and is unaffected by anything happening in a browser, so a drop visible in GA4 but not in Search Console clicks is, once again, a measurement incident.
5.The iOS and Safari case, stated carefully
A recurring version of this question is why iOS traffic looks systematically low. The mechanisms are real and documented by Apple: Intelligent Tracking Prevention caps client-side cookie lifetimes, iCloud Private Relay masks originating IP and referrer for subscribers, and App Tracking Transparency requires opt-in for cross-app tracking.
The effect worth understanding is not a missing visit but a duplicated person. When a cookie expires between visits, a returning user is recorded as new, so returning-user metrics degrade faster than session counts do, and anything person-level built on top of them degrades with it.
We are deliberately not quoting a percentage here. The figures circulating for iOS undercounting vary widely by audience and none that we can trace states its sample or its date. Measure your own gap against server logs instead; the method is in what your analytics hides.
III.Recovering, and deciding what was never lost
Some of it returns, some was never there, and some is permanently gone. Treating all three alike is how a drop becomes a wasted quarter.
A.What is recoverable
A tracking break is fully recoverable forwards and not backwards. Fix the tag, verify the request, and numbers return from that moment. The hole in the history is permanent, so annotate it in the property, because in eleven months somebody will build a year-over-year comparison straight across it.
Filter and bot changes are reversible. Whether to reverse them is a separate question: if bot filtering removed traffic that was never human, the lower number is the accurate one and the right response is to rebase the target rather than restore the inflation.
B.What is not
Consent and blocker losses are structural. The events were never sent and no configuration retrieves them. Measure the size of the gap, apply a multiplier when reporting, and stop treating the collected number as the whole picture.
Algorithm losses may or may not return and are not an analytics problem. The useful analytics contribution is establishing exactly which pages and which queries lost, so the content response is targeted rather than general.
C.The structural version of this problem
Notice what made every step here possible: a second source that fails differently. The entire diagnosis is a comparison between something client-side and something that is not.
Kissmetrics captures events itself rather than reading another tool's summary, and resolves them to a person rather than a session, which makes it a genuinely independent second count of the same conversions. When two systems disagree you can trace one specific person through both instead of arguing about totals. It scans your site and configures itself, so standing that second view up is a day rather than a project.
It does not make you immune. A consent decline blocks everything client-side equally, and any vendor suggesting otherwise is describing server-side collection with its own trade-offs. What it removes is the single-instrument failure, where the only thing you can measure with is the thing that broke.
Verdict
A sudden GA4 drop is a measurement incident until proven otherwise, and proving it takes ten minutes: check a source that cannot be blocked, find the exact hour, read the change log for the 48 hours before it.
The shape does most of the diagnostic work. A cliff is tracking, a step is a filter or a template, a slope is real. Segment by browser and region before touching any code, because a cause that varies by browser is not a broken tag. And when the loss turns out to be structural, rebase and report the multiplier rather than spending the quarter chasing events that were never sent.
This is part of GA4 problems and how to fix them, under traffic that is not real. The guide puts the rest of the pieces in order.
Continue Reading
How to Audit GA4 for Data Accuracy (And What to Do When the Numbers Don't Add Up)
If you have ever compared GA4 numbers to your backend and found a 20-40% gap, you are not alone. This guide provides a systematic audit process to identify where your data is leaking and what to do about it.
Read articleGA4 (not set) in Source/Medium: Causes and Fixes
Diagnosis takes an hour. Three of the six causes are configuration bugs that close permanently; the other three are browser policy, consent law and intermediaries rewriting your links, and no GA4 setting touches them.
Read articleGA4 Bot and Spam Traffic: How to Identify and Filter It
Bot traffic inflates your metrics and corrupts every downstream decision. GA4's built-in filters catch some of it, but sophisticated bots require a more layered approach.
Read article