What it is for
Google's documentation says the Measurement Protocol is meant to augment automatic collection through the Google tag and Tag Manager, not to replace it. You still need a tag on the site. The tag collects the visit, the session and the traffic source. The server adds events the tag missed or cannot see, such as a purchase confirmed after payment.
Google also says that if you send events only through the Measurement Protocol, only partial reporting may be available. Event rules you set up in GA4 do not run on these events either. Your code has to do the same work.
The same page says the protocol is mature and will not be deprecated, and recommends Google's Data Manager API for new server-to-server integrations. For a store that already sends purchases this way, nothing changes.
What you need
- 1The measurement ID. In GA4, go to Admin > Data streams and open your web stream. The ID starts with G-.
- 2An API secret. On the same stream page, open Measurement Protocol API secrets and click Create. Keep the value private.
- 3The visitor's client ID. This is the part most setups get wrong. See below.
The request is a POST to https://www.google-analytics.com/mp/collect with the measurement ID and the API secret in the address. Google says that to have the data collected in the EU, you change the host to region1.google-analytics.com.
What a Shopify purchase needs
The event is purchase, and Google's event reference sets the rules:
transaction_idis required. Google says it helps you avoid duplicate events for a purchase. Use the Shopify order ID, and use the same value in every sender.itemsis required. Each item needsitem_idoritem_name.currencyis required when you sendvalue. Google asks forvalueas the sum of price times quantity of the items, without shipping and tax.
Two limits from Google's reference catch stores with large orders: up to 25 parameters per event, and parameter values of 100 characters or fewer on a standard property. A request can carry up to 25 events.
Tie the purchase to the visit
GA4 joins a Measurement Protocol event to the visitor's earlier activity by the client_id. With the real client ID from the buyer's browser, the purchase belongs to the visit and its traffic source. With a made-up ID, the revenue still counts, but GA4 has no visit to tie it to. It then shows up as direct or unassigned. See GA4 shows your Shopify purchases as (direct) or Unassigned.
On Shopify, the server never sees the browser. So something in the browser has to read the client ID during the visit and keep it with the order. On a Shopify store that is usually a pixel in Settings > Customer events. Shopify's Web Pixels API gives a pixel access to the store's cookies through its browser object. Read the IDs only when the buyer's analytics consent allows it.
Add the session_id too. Google says an event with a session_id, sent within 24 hours of the start of that session, takes the location and device of that session.
Time limits
Google says events can be backdated up to 72 hours with timestamp_micros. An older timestamp is set to 72 hours ago, or rejected if you ask for strict validation. A purchase you send late shows on the wrong day, and may lose its tie to the session.
So a server that retries for days has a choice to make. It can send late and accept the shift, or stop. Neither shows the purchase on the day it happened.
Consent
The Measurement Protocol has a consent field with ad_user_data and ad_personalization, each set to GRANTED or DENIED. Google says that when you leave it out, GA4 falls back to the consent settings from the client's online activity.
That field describes ad use. It does not decide whether you may send the purchase at all. A buyer who declined analytics should not be sent to GA4, and your server has to read that choice for each order. See Shopify consent settings and missing purchases.
Location and device
A server request comes from your server, not from the buyer. Google's reference offers user_location and ip_override for the buyer's location, with user_location taking precedence, and a device object with fields such as category, operating_system and browser. Google says that without device data from tagging, web events default to desktop.
Google gives no answer
Google says the Measurement Protocol does not return HTTP error codes, even if an event is malformed or missing required parameters. A wrong measurement ID, a deleted API secret, a broken payload: the server gets the same reply every time.
Google offers a validation server at /debug/mp/collect. It returns messages about fields it cannot accept, and its events do not appear in reports. But Google says it does not validate the API secret. A format check passes with a wrong secret.
So the real check is GA4 itself:
- 1Send one purchase from your server for a real, low price order.
- 2Open the Realtime report in GA4 and look for it.
- 3A day or two later, look for its transaction ID in your purchase reports.
If it is not there, check that the measurement ID belongs to your store's web stream, and create a new API secret on that stream. For a one-order test of the browser tag, see GA4 purchase event not firing on Shopify.
One sender per purchase
If the store's own Google tag still sends purchase and your server sends it too, GA4 gets two. The same transaction_id on both is your best protection, but GA4 decides how it treats them. The cleaner way is to stop the tag's purchase event and keep the tag for everything else. See GA4 duplicate purchases on Shopify.
How this fits with the Google tag and the other platforms is in how a paid order reaches Meta, GA4 and Google Ads.
FAQ
Is the Measurement Protocol the same as server-side Tag Manager?
No. A server Tag Manager container receives events and forwards them. The Measurement Protocol is the address GA4 receives server events on, whatever sends them.
Can I drop the Google tag once purchases go from the server?
Google says the protocol augments the tag. Without the tag, GA4 has no sessions or traffic sources, and only partial reporting may be available.
Why do I see the purchase in Realtime but not in reports?
Standard reports can take a day or two. See Purchases show up days later in Meta Ads Manager or GA4.
Where Tikra fits
Tikra sends each paid online order of your store from our server to Google Analytics 4 through the Measurement Protocol, as a purchase with the Shopify order ID as the transaction ID, to Google's collection address for the EU. When its pixel read them with analytics consent, the purchase carries the buyer's client ID and session ID. Without them, Tikra uses an ID made for the order: the revenue counts, but GA4 cannot show where the buyer came from. Refunds and partial refunds are sent to Google Analytics 4 too.
Google gives no confirmation per order, so Tikra shows Google Analytics 4 orders as sent, not confirmed, and our help points you to the Realtime report for the real check. When you connect, Tikra sends a test event to Google's validation server, which checks the format only. Tikra applies your customers' consent choices to every order, and in Strict mode an order is sent only with the buyer's consent. A written guarantee in our Terms covers eligible orders: at least 97 % reach each platform, fixed within 12 hours or a month's fee credited (Terms of Service, section 8).
The free diagnosis sends none of your orders anywhere. It shows your paid orders of the last 7 full days, how many came from a Meta, Google or TikTok ad, and, after a full day and 10 paid online orders, how many your shoppers' browsers reported.