Google Analytics 4 (GA4) introduces the Measurement Protocol v2, a significant upgrade from its predecessor in Universal Analytics (UA). While the Measurement Protocol has long been a powerful tool for sending data from external environments like kiosks or CRM systems to Google Analytics, this new version brings flexibility, enhanced debugging, and cross-platform tracking capabilities. In this blog post, we’ll dive into the key updates, practical considerations, and known limitations of GA4’s Measurement Protocol v2.

What is the Measurement Protocol?

The Measurement Protocol allows developers to send data to Google Analytics servers using HTTP requests from any environment, not just browsers. This is especially useful for tracking offline interactions (e.g., point-of-sale transactions, CRM updates) alongside online behavior. In GA4, the protocol takes on a more advanced role, adapting to the platform’s focus on event-driven data and cross-platform tracking.

Here are some use-cases for the Measurement Protocol:

Key Updates in Measurement Protocol v2

Endpoint and Authentication

In Measurement Protocol v1 (Universal Analytics), the endpoint for data submission was straightforward: www.google-analytics.com/collect, and no API secret was required. In v2, the endpoint is now split into:

/mp/collect for sending regular events
/debug/mp/collect for debugging purposes

A crucial change is the requirement of an API Secret for authentication, ensuring that only authorized systems can send data to GA4:

https://www.google-analytics.com/mp/collect?api_secret={{SECRET_GOES_HERE}}&measurement_id={{ID_GOES_HERE}}

This added security is essential as data sent via Measurement Protocol can impact reports.

Flexible JSON Payload Structure

One of the most important advancements in v2 is the transition from the rigid structure of v1 to a flexible JSON payload. This allows for:

Complex data representation: You can now send multiple events in a batch using a single HTTP request.
Event-level control: Each event can carry up to 25 parameters, enabling a more detailed and nuanced analysis.

More details about the payload available at the official documentation

Session Handling

Session management has shifted significantly in GA4. In v1, developers had control over sessions through the sc=start and sc=end parameters, allowing for manual session management. In v2, sessions are handled automatically by GA4 based on user activity and time thresholds. MP events are meant to enrich existing online sessions, as opposed to starting new ones.

However, when sending events via Measurement Protocol, you must include a session_id to ensure that events are attributed correctly. The session’s timestamp is crucial for maintaining accurate attribution, especially when dealing with data that spans both online and offline touchpoints.

New Debugging Features

GA4 introduces a Measurement Protocol Validation Server, making it easier to test and troubleshoot data before it goes live. You can send events to the /debug/mp/collect endpoint, and while these events won’t appear in your GA4 reports, they’ll provide instant feedback on any errors or issues with your payload.

This feature is a significant upgrade from v1, where debugging was limited and often required extensive manual testing. With the Validation Server, you can save time by catching errors early in the implementation process

More details about the validation server available at the official documentation.

Known Limitations in v2

72-Hour Attribution Window

One of the challenges with Measurement Protocol v2 is the 72-hour attribution window. Events with timestamps older than 72 hours from the time of submission may not be attributed to the correct session and are often marked as “Unassigned” in GA4 reports. This limitation can impact acquisition-based reports if you’re sending data from offline systems or dealing with delayed event transmissions.

Simo Ahava wrote a great article on the topic.

Inability to Modify Events via UI

Unlike events sent from the browser (via gtag.js), Measurement Protocol events cannot be modified using GA4’s Modify Event feature. This restriction can be problematic if you need to adjust parameters or create custom events post-hoc. All modifications must happen on the client-side or within the system that generates the Measurement Protocol requests.

Latency in Reports

Another consideration is the potential latency in data processing. Data sent via Measurement Protocol may take 24-48 hours to appear in GA4 reports, which can complicate real-time tracking. While this delay is generally manageable, it’s important to account for it in reporting workflows.

Practical Considerations

Batch Your Events: Take advantage of the JSON structure to batch multiple events in one request, especially when working with server-side environments. This can improve efficiency and reduce the number of API calls needed.

Validate Early and Often: Use the Validation Server during development to ensure your payloads are formatted correctly before they hit your production environment.

Monitor Sessions Closely: Ensure that your session_id is correctly included in your payloads and is within the 72-hour window for accurate session attribution. Having a mechanism to frequently pull the session_id value and refresh at the system of record is recommended.

Conclusion

GA4’s Measurement Protocol v2 brings powerful new capabilities, especially in terms of flexibility and cross-platform tracking. However, you need to be mindful of the changes in session handling, debugging workflows, and the limitations imposed by the 72-hour attribution window. By adapting to these updates, you can ensure a smooth transition from UA to GA4 and leverage the enhanced data collection opportunities that v2 offers.

Additional resources

Official documentation
Simo Ahava’s blog
How to capture the session_id by Dodov.dev