The Measurement Protocol is Google’s method for sending events to Google Analytics 4 directly from a server, CRM or other back-end system, instead of from a visitor’s browser. It lets you record things that happen away from the website, such as a sale closed by phone or a subscription renewal, against the same visitor GA4 already knows.
How the Measurement Protocol works
Your system makes an HTTPS request to Google’s collection endpoint. The address includes two values: the measurement ID of your web data stream, and an API secret that you create in GA4 under Admin, Data streams, your stream, then Measurement Protocol API secrets. The secret proves the request is genuinely yours.
The body of the request is a short piece of JSON containing:
- A client_id, the anonymous identifier GA4 stored in the visitor’s browser cookie, so the event joins the right user. Apps use an app instance ID instead.
- Optionally a user_id, if you use your own login or customer ID in GA4.
- One or more events, each with a name and parameters, for example a purchase with its transaction ID and value.
Here is a typical case. A London accountancy practice takes enquiries through a web form. When the form is submitted, the site saves the visitor’s GA4 client ID in a hidden field alongside the enquiry. Three weeks later the enquiry becomes a signed client in the CRM, and the CRM sends a “client_signed” event through the Measurement Protocol with that client ID and the annual fee. GA4 can now connect the signed client to the channel that first brought that visitor.
Google provides a validation endpoint that checks your request format without recording anything, which is where all testing should start. At the time of writing (October 2026), events sent without a session ID may not be attributed to the session that brought the visitor, so many set-ups store the session ID too.
Why it matters
Browser tracking only sees what happens on the website. For many UK businesses the money is made later: on the phone, in a showroom, after a quote is accepted. The Measurement Protocol closes that gap in GA4 so reports reflect revenue, not just form fills. It is also used for refunds, cancelled orders and server-confirmed purchases that a browser tag might miss.
It does not remove your consent obligations. If a visitor declined analytics cookies, your site should not have captured a client ID for them, and you should not send their data later from the server. Under UK GDPR you still need a lawful basis and a privacy notice that covers sharing this data with Google. At the time of writing, the protocol also accepts consent fields for advertising use of the data, which matter if GA4 is linked to Google Ads.
Common mistakes
- Putting the API secret in front-end JavaScript, where anyone can copy it and send fake events.
- Sending events with an invented client ID, which creates new phantom users instead of joining real ones.
- Duplicating purchases already tracked in the browser, doubling revenue. Use the same transaction ID so GA4 can deduplicate.
- Skipping the validation endpoint and assuming silence means success. The live endpoint accepts malformed requests without complaint.
- Sending emails, names or phone numbers as parameters, which breaks Google’s terms and your own data protection commitments.
How to act on it
- List the outcomes that happen off the website and are worth reporting in GA4.
- Capture the GA4 client ID (and session ID if needed) at the moment of enquiry or checkout, but only for visitors who gave consent.
- Create an API secret, store it on the server, and limit who can see it.
- Build the request, test it against the validation endpoint, then send a small batch and check it in DebugView and the Realtime report.
- Decide whether these events should also reach Google Ads as offline conversions, which use a separate route.
Connecting CRM outcomes back to ad spend is a core part of how I run performance marketing, because bidding on form fills alone rewards cheap leads rather than good ones.