GA4 Measurement Protocol: Close the CRM-to-GA4 Loop (2026)

Most teams track the click perfectly, then lose the conversion the moment it leaves the browser. A lead turns into a deal in the CRM, a subscription is activated by support, a contract is signed after a sales call: none of these events ever reach GA4, and your attribution stays incomplete. The GA4 Measurement Protocol exists precisely to close that gap. It lets you send an event straight to Google’s servers, up to 72 hours after the original web session, tied back to the right user. The payoff: your offline conversions surface in GA4 and, in turn, in Google Ads. This 2026 guide walks through how to implement it end to end, which pitfalls keep your data from silently disappearing, and when to move to the newer Data Manager API.

What is the GA4 Measurement Protocol, and when to use it

The Measurement Protocol is an HTTP API that accepts GA4 events sent from any server, without going through the browser or gtag.js. You build a POST request containing the user’s identifier and the event to record, send it to the collection endpoint, and Google treats the event as if it came from the site. It is the ideal tool when the data is born server-side: in a CRM, a back office, a payment webhook or a billing system.

Three solutions partly overlap, and you need to pick the right one for the job. The table below compares them on the criteria that matter in production.

In short: the Measurement Protocol is still the simplest building block for pushing a specific offline conversion into GA4. If you are rebuilding your entire tracking architecture, server-side GTM is the broader framework the MP often fits inside. And if your goal is mainly to feed Google Ads, look at the Data Manager API first, covered below.

Prerequisites: client_id, session_id and API secret

For an offline event to attach to the right journey, Google needs two identifiers and a key.

The first is the client_id. It identifies the originating browser and lives in the _ga cookie. Its value looks like GA1.1.1234567890.1680000000: the last two blocks, separated by a dot, form the client_id (1234567890.1680000000). In practice, you capture it on the web at the moment the lead is generated (a form, a booking) and store it in the CRM on the contact’s record. Without that hand-off, no attachment is possible.

The second is the session_id. It is not mandatory, but without it the event risks starting an artificial session and breaking source attribution. You retrieve it through the gtag('get', measurementId, 'session_id', callback) API at capture time, then pass it inside the event params under the session_id key.

The third piece is the API secret. You create it in GA4, under Admin, Data streams, by opening your web stream and then Measurement Protocol API secrets. Generate a secret dedicated to this integration and save its value: it is shown only once. You will also need the stream’s Measurement ID, the one that starts with G-.

Structure of a complete HTTP payload

The production endpoint is https://www.google-analytics.com/mp/collect, called with POST and with measurement_id and api_secret as URL parameters. The body is a JSON object. Here is an example that sends a purchase event triggered when a deal moves to won status in the CRM.

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=YOUR_SECRET

{
  "client_id": "1234567890.1680000000",
  "events": [
    {
      "name": "purchase",
      "params": {
        "session_id": "1699999999",
        "transaction_id": "DEAL-4821",
        "currency": "EUR",
        "value": 4800,
        "engagement_time_msec": 1
      }
    }
  ]
}

Three details make the difference. The transaction_id must be unique and stable: it is what prevents duplicates if the event is resent. Setting engagement_time_msec to 1 forces GA4 to count the session as engaged, otherwise some reports ignore the event. Finally, the event name must match exactly what your Google Ads conversions expect, or the ad-side reporting fails silently.

To test without polluting your data, send first to the validation endpoint https://www.google-analytics.com/debug/mp/collect, which returns the list of format errors without recording the event.

Critical pitfalls to know

The attachment window is 72 hours. Beyond that delay after the session’s last event, Google no longer links the offline event to the original journey: it still records it, but without useful attribution. In practice, your CRM must push the conversion within three days, which usually calls for a scheduled job rather than a manual send.

The timestamp_micros is the second pitfall. If you omit it, GA4 timestamps the event at the moment of receipt, which skews your reports when you process yesterday’s batch. Set it in microseconds (the Unix timestamp in seconds multiplied by one million) to reflect the real conversion time, while staying within the 72-hour window.

The third pitfall surprises almost everyone: events sent through the Measurement Protocol do not appear in standard real-time reports the same way web traffic does, and some dimensions stay empty. This is not a bug. Verification goes through dedicated tools, described next. Never conclude a failure based only on their absence from the real-time interface.

Verify that events arrive

Two reliable methods confirm collection. The first is GA4’s DebugView (Admin, DebugView). Add the debug_mode parameter set to 1 in your params during testing: the event then shows up live in DebugView, with its full parameter detail, which makes it easy to spot a misspelled name or a missing value.

The second method, and the most solid in production, is BigQuery. If the GA4 export is active, your MP events land in the events_intraday_ table and then in events_. You can isolate them and check their volume with a simple query, filtering on the technical source. To go further on these queries, our collection of BigQuery queries for GA4 details the schema pitfalls that silently distort this kind of count. This control step is essential: it is the only place where you can see, without ambiguity, how many offline events were actually accepted.

When to move to the Data Manager API

Google has been clear: the classic Measurement Protocol is maintained, but will get no new features. For new CRM integrations aimed at ad activation, the Data Manager API takes over. It centralizes the connection of your first-party data and directly drives enhanced conversions, Customer Match and offline conversions on the Google Ads side.

The right instinct in 2026: use the Measurement Protocol when your goal is to enrich GA4 analytics with single offline events, and look at the Data Manager API as soon as the main goal becomes large-scale Google Ads activation, especially in B2B or ecommerce. Our complete Google Ads Data Manager guide covers this switch and the use cases. The topic is all the more strategic because GA4 attribution changed in April 2026: with shorter lookback windows, offline conversions have become a major lever to avoid underestimating your campaigns’ real performance.

Production checklist

Before you consider the integration finished, validate these points one by one:

1. The client_id is captured on the web and stored on the contact’s CRM record.
2. The session_id is retrieved and passed in the event params.
3. A dedicated API secret is created in GA4 and stored server-side, never exposed to the browser.
4. The event name matches exactly what your Google Ads conversions expect.
5. The transaction_id is unique and stable to prevent duplicates.
6. The timestamp_micros reflects the real conversion time, within the 72-hour window.
7. A scheduled job pushes conversions within the delay, without relying on a manual send.
8. Collection is confirmed in DebugView during testing, then in BigQuery in production.

Follow this outline and you close the loop between your CRM and GA4: every won deal, every activated subscription and every signed contract finally shows up where your acquisition decisions are made.