On September 1, a lot of people opened GA4 and saw nothing. Not a small dip. Zero sessions for the day, on properties that were plainly still receiving traffic. Dana DiTomaso flagged it publicly and read it correctly straight away, as a processing problem with the previous day's data rather than a collection problem. Barry Schwartz wrote it up the next morning at Search Engine Land. Google had not acknowledged it, and the Analytics status page said nothing at all.
The data was not lost. It was late. That distinction matters enormously to an engineer and not at all to the person who has to send a monthly report on the second working day of the month. Search Engine Land covered the outage while it was still unresolved, which is roughly when most teams were discovering it for themselves.
What actually happened on September 1
The visible symptom was uniform: standard reports returning zero for the current day, and in many accounts for the previous day as well. Sites with steady traffic, unchanged tags, and no deployment in the window were showing flat nothing. That uniformity is the tell. When a single property breaks, the cause is almost always local, a container change or a consent configuration or a bad release. When dozens of unrelated properties break in the same hour, the cause is upstream and you should stop touching your own setup immediately.
The correct diagnosis, offered early by DiTomaso, was that the platform was struggling to process the previous day's data rather than failing to collect the current day's. Those two failure modes look identical in the interface and could not be more different in consequence. Collection failures are permanent, because a hit that was never received is never recoverable. Processing failures resolve themselves, and the numbers backfill.
| SYMPTOM | LIKELY CAUSE | IS THE DATA RECOVERABLE | FIRST ACTION |
|---|---|---|---|
| Zero across many unrelated properties at once | Platform-side processing delay | Yes, it backfills | Stop investigating your own setup. Document and wait |
| Zero on one property only, others fine | Tag, container, or consent change on that site | No, uncollected hits are gone | Check recent deploys and tag manager versions immediately |
| Traffic present but attribution collapsed to direct | Referrer or parameter handling change | Partially. Sessions exist, sources do not | Compare against server logs and ad platform data |
| Realtime works, standard reports do not | Processing pipeline lag, collection is healthy | Yes | Use realtime as proof of collection and reassure stakeholders |
| Everything zero including realtime | Collection stopped. Usually local | No | Treat as an incident. Check the tag on a live page now |
Row four is the one worth memorising, because it is the cheapest reassurance available during an incident. If realtime is showing sessions while the standard reports show zero, collection is alive and you are looking at a delay. That single check turns a panicked morning into a documented one, and it takes about fifteen seconds.
What made this particular event awkward was the silence. No status page entry, no acknowledgement, nothing to link to when a stakeholder asked what was happening. The information that existed lived on a practitioner's social post and a trade publication, which is where a surprising amount of the operational truth about these platforms lives now.
Why Google Analytics missing data becomes a business problem so fast
Any other day of the month and this is an inconvenience. September 1 is not any other day.
The first of the month is when the previous month closes. It is when agencies pull client reports, when in-house teams assemble board packs, when performance bonuses get calculated against traffic and conversion targets, and when budget conversations for the next period start. A gap on the first is a gap in the artifact that a lot of people are about to make decisions from, and the deadline does not move because a vendor is having a bad day.
There is a second-order problem underneath it that is worse. Once a report has been sent with a hole in it, the hole is in the record. Somebody screenshots the chart. Somebody pastes the number into a spreadsheet that gets referenced for a year. The backfill arrives two days later and updates the platform, but it does not update the deck, the email, or the memory of the person who saw a scary number on Tuesday. We wrote about the same failure pattern in how visibility volatility should be reported, and the mechanism is identical here: unlabelled data outlives its context.
“Every number you send is quoted for longer than it is accurate. Date-stamp accordingly.”
The third problem is credibility, and it is the expensive one. A marketing team that cannot explain its own numbers on demand loses standing, and it loses it in exactly the meetings where budget is allocated. Saying the platform was down is true and it sounds like an excuse, unless you can immediately produce a second, independent view of the same period. Then it stops being an excuse and becomes a demonstration of competence.
The three sources of truth you should already have
Redundancy in measurement is not exotic and it is not expensive. Most teams already own two of these three and simply never wired them together.
The point is not to reconcile these to the decimal. They will never agree, and chasing agreement between measurement systems is a well-known way to burn a quarter of an analyst's year. The point is triangulation. Three sources that broadly agree on direction and magnitude give you a defensible answer when one of them goes dark, and that is the entire job during an incident.
| SOURCE | SURVIVES A PLATFORM-SIDE ANALYTICS STALL | COVERS PAID | COVERS ORGANIC | EFFORT TO SET UP |
|---|---|---|---|---|
| Server logs or server-side endpoint | Yes, fully independent | Yes, by parameter | Yes, by referrer | Medium. Engineering time |
| Search Console | Yes, separate pipeline | No | Yes, search only | Low. Already connected |
| Ad platform reporting | Yes, separate pipeline | Yes | No | Low. Already connected |
| Warehoused daily export | Yes, if the export already ran | Yes | Yes | Low to medium. One pipeline |
| A second client-side analytics tag | Sometimes. Shares the same blockers | Partially | Partially | Low, but least useful |
The bottom row is there because it is the first thing people suggest and the weakest answer. A second client-side tag shares most of the failure modes of the first: the same consent gate, the same ad blockers, the same browser restrictions. It protects you against one vendor's pipeline stalling and against nothing else. Server-side is where the real independence is, which is why it is the first thing we set up in a reporting and analytics engagement rather than the last.
A protocol for the next time Google Analytics is missing data
Write this down before you need it, because the whole value is in not having to think during the twenty minutes when three people are asking you what happened.
Notice how little of that is technical. Four of the five steps are communication and record-keeping, because that is where the actual damage happens. The engineering part of a processing delay resolves itself without you. The reputational part does not.
It is the same discipline we argued for when an answer engine changed underneath a citation report earlier this week. The failure mode is identical even though the platform is different: a number moved for reasons that had nothing to do with your work, and the only defence is a written protocol and an annotation layer you built before you needed one.
Do this before the next month closes
Three things, and none of them take a week.
Set up one daily export of the metrics your reporting actually uses into somewhere that is not the analytics vendor. Sessions, conversions and revenue by channel by day. If that feels too small to be worth building, that is the point: it is small, and it is the difference between rebuilding a monthly report in an hour and not being able to rebuild it at all.
Then write the incident protocol above into your team's runbook and give it an owner. Five steps, one page. The test of whether it works is whether a person who is not you can execute it while you are on a plane, which is roughly the scenario that produces every bad reporting outcome I have seen.
Last, add a standing footnote line to your monthly reporting template: data source, pull date, and known gaps. Most months it reads as boilerplate. The month it matters, it is the difference between a team that had an outage and a team that looks like it does not know its own numbers. That distinction compounds across a year of meetings, and it is worth more than another dashboard. If you want the outside read on where your measurement has single points of failure, that mapping is part of the first phase of any SEO engagement we start, and it usually turns up two or three gaps the team already suspected and had never written down.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Josh leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.