Measurement Protocol Is Done. What That Means for Your Server Container

Google added a banner to a documentation page in June and the analytics community lost a weekend to it. The banner said the Measurement Protocol was entering maintenance mode with no future enhancements planned.

The reading was that Google had quietly killed the thing everyone uses for server-side events. That reading was wrong, and the correction is more interesting than the panic was.

Google revised the wording within days. The current text on the Measurement Protocol overview says it has reached a mature, finalized product state and will remain operational with no plans for deprecation, while recommending the Data Manager API for new server-to-server event integrations.

So the protocol is not dying. It is finished. Nobody is adding anything to it again.

That distinction matters because it changes the question from "when do I have to migrate" to "when does migrating buy me something." Those have very different answers, and for a lot of setups the second answer is not yet.

Short version

The Measurement Protocol is not deprecated and nothing breaks today. Google has stopped developing it and points new server-to-server work at the Data Manager API instead.

If you run a standard server container, the GA4 tag inside it is not affected. That tag is tagging, not Measurement Protocol. What is affected is anything you built yourself: custom backend calls to /mp/collect, refund and subscription events, offline conversion uploads, CRM writebacks.

The real cost of migrating is not the payload. It is authentication. The Measurement Protocol takes an API secret in a query string. The Data Manager API takes OAuth. Where your container runs decides whether that is a twenty-minute change or a rebuild.

What this covers

What Google said and what people heard
Your GA4 server tag is not affected
What in your container is affected
The two paths, compared honestly
The auth change is the migration
Field mappings that catch people
The timing windows nobody reads
Deduplication behaves differently per product
What this does not change
Move now, or wait
Pre-flight checklist
Questions we get asked

What Google said and what people heard

Three things happened across the first half of 2026, and conflating them is where the confusion started.

Google expanded the Data Manager API to accept Google Analytics web and app stream events, positioning it as an alternative to the Measurement Protocol for recommended and custom events. Separately, Google blocked new offline conversion imports through the Google Ads API from 15 June 2026, requiring developers not already on that path to use the Data Manager API. Then the maintenance mode banner appeared on the Measurement Protocol docs.

Only the second of those is a hard cutoff, and it concerns Google Ads offline conversions rather than Google Analytics. The first is an option. The third is a statement of intent.

Read together they look like a deadline. Read separately they are a direction of travel with one narrow enforcement point.

The sentence that got misread

"Maintenance mode" in Google's vocabulary means no new features. It does not mean sunset. The current documentation is explicit that the Measurement Protocol will remain operational with no plans for deprecation.

If you have a working implementation and no new requirements, the correct action this quarter is to write down where your Measurement Protocol calls live. That is it.

Your GA4 server tag is not affected

This is the part that most coverage skipped, and it is the part that determines whether you have any work to do.

Open your server container. Look at the GA4 tag sitting in it, the one receiving events from the GA4 client and forwarding them to Google Analytics. That tag is not making Measurement Protocol calls. It is tagging. If you want the full picture of what a server container is doing and where the boundaries sit, we covered that in our server-side GTM guide.

Google's own Measurement Protocol overview draws the line for you. It describes the protocol as intended to augment automatic collection through gtag, Tag Manager and Google Analytics for Firebase, not to replace it, and states that you must use tagging to use the protocol at all. Server-side Tag Manager sits on the tagging side of that sentence.

So a standard sGTM setup, however sophisticated, has no exposure here. The web container fires, the client parses, the GA4 tag forwards, the Google Ads and Meta tags fan out. None of that is /mp/collect.

I have seen three agencies this month scope a migration project for clients who do not have a single Measurement Protocol call in their stack. Check before you quote.

What in your container is affected

Four things, and they are all things somebody built deliberately. The distinction matters here, and it is the same one we drew in server-side tagging versus server-side tracking: the transport your container uses by default is not the transport you wrote yourself.

