Frozen, Not Switched Off

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.

Translated, that means nothing is being switched off and nothing is being added. This is not a deadline but a fork – and forks demand a decision at a moment nobody sets.

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 is the reach of a single request. The Measurement Protocol speaks to Google Analytics. Google Ads or Display & Video 360 require a different interface with its own schema, its own authentication and its own error handling. The Data Manager API brings those destinations under one data model; a single event can go to 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

  access: currently through an allowlist

What argues against switching immediately

Access to the Data Manager API runs through an allowlist. For a portion of users the migration is therefore not a decision at all but a queue, and a plan built on access not yet granted is not a plan.

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.