![\"Two](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/wartungsmodus-en.png\")
What maintenance mode means in practice<\/h2>\n
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.<\/p>\n
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.<\/p>\n
The three differences that matter<\/h2>\n
The first is authentication. The Measurement Protocol works with an 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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 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.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" Google put the Measurement Protocol into a finalized state in June 2026: no deprecation, no new features. The Data Manager API takes over, with OAuth instead of an api_secret, several destinations per request and encrypted identifiers – and an allowlist in front of it.<\/p>\n","protected":false},"author":1,"featured_media":11518,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[91261,91258,91392],"class_list":["post-10557","post","type-post","status-publish","format-standard","hentry","category-digital-analytics","tag-conversion-tracking","tag-google-analytics-4","tag-rest-api"],"yoast_head":"\napi_secret<\/code> 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<\/code> scope. The shared secret disappears, and the authorisation can be bound to a service account and revoked individually.<\/p>\nThe same task, two routes\n\n Measurement Protocol\n POST \/mp\/collect?measurement_id=G-\u2026&api_secret=\u2026\n one endpoint, one destination, secret in the query\n identifiers in clear text or hashed\n\n Data Manager API\n REST or gRPC, OAuth 2.0, scope \"datamanager\"\n one call, several Google destinations\n up to 10 identifiers per record, XChaCha20-Poly1305\n\n access: currently through an allowlist<\/code><\/pre>\nWhat argues against switching immediately<\/h2>\n
api_secret<\/code> in an environment variable has none of those requirements – which is simultaneously its weakness and the reason the existing integration needs so little care.<\/p>\nWhen the switch pays for itself<\/h2>\n