Custom tags that POST to /mp/collect. Usually a custom template using sendHttpRequest with the measurement ID and API secret in the query string. Common for pushing enriched or delayed events back into GA4.
Backend event streams. Refunds, subscription renewals, cancellations, fulfilment, lead qualification. Anything your application server sends to GA4 without a browser involved.
Offline conversion imports into Google Ads. Distinct from the Measurement Protocol, but caught by the same migration wave and subject to the 15 June 2026 cutoff for new implementations. If you are building this from scratch, start with our guide to offline conversion tracking and wire it to the new API rather than the old one.
Anything a previous consultant left behind. Scheduled jobs, Cloud Functions, a Zapier step. These are the ones that surface six months later when the credential rotates.

If none of those exist in your setup, you can stop reading and go do something useful. If one or more do, the rest of this is for you.

The two paths, compared honestly

Google publishes a comparison table. This is that table plus the columns Google has no reason to include. Sort by any column. On mobile each row becomes a card.

Measurement Protocol against the Data Manager API for server-to-server events

Data model	Specific to Google Analytics	Unified across Google advertising products
Authentication	API secret in a query parameter	OAuth, no API secret
Destinations per request	One data stream	Multiple, in a single request
Encryption of user data	Not supported	Supported
Error reporting	Validation server only, silent in production	Fast-fail, plus Diagnostics for downstream errors
Future development	None planned	Active
Setup burden	Minutes	Cloud project, IAM, account grants
Send user properties alone	Yes	Only attached to an event

The error reporting row is the one I would migrate for. A Measurement Protocol call that silently accepts a malformed payload in production has cost more client money than any other single failure mode I deal with.

The auth change is the migration

Everything else is a payload rewrite that a competent developer does in an afternoon. Authentication is where projects stall, and where your hosting choice suddenly becomes a strategic decision rather than a billing one.

The Measurement Protocol wants two values: a measurement ID and an API secret, both in the query string. The Data Manager API wants OAuth credentials with the scope https://www.googleapis.com/auth/datamanager, obtained through Application Default Credentials, a service account, or a verified OAuth client.

Google's setup guide also notes that the Data Manager API scope is a sensitive scope, so any Cloud app obtaining user credentials for it must go through OAuth verification. Service accounts skip that requirement, which is one reason service accounts are the sane default here.

If your container runs on Google Cloud

This is straightforward, and the reason is a sandboxed API that has been in server-side Tag Manager for a while without much attention: getGoogleAuth. It returns an authorization object for use with sendHttpRequest, resolving credentials from the server environment through Application Default Credentials.

Authenticating from a custom sGTM template

The template needs the use_google_credentials permission configured with that scope. Then grant the container's service account, the Cloud Run or App Engine default service account, the appropriate access on the destination. For a Google Analytics property that means an Editor or Administrator role, because the Data Manager API checks the credentials against the operating account.

No secret in a query string. No secret in a variable. No secret to rotate.

If your container runs somewhere else

Application Default Credentials resolve from the server environment. On a managed sGTM host that is not a Google Cloud project you control, there may be no Google service account for ADC to find, and no console where you could grant one access to your GA4 property.

That is the migration cost nobody puts in the proposal. Managed hosting is excellent value for standard tagging, and it may not carry you across this particular change. Confirm with your provider before you scope the work, and treat the answer as a genuine input into where the container lives. We compared the main options, pricing included, in best server-side tracking tools for small agencies.

Field mappings that catch people

Google publishes a full mapping table and you should work from it rather than from memory. These are the entries that have caused real debugging sessions.

There is no request-level timestamp. The Measurement Protocol lets you set timestamp_micros once for the request. The Data Manager API does not. Set eventTimestamp on every event, in RFC 3339 format for JSON.
User properties cannot travel alone. The Measurement Protocol accepts a request containing only user properties. The Data Manager API does not. Properties attach to an event or they do not go. Per-property timestamps are gone too; they are inferred from the event timestamp.
screen_resolution splits in two. The string "1280x720" becomes separate integer screenHeight and screenWidth fields. A string here fails validation.
Value and currency are promoted. params.value becomes top-level conversionValue, params.currency becomes currency, params.transaction_id becomes transactionId. Google explicitly warns against duplicating these into additionalEventParameters, where the top-level fields take precedence anyway.
Items move into cart data. params.items becomes cartData.items, with itemId, quantity and unitPrice as first-class fields and everything else pushed into additionalItemParameters.
encoding is required for user data. Set it to HEX or BASE64 to match how you encoded your hashes. Omitting it on a request carrying userData is a rejection.
Reserved event names hard fail. Where the Measurement Protocol would quietly ignore certain reserved names, the Data Manager API rejects the event with INVALID_EVENT_NAME.
Multiple Analytics destinations need references. If the request carries more than one Google Analytics destination, each event needs a destinationReferences entry, or you get MULTIPLE_DESTINATIONS_FOR_GOOGLE_ANALYTICS_EVENT.

