GA4's Measurement Protocol is in maintenance mode — what changed, and why "own your data" shouldn't mean re-plumbing every 18 months
Is the GA4 Measurement Protocol deprecated? No. Google's own docs describe it as a "mature, finalized product" with "no future enhancements planned" — that's maintenance mode, not a death sentence. There is no sunset date, and Google says plainly it "will remain operational." If you're running server-side hits through it today, they'll keep working. Anyone telling you the Measurement Protocol is dead or being killed is wrong.
What is true is that the Measurement Protocol has stopped evolving, and Google is steering all new data ingestion toward a different pipe — the Data Manager API, which launched 9 December 2025. Around it, 2026 brought a cluster of forced-migration deadlines for anyone importing conversions or audiences into Google Ads. So the honest answer to "what do I do?" is: nothing is shutting off, but if your reason for going server-side was to own your data and stop depending on Google, the last twelve months are a case study in why that reasoning doesn't hold. This post lays out what actually changed and what it costs.
What "maintenance mode" actually means
Maintenance mode is a specific, boring status, and it's worth reading it precisely rather than through the panic of a headline:
- The Measurement Protocol still works. Existing integrations keep sending hits.
- No new features are being added to it. It is frozen at its current capability.
- There is no announced sunset. Google has not set a shutdown date and states it stays operational.
That's the whole of it. "Frozen for new features" is not the same as "deprecated," and the distinction matters because it changes what you should do. You don't need an emergency migration off the Measurement Protocol. What you do need to know is that every capability Google adds from here lives somewhere else — and getting to that somewhere else is where the work is.
The Data Manager API and the 2026 deadline cluster
The Data Manager API is Google's consolidated ingestion endpoint for conversions, Customer Match audiences, and analytics events. It's a genuine product with real momentum: version 1.6 (7 May 2026) added store-sales conversions and expanded analytics event ingestion, and v1.7 followed shortly after, pulling the Google Marketing Platform into the same signal loop.
The catch for existing GA4 and Google Ads users is that the older paths didn't just stay put while the new one grew. They were switched off on a schedule. Three deadlines landed within four months of each other:
| Date | What changed | Who it hits |
|---|---|---|
| 2 Feb 2026 | Ads API stopped accepting new adopters for session attributes + IP-address data in conversion imports | Anyone starting a fresh conversion-import integration |
| 1 Apr 2026 | Customer Match uploads via the legacy Ads API (OfflineUserDataJobService / UserDataService) disabled for new and dormant (180-day-inactive) integrations — developers notified 4 Mar 2026 |
New or long-idle audience-upload pipelines on the old services |
| 15 Jun 2026 | New offline-conversion imports via the Ads API blocked — must use the Data Manager API | Teams wiring up offline/CRM conversion imports |
None of these is the Measurement Protocol being sunset. But look at the pattern: three separate forced migrations in one year, each with its own cutover date and its own "developers were notified on X" scramble. If you built on the old paths, the ground moved under you three times. That's the real story here — not a shutdown, but churn.
The catch: server-side GA4 still needs the client-side pixel
Here's the part that gets skipped, and it's the crux. A common reason teams invest in server-side tracking is independence: send hits from your own server, and you supposedly stop depending on Google's client-side tag. For web streams, that's not what happens.
Even on the "future-proof" Data Manager API path, sending server-side events for a web stream still requires the client-side GA4 tag to mint the client_id first. The server can't fabricate a valid client_id out of nothing; it needs the value the browser-side pixel generates. So you keep the pixel and you build and maintain the server-side pipeline on top of it. You've added migration complexity without buying the independence you were after.
In one line: server-side GA4 does not let you remove the client-side pixel — the Data Manager API path for web streams still depends on the client-side tag to generate the client_id. "Own your data" via server-side GA4 is, for web analytics, a pipeline you run in addition to Google's tag, on Google's schedule, feeding Google's systems.
The honest contrast
Let me be fair about where server-side ingestion genuinely earns its keep, because "GA4 is useless" is not the claim. If you're a large advertiser doing ad-conversion measurement — matching offline sales back to ad clicks, uploading Customer Match audiences, feeding conversion signals to bidding — server-side ingestion through the Data Manager API is legitimately the right tool, and there isn't really a privacy-first substitute for that job. If you need to send conversion data to ad networks, that's exactly where GA4 and the Data Manager API belong. Simplytics does not do that. It sends no data to ad networks and does no ad-conversion measurement. That's a real trade-off, and it's the whole point of the design.
The contrast is narrower and more specific: it's about churn and what "own your data" actually costs. If your goal is to understand your own site's traffic and keep control of it, a cookie-less, aggregate-only tool has nothing in the paragraphs above to migrate. There's no Measurement Protocol, no Data Manager API version to track, no client_id to mint, no conversion-import service being switched off in April, no offline-import cutover in June. The difference between keeping raw records and keeping only aggregates is the whole reason: Simplytics discards raw visit records nightly and keeps anonymous aggregates forever, so there's no user-level pipeline to re-plumb in the first place.
And this isn't the only place GA4 keeps shifting under its users. The same month brought a change to GA4's Google Signals and consent controls — a separate reconfiguration on a separate timeline. "Own your data" sold as server-side GA4 tends to mean re-checking settings and re-plumbing pipes every time Google reorganizes, which lately is often.
What you get instead, with an aggregate-only tool, is a data model that doesn't change under you: a plain GET /api/v1/stats/:domain Stats API and per-dataset CSV export. You read your numbers, you export them, and next quarter the schema is the same. Nothing to migrate is a feature.
The bottom line
The GA4 Measurement Protocol is not deprecated — it's frozen, no new features, no sunset, still running. But the surrounding ecosystem moved three times in 2026, the future lives in the Data Manager API, and even that "own your data" path can't remove the client-side pixel for web streams. If you need server-side ad-conversion measurement, that's the road, and it's a fine road for that job. If you just want to own your site's numbers without re-plumbing your analytics every eighteen months, the winning move is to not build a pipeline that needs re-plumbing.
The one-line summary: server-side GA4 is churn you manage on Google's calendar and still can't escape the pixel; a cookie-less, aggregate-only tool has nothing to re-migrate — which is why the cheapest privacy-friendly Google Analytics alternative gives you a lot of functionality for a lot less money, at $1/month versus the $9–15/month competitors.