What Can the GA4 Measurement Protocol Do?

I use the protocol when the backend knows an event happened and can supply the data GA4 needs. It can connect online and offline behaviour and record server interactions alongside browser events.

It does not recreate a browsing history that was never collected. Google says it supplements automatic collection through the Google tag, Tag Manager or Firebase. An event with no connection to the original visitor is not evidence that the original session’s attribution has been restored.

Events can be backdated by up to 72 hours. That is not a way to backfill last month’s missing purchases, and the backdating limit alone does not guarantee session attribution.

For a web stream, client_id identifies the user instance and should match the ID generated by the website’s GA4 tag. I carry that value into the backend when permitted, rather than replacing it with an order number or a fresh random value for each purchase. The request also needs the stream’s measurement_id and an api_secret that stays on the server.

transaction_id identifies the order on a purchase event. Google documents purchase deduplication for web streams, for transactions from the same user with the same transaction ID. I preserve the browser’s client identity and the same order reference in any server copy. A transaction ID alone is not a promise of deduplication across different users or app streams.

I look for the wrong stream, a lost client_id, a reused or empty transaction_id, malformed ecommerce parameters, or an event sent with the wrong time. Session context also matters: Google recommends session_id and engagement_time_msec for accurate session and engagement metrics, including Realtime. I use the actual context rather than inventing engagement.