The Measurement Protocol
The Measurement Protocol is an HTTP interface for sending analytics events directly to the backend, without a browser tag. It is what makes server-side, offline, and backend events possible: a server, a kiosk, or a CRM can post events as JSON. With that power comes responsibility — events must be well-formed and de-duplicated, and identity and consent rules still apply on the server.
What this means
The Measurement Protocol (GA4 version) lets you send events to Google Analytics as HTTP POST requests with a JSON body, using a measurement id and an API secret. It powers use cases a browser tag cannot reach: server-side tagging, offline conversions, point-of-sale, and events from systems with no front end.
Power and pitfalls
Because you build the payload, nothing validates intent for you. Events must include the right client or app identifier to join with browser sessions, must be de-duplicated (especially for purchases), and must be well-formed — malformed events are dropped, often silently, which is easy to mistake for missing traffic. And every privacy rule that applies in the browser still applies to what your server sends.
- HTTP POST of JSON events with measurement id + secret
- Enables server-side, offline, and backend events
- You own validation, dedupe, and data minimisation
How it appears in analytics and logs
Events arriving via the Measurement Protocol bypass the browser, so client context is absent unless you supply it. Malformed payloads are silently dropped, which can look like missing data.
Diagnostic use case
Send events from servers, backends, or offline systems via HTTP when a browser tag cannot, while keeping events well-formed and consent-aware.
What WebmasterID can help detect
WebmasterID's ingest accepts first-party events server-side and classifies them, so backend or server-sent events are filtered and separated from bots like any other event.
Common mistakes
- Omitting the client id so events do not join sessions.
- Not de-duplicating server-sent purchase events.
- Posting raw IPs or personal identifiers in payloads.
Privacy and accuracy notes
The Measurement Protocol sends whatever you put in the payload — so data-minimisation is entirely on you. Do not post raw IPs or personal identifiers; consent obligations follow the data, not the channel. This is educational, not legal advice.
Related pages
- Server-side event tracking
Server-side event tracking sends events from your own server (or a server-side tag container) to the analytics backend, instead of firing them directly from the visitor's browser. It can improve data control, resilience to ad-blockers, and where data is processed — but it does not remove consent obligations and can hide client context. This page covers the model and the trade-offs.
- The purchase event and e-commerce
The purchase event records a completed transaction and anchors all e-commerce reporting: revenue, items, and conversion value. It carries a transaction id, a value and currency, and an items array describing what was bought. The discipline is to record the order, not the customer — product and revenue data belong in the event, personal identity does not.
- Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
- Events reference (docs)
How WebmasterID ingests first-party events.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.