Two replacements worth knowing rather than discovering. The /debug/mp/collect validation endpoint becomes a validateOnly flag on the request. And validation_behavior has no equivalent, because errors during downstream processing now surface through Diagnostics instead.

The fast-fail model, and why it is better

If an IngestEventsRequest fails, no events in that request are processed. All or nothing.

That sounds worse than the Measurement Protocol, which accepts almost anything with a 2xx and discards what it cannot use. It is not worse. It is the difference between a batch job that alerts you and a batch job that has been dropping a third of your refunds since March.

The timing windows nobody reads

Two separate limits apply to Google Analytics events, and they are not the same number.

Event timestamp ceiling

72h

Events sent to Google Analytics must carry an eventTimestamp within the last 72 hours. Older than that and the event is not accepted.

Join window

48h

To be processed alongside events collected by gtag.js or the Firebase SDK, send within 48 hours of the original client-side event timestamp. Later may not attribute as expected.

Batch size in Google's client

2,000

Google's own client library samples batch at 2,000 events per ingest request. Treat that as the sensible ceiling for your batching logic.

The 48 hour figure is the one that bites lead-gen businesses. If your qualification process takes three days, that event will land in GA4, and it will not join cleanly to the session that produced it. Design around that rather than discovering it in a report.

Deduplication behaves differently per product

This is genuinely new information for anyone coming from a Measurement Protocol background, and it is the section I would read twice if you are sending the same event to both GA4 and Google Ads.

How a matching transaction ID is handled, by destination
Destination	On a transaction ID match	The consequence
Google Ads	Conversion value and currency are updated and override the tag's original value. Every other field is ignored.	Correcting a value works. Correcting a GCLID or user data on an already-matched transaction does not.
Google Analytics	The first instance received wins. Later instances of the same event are discarded.	Sending a corrected purchase after the browser already reported it changes nothing in GA4.
No match found	A new conversion event is created and Google attempts attribution from the identifiers you supplied.	A wrong or missing transaction ID inflates your conversions rather than correcting them.

One more trap on new conversion actions. During the initial 14 day trial period for a Google Ads conversion action, value updates are disabled and newly created conversions appear in reporting without being used for bidding. If you test a migration against a freshly created conversion action, you will conclude it does not work.

What this does not change

Identifier matching at Google Ads. Google Ads matches on GCLID, GBRAID, WBRAID, or hashed user-provided data. A unified schema does not create a new match key, and a first-party identifier you invented is still not one of them. Capturing and persisting the identifiers you are allowed to use is a separate job, covered in UTM parameters to first-party cookies.
Consent. The consent object maps across from the Measurement Protocol and still governs what Google may do with the event. Server-side transport is not a consent workaround and never was, a point we made at length in tracking without violating user privacy. For the separate June 2026 change to how Google gates advertising data, see the consent controls split.
Collection quality. If the transaction ID written into your purchase event is inconsistent between the browser and the backend, deduplication fails on both APIs equally. Fix the identifier before you rewrite the transport.
Your standard sGTM tags. Worth repeating because the panic keeps resurfacing. The GA4, Google Ads and Meta tags in your server container are unaffected.
The deadline you think you have. For Google Analytics there is no deadline. The one real cutoff, 15 June 2026, applied to new offline conversion imports through the Google Ads API.

Move now, or wait

My honest read, having looked at this across a set of client stacks over the past two months.

Move now if you are building something new

