Not every customer interaction happens in a browser. Deals close in a CRM, purchases happen in stores, and connected devices, kiosks and back-end systems generate events that a website tag never sees. For years, the standard way to get those events into Google Analytics 4 (GA4) was Measurement Protocol, a set of rules for sending raw event data directly to Google Analytics servers over HTTP.
That changed in 2026. Google moved Measurement Protocol into maintenance mode and now recommends its Data Manager API for new server-side integrations. Measurement Protocol isn’t going away, but it won’t receive new features, and Google’s investment is clearly going elsewhere. Here’s what changed, where server-side events still earn their place, and how to decide when to move.
What changed in 2026
The Data Manager API is Google’s unified way to send first-party data across its advertising products, including Google Ads, Display & Video 360 and Google Analytics. In May 2026, Google expanded it to accept any GA4 web or app event that isn’t a reserved event, which made it a direct alternative to Measurement Protocol.
Shortly after, Google updated its Measurement Protocol documentation to describe the protocol as mature and finalized. It will keep working, with no plans for deprecation, but new capabilities are going into the Data Manager API instead. Google has been moving other data pathways in the same direction, including Customer Match audience uploads and new Google Ads offline conversion imports.
In practice, that means existing Measurement Protocol integrations are safe for now, but new builds should start on the Data Manager API.
Where server-side events still matter
Whichever tool you use, the reasons to send events from outside the browser haven’t changed:
- Offline conversions: Send in-store purchases, phone orders or deals closed in your CRM back to GA4, so you can analyze the full customer journey and not just the online part.
- Connected devices: Track interactions with smart devices and sensors. For example, a company that makes a filter sensor for home appliances could send an event each time the sensor triggers a replacement reminder, and another when the customer buys a filter, showing whether the reminders drive purchases.
- Kiosks, screens and media players: Capture taps on a kiosk touchscreen or play and pause actions in a video player, where standard web tagging isn’t available.
- Server-to-server integrations: Send events from CDPs, payment systems and other back-end platforms. With browser privacy features and ad blockers limiting client-side tracking, server-side collection is now a core part of a reliable measurement setup.
One rule applies to both tools: server-side events are designed to enhance your existing tagging (gtag.js, Google Tag Manager or Firebase), not replace it. GA4 uses the client ID or app instance ID to join server-side events with the device, location and privacy information collected by your tags. If you send events only from your servers, you may get partial reporting. Event creation and modification rules set up in the GA4 interface also don’t apply to server-side events, so your application needs to handle that logic itself.
How the two compare
- Data model: Measurement Protocol uses a data model specific to Google Analytics. The Data Manager API uses one data model across Google’s advertising products.
- Destinations: Measurement Protocol sends each request to a single GA4 data stream. The Data Manager API can send the same event to multiple destinations in one request, such as a purchase sent to both GA4 and Google Ads.
- Encryption: The Data Manager API supports encryption of user-provided data. Measurement Protocol does not.
- Authentication: Measurement Protocol uses a measurement ID and an API secret generated in GA4. The Data Manager API uses Google Cloud credentials, through a user account or a service account, and requires no API secret.
- Error handling: Measurement Protocol only reports errors for test requests sent to its validation server, so malformed data can be accepted silently in production. The Data Manager API uses a fast-fail model: if any record in a request has an error, the whole request fails.
- Location and device data: Measurement Protocol can’t send geographic information; it relies on what your tags collect. The Data Manager API lets you provide location and device information with each event.
What a move involves
Google’s upgrade path follows five steps:
- Set up API access: create or select a Google Cloud project, enable the Data Manager API, set up authentication and give that account access to your GA4 property.
- Install a client library for your programming language.
- Map your existing Measurement Protocol fields to their Data Manager API equivalents.
- Send events to your GA4 property.
- Verify the results in GA4’s Realtime report or DebugView.
A few practical notes for planning:
- Authentication is the biggest change. Moving from an API secret to Google Cloud credentials can be quick or can require rework, depending on where your integration runs. Service accounts are the usual choice for server-to-server work. Apps that use personal user accounts need to go through Google’s OAuth verification before going to production.
- Test thoroughly before switching. Because one bad record fails the whole request, your error handling needs to be ready. The upside is that bad data gets caught instead of quietly skewing your reports.
- Check feature access. Some capabilities, such as sending events with a transaction ID as an additional data source, require Google to allowlist your property.
When to stay and when to move
Staying on Measurement Protocol for now is reasonable if your integration is stable, you only send data to GA4, and you don’t have developer capacity right now. It will keep working.
Moving to the Data Manager API makes sense if you’re building a new integration, you want the same events in GA4 and Google Ads, you send user-provided data that should be encrypted, or silent data quality issues have cost you before.
Either way, now is a good time to audit what you send server-side. Document your event names and parameters, check that your tagging is still in place, and confirm that your server-side events actually show up where your team expects them.
The bigger picture
Google consolidating its data pathways into one API reflects a broader change in measurement. As browser-based tracking becomes less reliable, accurate reporting depends more on first-party data sent from your own systems. Teams that treat server-side collection as part of their data architecture, and not as a one-off developer task, will adapt faster to the next change, whatever it turns out to be.
