English
Deutsch
PolskiGA4 Measurement Protocol in Maintenance Mode: What Changes and When the Data Manager API Is Worth Switching To
Contents
Google’s Measurement Protocol page has carried a notice since June 2026 describing an unusual state: the interface has reached a mature, finalized product state and will remain operational, with no plans for deprecation. For server-to-server integrations the Data Manager API is recommended instead, described as the central infrastructure for future data ingestion innovations.
In other words, nothing is being switched off and nothing is being added. There is no deadline for the decision: you have to choose when a move to the other interface makes sense.
What maintenance mode means in practice
An existing integration keeps running. Anyone currently backfilling orders from an ERP system or closed deals from a CRM into GA4 needs to touch nothing, and there is no date on which anything stops working.
What stops is development. Every future capability in server-side ingestion appears in the new interface. A setup resting on the Measurement Protocol therefore ages not by breaking but by having the environment around it gain abilities it cannot call on.
The three differences that matter
The first is authentication. The Measurement Protocol works with an api_secret sent along in the query – a long-lived secret inside a string, one that ends up in logs and is rarely rotated. The Data Manager API requires OAuth 2.0 with the datamanager scope. The shared secret disappears, and the authorisation can be bound to a service account and revoked individually.
The second difference is how many destinations a single request can reach. The Measurement Protocol sends data to Google Analytics. Google Ads or Display & Video 360 need another interface, with its own schema, authentication and error handling. The Data Manager API brings these destinations under one data model, so a single event can reach several of them in one request.
The third concerns identifiers. The new interface supports up to ten user identifiers per record and encryption with XChaCha20-Poly1305, whose key management can sit in Google Cloud or in AWS. For matched data that means the identifier leaves the premises encrypted rather than merely hashed.
The same task, two routes
Measurement Protocol
POST /mp/collect?measurement_id=G-…&api_secret=…
one endpoint, one destination, secret in the query
identifiers in clear text or hashed
Data Manager API
REST or gRPC, OAuth 2.0, scope "datamanager"
one call, several Google destinations
up to 10 identifiers per record, XChaCha20-Poly1305
allowlist: only for GA events with a transaction ID as an additional sourceWhat argues against switching immediately
Sending GA4 events with a transaction ID as an additional data source requires allowlist access in the Data Manager API. If that is the use case you need, migration has to wait for access. A migration plan cannot rely on access that has not yet been granted.
Added to that is the effort underestimated in every interface migration: OAuth demands a service account, key management, and a way of noticing expired authorisation before three days of conversions are missing. An api_secret in an environment variable has none of those requirements – which is simultaneously its weakness and the reason the existing integration needs so little care.
When the switch pays for itself
Three cases argue clearly for it. The first is a planned second integration: anyone about to deliver conversions to Google Ads as well would otherwise build a second integration beside the first and maintain two thereafter. The second is the handling of personal data – where identifiers leave the building, encryption with local key management is a different conversation with the data protection office than a hash is. The third is a new build, because starting an integration that does not yet exist on a frozen interface costs the same work twice.
Where none of these applies, waiting is defensible and even obvious. The notice on Google’s page is not a countdown. It is the statement that one interface is finished and the other is still being built, and that statement does not change by being read six months later.
Questions and answers
Why is an api_secret in the query string more than a cosmetic flaw?
Because a URL including its query string gets stored in many places nobody treats as a store for secrets: in the access logs of proxies and load balancers, in error messages, in monitoring tools and in the application’s own log output. Each of those places then holds the secret for as long as it retains its entries, often longer than the secret should be valid.
Anyone who knows the secret cannot read data from GA4 with it, but can write arbitrary events into the data stream. The damage is therefore not a data leak but distorted reports, and it surfaces late, because injected events look like genuine ones.
As long as the existing integration keeps running, the remedy is rotating the secret. GA4 allows several such secrets per data stream, listed in the stream settings as “Measurement Protocol API secrets”, so the rotation works by creating and rolling out a new one and deleting the old one only afterwards. OAuth 2.0 in the Data Manager API solves the same problem at the root, because access tokens are short-lived and do not sit in a URL.
Can both interfaces run in parallel during the migration?
Yes, as long as the same event does not travel both routes to the same destination; otherwise conversions appear twice in GA4. A clean approach is a split by destination, for instance GA4 staying on the Measurement Protocol while Google Ads is newly fed through the Data Manager API, or a hard switch per destination at a fixed point in time.
How does a broken or expired integration become visible before conversions go missing?
Differently for the two interfaces. The Measurement Protocol answers every request it receives with a success status, even when the event is malformed or discarded. Checking against the validation endpoint /debug/mp/collect reveals errors, but it belongs in development, not in every request. In operation, the only option is reconciliation: the number of events sent against the number that arrive in GA4.
With the Data Manager API, by contrast, missing or expired authorisation shows up as an error response. An alert on responses outside the success range is then enough to notice the problem at the first failure rather than through missing conversions, provided the integration evaluates the responses at all.
Related articles