Any new server-to-server integration should start on the Data Manager API. There is no argument for building on a protocol that will never gain another feature, and the setup cost is a one-time tax you pay either way.
Move now if you send to more than one Google destination

If the same business event needs to reach GA4, Google Ads and a Customer Match audience, you are currently maintaining separate integrations for each. One request with multiple destinations is a real reduction in surface area, not a marketing claim.
Move now if silent failures have cost you

The fast-fail model plus Diagnostics is worth the migration on its own for anyone who has spent a week reconciling a discrepancy that turned out to be a malformed field the Measurement Protocol politely accepted.
Wait if you have a working single-destination GA4 feed

A stable backend stream sending refunds to one property, with no plans to expand it, gains very little today. Document it, note the direction of travel, revisit when a requirement changes. Migrating for its own sake is how you introduce a bug into something that worked.
Resolve your hosting question first, either way

Before scoping anything, establish whether your server container can obtain Google credentials from its environment. That answer determines whether this is a template change or an infrastructure conversation, and it is cheaper to find out now.

Pre-flight checklist

Answer these before writing any code. Two of the seven are gating: until those are settled, any estimate you give is a guess. Answer one and the next appears. At the end you get a verdict you can copy into a ticket or a client email.

Seven checks

Question 1 of 7

01
Have you inventoried every Measurement Protocol call you own?Gating

Custom sGTM templates, backend jobs, Cloud Functions, third-party automations. If that list comes back empty, you have no migration and you can stop here.
02
Have you confirmed your standard sGTM tags are out of scope?

The GA4 tag forwarding events from the GA4 client is tagging, not Measurement Protocol. It does not belong in the estimate.
03
Do you know whether your container can obtain Google credentials?Gating

On Cloud Run or App Engine, getGoogleAuth resolves through Application Default Credentials. On third-party hosting, ask the provider rather than assuming.
04
Is there a Cloud project with the Data Manager API enabled?

Enabling it needs the serviceusage.services.enable permission. Find out now whether you hold it or whether you are waiting on someone.
05
Does the service account have access on the destination?

Editor or Administrator on the GA4 property, or the equivalent grant on the Google Ads account. Holding credentials is not the same as holding access.
06
Are your transaction IDs consistent across browser and backend?

Deduplication depends entirely on this. A mismatch creates duplicate conversions on either API, so it is not something the migration fixes for you.
07
Does your event latency fit inside 48 hours?

That is the window for an event to be processed alongside the client-side events it belongs to. Longer qualification or fulfilment cycles need a decision, not a workaround.

Questions we get asked

Is the Measurement Protocol being shut down?

No. Google's documentation states it has reached a mature, finalized product state and will remain operational with no plans for deprecation. What stopped is development. Existing implementations keep working, and there is no announced end date.

Does my server-side GTM setup need migrating?

Only the parts you built by hand. The GA4 tag in a server container is tagging, and Google's own documentation places Tag Manager in the automatic collection category that the Measurement Protocol supplements. If you never wrote a custom call to /mp/collect, there is nothing to move.

Can I run both during a transition?

Yes, and you should. Send the same events through both paths with matching transaction IDs, then compare. Remember that Google Analytics keeps the first instance it receives of a given event, so run the comparison in reporting rather than expecting the second path to overwrite the first.

What does this cost?

Nothing in API fees. The cost is engineering time plus whatever your hosting answer turns out to be. For a single-destination GA4 feed on a Cloud Run container, budget a day including testing. If the container needs to move, that is a different conversation and a larger number.

Is the encryption support meaningful for GDPR?

It is a useful control, not a legal position. Encrypting hashed identifiers in transit to Google addresses one specific risk. Your lawful basis, your consent capture, and what you send in the first place are unchanged by it. Treat it as defence in depth rather than as a compliance answer.

What happens to the API secret we already have?

It keeps working for as long as you keep using the Measurement Protocol. Once a stream is migrated, revoke it. An unused API secret sitting in a container variable is a credential nobody is monitoring.

Sources

Tracking

Measurement Protocol Is Done. What That Means for Your Server Container