If you hit the banner “No future enhancements are planned. Upgrade to the Data Manager API to future-proof your integration” while opening the Measurement Protocol docs, you are probably asking the wrong question. The real issue is not “which one is better.” It is “do I need to rewrite my pipeline now, and at what cost.” This article settles it, use case by use case. The Measurement Protocol vs Data Manager API matchup comes down to very concrete details: encryption, multi-destination sends, quotas, and above all a constraint that 90% of the content out there forgets to mention, allowlist access. For a refresher on what the MP actually does, keep our full Measurement Protocol guide handy.
Should you migrate? The short version. Offline CRM conversions to Google Ads: yes, prepare the move. Server-side purchase, multi-destination: yes. Pure GA4 analytics enrichment: no, the MP still works. New integration: go straight to the Data Manager API.
What Google actually changed (and what it did not)
Let’s decode the banner, because it says exactly two things and nothing more. One, the Measurement Protocol will not evolve: no new features, no new fields. Two, Google names the Data Manager API as the forward path. That’s it.
One clarification before going further, to avoid the most common confusion: we are talking about the API here, not the interface. The Data Manager on the product side, the one that handles BigQuery connections and Customer Match in the Google Ads UI, is a different topic, covered in our Google Ads Data Manager guide. This article targets the Data Manager API, the programmatic building block.
What the banner does not say, and this matters: there is no sunset date. The MP is not deprecated, it is frozen. Your current POST requests keep working, your offline conversions still land in GA4, your attribution does not break overnight. “Maintenance mode” means “we won’t touch it anymore,” not “we’re turning it off soon.” Get reassured first, decide second.
That said, the trajectory is unambiguous. The Data Manager API is moving fast: v1.6 on May 7, 2026 added store sales and expanded Analytics event ingestion across web and app; v1.7 on May 28, 2026 wired in Campaign Manager 360, Search Ads 360 and Display & Video 360. On the other side, the MP received exactly nothing. When one product ships a major version a month and the other zero, the question is no longer “if” but “when” you migrate.
Measurement Protocol vs Data Manager API: the technical comparison
Here is the field-by-field comparison, on the criteria that matter once you are in production, not on a marketing slide.
| Criterion | Measurement Protocol | Data Manager API |
|---|---|---|
| Data model | Proprietary to GA4 | Unified, shared across Google products |
| Destinations | One GA4 data stream per request | Multi-destination (GA4 + Google Ads) in one request |
| Identifier encryption | None (you send in clear) | XChaCha20-Poly1305, keys wrapped via KMS (GCP or AWS) |
| Authentication | api_secret in a query param | OAuth 2.0, datamanager scope |
| Transport | Plain HTTP POST | REST and gRPC |
| Direction | Frozen, maintenance mode | Active, v1.7 as of May 28, 2026 |
| Access | Open to everyone | Allowlist on certain capabilities |
Two rows deserve a pause. Encryption first: the MP sends your user identifiers in clear, while the Data Manager API requires client-side encryption before sending. That is more implementation work, but it is also what makes it defensible in front of a security team. Multi-destination next: where the MP needs one request per stream, the Data Manager API pushes the same event to GA4 and Google Ads at once. On any real volume of offline conversions, that changes the operational math.
The quotas and limits to know before you size it
Before you promise a migration to your client or your lead, size it with numbers. The Data Manager API enforces per Google Cloud project caps you should know:
- 100,000 requests per day and 300 requests per minute per Cloud project.
- 10,000 audience members or 2,000 conversion events per request.
- Up to 10 user identifiers per record.
These numbers are more than enough for most offline conversion pipelines. They become structural if you plan massive audience uploads or a historical backfill: in that case, plan batching and quota handling at design time, not after your first 429.
Should you migrate? The decision grid by use case
This is the heart of the decision. Do not migrate “because Google says so”: migrate if your use case gains from it. Here is the grid I apply on engagements.
| Your use case | Decision | Why |
|---|---|---|
| Offline CRM conversions to Google Ads activation | Migrate | This is what the Data Manager API serves best, and the old Ads paths are closing |
| Server-side ecommerce purchase, multi-destination | Migrate | One request for GA4 + Ads, native encryption, clean sizing |
| Pure GA4 analytics enrichment, single events | Stay | The MP does the job, stays operational, and migrating adds nothing here |
| Kiosk, POS, device with no tagging | Stay | Until allowlist access is granted, you cannot switch |
| Brand-new integration from scratch | Data Manager API right away | Better to start on the forward format, not a frozen one |
The case that should migrate first is CRM to Google Ads. The sequence of closing old paths forces it: since April 1, 2026, Customer Match uploads through the old Google Ads API services are closed, and since June 15, 2026 new offline conversion imports through the Google Ads API are blocked. If your B2B pipeline looks like the one in our Enhanced Conversions for Leads with server-side GTM guide, you are on the front line.
Conversely, if you only push single events to enrich your GA4 reports, with no ad activation behind them, do not move. The MP does exactly what you need, and a migration would be work with no payoff.
The real blocker: the allowlist
Here is the point nobody puts forward, and the one that often makes “migrate now” unworkable: several Data Manager API capabilities are reserved for allowlisted accounts. Sending events with a transaction ID as an additional data source for GA4, or uploading store sales conversions, are open only to allowlisted properties and accounts. Concretely, you can have everything coded and hit an access wall.
The access request goes through a dedicated Google form, for the property or account concerned. Prepare the Google Cloud project ahead of time, with the API enabled and OAuth 2.0 credentials ready, so you do not waste time once access is granted. And accept this uncomfortable idea: in September 2026, “waiting” is a perfectly legitimate decision. Preparing the migration without launching it is often the right answer as long as access is not there.
The 5-step migration plan
When you decide to go, the switch fits in five steps.
- Create a Google Cloud project and enable the Data Manager API on it.
- Generate OAuth 2.0 credentials with the
datamanagerscope (note that it is distinct from the Google Ads API scope). - Map your Measurement Protocol payload to the Data Manager schema: this is the bulk of the work, the models do not copy over field for field.
- Grant the operating account access to the target GA4 property.
- Verify with GA4 Realtime and DebugView: those diagnostic tools stay perfectly valid after the switch.
If your collection already runs on server-side GTM, place where the Data Manager API fits in the architecture; our server-side GTM guide sets the scene. And for a concrete example of an integration already built on this logic, look at our Shopify GA4 server-side article.
The 3 pitfalls to avoid
First pitfall, the OAuth scope. The datamanager scope is not the Google Ads API one. If you reuse existing credentials without checking, you will hit an authorization refusal mid-switch.
Second pitfall, believing the Data Manager API replaces your tagging. It does not. Like the MP, it needs standard tagging alongside it (gtag or GTM), otherwise the session context is incomplete and attribution suffers. The Data Manager API activates and enriches, it does not collect the web journey for you.
Third pitfall, double counting during the switch. If you send the same conversion through the MP and the Data Manager API in parallel to test, you will count it twice. Scope the transition window precisely and cut one path before opening the other, or filter by source so you do not pollute your reports.
Verdict as of September 5, 2026
My recommendation, as I give it to a client today, hinges on one thing: what you do with your data. If you feed Google Ads from a CRM or an ecommerce back office, plan the migration now, request allowlist access if your capability depends on it, and keep the MP running until the switch is validated. If you only enrich GA4 with offline events and nothing rides on activation, stay on the Measurement Protocol: it is frozen, not dead, and it does the job. And if you are starting from scratch, do not even ask, go with the Data Manager API.
The right posture is neither to rush nor to ignore. It is to know which box you are in, and act accordingly.
FAQ
Will the GA4 Measurement Protocol be shut down?
Nothing points to it so far. It is in maintenance mode, with no new features, but no sunset date has been announced. Your existing integrations keep working.
How do I request access to the Data Manager API?
Some capabilities (transaction ID as an additional source, store sales) go through a Google allowlist form, property by property or account by account. First prepare the Google Cloud project with the API enabled and OAuth 2.0 credentials.
Data Manager API or Google Ads API for offline conversions?
The Data Manager API is the forward path: the old offline conversion imports through the Google Ads API have been closing progressively since 2026. For any new activation integration, go with the Data Manager API.
Which OAuth scope for the Data Manager API?
The datamanager scope. It is distinct from the Google Ads API scope: do not reuse existing credentials without checking, or you risk an authorization refusal.