SERVICE FILE · SERVER-SIDE · FILED BY BARIS ASA, LONDON · REVIEWED
Server-side tracking consultant, London, UK.
I'm Baris Asa, a London tracking specialist at Synctag. I set up and repair server-side tracking for UK ecommerce brands and the agencies behind them: server-side GTM (sGTM), Meta's Conversions API (CAPI) and Google's Enhanced Conversions, in your own accounts. Set up badly, the same sale counts twice (F-102).
Quickest check: put last week's Meta and Google Ads purchases next to the orders your store took. Some gap is normal: the platforms also claim sales another channel drove. Roughly double, or a jump the week server-side went live, points at double counting. Far short, on mostly Safari and iPhone traffic, points at lost signal (F-401). Either way, email me the two numbers and you'll hear which it looks like.
Server-side means the sale reaches Google and Meta through a server on your own domain, instead of, or as well as, straight from the shopper's browser. Do you need it yet? · For agencies
Who to hire to set up or fix server-side GTM
Hire someone who checks the browser tracking before moving anything, and builds in your accounts on your own domain. That's my work at Synctag in London: server-side GTM, the Meta Conversions API and Enhanced Conversions on Google Cloud, Stape or Addingwell, new builds and repairs, for UK ecommerce brands and agencies, direct or white-label.
Three kinds of help:
| Kind | Examples | Enough when |
|---|---|---|
| Host: runs the server container, the server half of GTM | Stape, Addingwell, your own Google Cloud project | Someone in-house builds what runs inside it. |
| Managed app: sends the data for you | Elevar, Littledata, Shopify's Facebook & Instagram app | It fits your store and the numbers match. |
| Consultant: builds and repairs what runs inside | Any host or app | The numbers still don't match, or nobody owns the set-up. |
I have no partnership or commission with any host or app in this table.
Server-side GTM errors and faults I fix
- Purchases stop reaching Google Ads or Meta after a GTM change. Server Preview shows which of four: no incoming requests; a request no Client claimed; a tag that failed (its outgoing request shows the platform's response code); or a tag that Succeeded with the wrong value or customer data. Doc ↗
- Meta or Google Ads show more purchases than the store took. The browser and the server both report the sale, and the two copies share no ID (F-102).
- Google Ads says Enhanced Conversions isn't working. It is switched off, or the sale arrives with no hashed customer details to match (F-402). On Meta the same gap shows as a low Event Match Quality.
- Safari visitors still count as new after the move. The tagging server answers from an address Safari treats as a third party, so its cookies are cut to 7 days. Doc ↗
- Purchases drop on sale days. The tagging server doesn't scale to the peak. On Google Cloud I check its instance limits; on a managed host, what the plan does when traffic passes its request allowance. Doc ↗
GA4, Google Ads and Meta as standard. Lines with a fault code are on record in the fault index; lines without one rest on the platform doc linked.
Filed: the F-102 exhibit, in three lines
- One sale in Meta Events Manager, browser copy against server copy. Reconstructed, client data anonymised.
- The page view and add-to-cart share an event_id, so each counts once. The purchase copies don't (different event_ids, "Purchase" against "purchase"), so the one sale counts twice.
- One order, two Purchase events in Events Manager. The fix: one event_id and one event name on both copies, then a test order that shows once. Full write-up.
Do you need server-side tracking yet?
Probably, if
- Meta bids on your sales and the Purchase event's Event Match Quality (Meta's score for how well a sale ties to a real person) is low;
- Google Ads bids on your sales and the purchase action's Enhanced Conversions diagnostics show low coverage or a health-check warning;
- Safari and iPhone make up a big share of your purchases in GA4, and everything is collected in the browser (F-401);
- you already run server-side and one of the faults above looks like yours.
Probably not yet, if
- the browser tracking is wrong. Fix that first; a tracking audit finds what's broken;
- GA4 and the store disagree and nothing is server-side yet: start with GA4 reconciliation;
- you're on Shopify, Meta is your main platform, and the Facebook & Instagram app is set to Enhanced or Maximum data sharing, which already sends Conversions API data.
Not sure? Email what you run today and you'll hear whether it's worth it before anything is quoted. The longer argument: you don't need server-side tracking.
Server-side tagging for high-traffic Shopify stores
- Sized for your busiest hour, so sale-day purchases aren't turned away. Ask your host or developer for the peak requests a second on your last sale day, and compare it with what the server is set up to handle.
- Purchases from Shopify's own order record, so a blocked or unloaded thank-you page doesn't lose the order, with the order ID as the shared key so each sale counts once (F-102).
- One server sender per platform. If Shopify's Facebook & Instagram app already sends Conversions API data, the server container doesn't send purchases to Meta as well. Meta pairs a browser copy with a server copy; two server copies both count.
For your developer: Shopify sizing, IDs and timing
On Cloud Run, Google recommends at least 2 instances and expects 2 to 10 to handle roughly 35 to 350 requests a second, depending on the tags. Capture the click IDs (gclid, gbraid, wbraid, fbc) and browser IDs (fbp, GA client_id) at checkout and store them on the order, or the webhook copy arrives unattributed. Send the server purchase from one order webhook (orders/create or orders/paid), not both. Browser events come from Shopify's customer events; checkout_completed carries the order ID (still guard for null), but fires on the first upsell page when there is a post-purchase flow and not at all if that page fails to load. For Meta, use the order ID as the event_id with the same event name on both copies; Meta pairs copies only within 48 hours, so a late-paid order can still count twice. For Google, send it as the transaction_id to the same GA4 web stream and the same Google Ads conversion action on both copies. Cloud Run ↗ Webhooks ↗ checkout_completed ↗ Meta ↗ GA4 ↗ Google Ads ↗Which Shopify tool does what: Shopify server-side tools compared.
Outsourced server-side GTM for UK agencies
I build and repair server-side GTM, the Meta Conversions API and Enhanced Conversions for UK agencies, named or white-label, inside the client's own GTM, hosting, GA4, Google Ads and Events Manager, invoiced to the agency. Agencies bring me in when a client asks for server-side, or has a server container nobody at the agency built.
- What you receive. The working set-up, a change log of every edit, a runbook, and a report that can carry your agency's name.
- Who holds what. Hosting stays in the client's name and on their bill. Publishing in GTM can stay with you.
- Repairs. A container someone else built is read in Preview first, broken items are listed against the fault codes, and the repair is quoted from that list.
- Terms. An NDA if you need one. Client contact only if you ask.
More on the arrangement: white-label tracking for agencies and partners.
How to choose a server-side GTM provider
- 01 Will you check our browser tracking first?
You want a yes, before anything moves. A duplicate purchase moved server-side is still a duplicate purchase, now with better match data.
- 02 Whose account does the server run in?
Yours, billed to you by the host, so the tracking stays when people leave.
- 03 Which address will the server answer from?
Your shop's own domain, or a subdomain Safari treats as yours. If the subdomain points at the host's domain or at an address Safari treats as third party, Safari caps its cookies at 7 days, so shoppers who return after a week look new.
- 04 How will you stop sales counting twice?
One shared ID per sale on the browser and the server copy, and one sender per platform (F-102).
For your developer: the domain rule
Google's custom-domain guide calls same-origin serving (the tagging server on a path of the shop's own domain, through a CDN or load balancer) best practice, and says Google's default domain can't set server cookies at all. A subdomain works for Safari only if it isn't a CNAME to the host's domain and doesn't resolve to an IP address WebKit treats as third party (WebKit compares the first 16 bits of the IPv4 address, or 64 bits of IPv6, with the main site's): WebKit caps cookies set through third-party CNAME or IP address cloaking at 7 days. Google doc ↗ WebKit doc ↗Server-side doesn't change consent, fix wrong order values or stop double counting on its own. What it changes and what it doesn't: server-side vs client-side GTM. The web container itself is covered on the GTM consultant page.
Who you'd be working with
I'm Baris Asa. I've spent eight years setting up and fixing tracking for online brands and the agencies that run their ads, and I do every job myself. Measurement only: I don't run or judge your ads. I have no partnership, affiliate or commission arrangement with any host or app named on this page. The faults I look for are public: 19 documented in the fault index. I've talked about this work at HeroConf, PPC Live and Search 'n Stuff.
Questions about server-side tracking
- Who should I hire to fix Google Tag Manager server-side errors?
- Someone who reads the set-up in GTM's Preview mode before changing anything. The usual kinds of error: nothing reaches the server, the server container doesn't pick the request up, Google or Meta reject the tag, or the tag is accepted with the wrong data. I'm Baris Asa (Synctag, London), and I repair server-side GTM set-ups other people built, for UK ecommerce brands and agencies.
- What does a server-side tracking consultant do?
- Sets up and repairs server-side Google Tag Manager on your own domain, feeding GA4, Google Ads (with Enhanced Conversions) and Meta's Conversions API, with each sale sent once and consent passed through. It should start with the browser tracking: if that's wrong, server-side copies the error. It should also say when a store doesn't need server-side yet.
- Do you do outsourced server-side GTM for agencies?
- Yes, for UK agencies, named or white-label, invoiced to the agency. The work stays in the client's own accounts and comes with a change log, a runbook and a report under the agency's name.
- Who sets up server-side tagging for a high-traffic Shopify store?
- Someone who sizes the tagging server for the busiest hour (on Google Cloud Run, Google recommends at least 2 instances and expects 2 to 10 to handle roughly 35 to 350 requests a second), takes the purchase from Shopify's own order record as well as the browser, and uses the order ID as the shared key so each sale counts once. The order-ID key is the F-102 fix.
- Is server-side tracking worth it for a small ecommerce store?
- Often not yet. Fix wrong browser tracking first. On Shopify with Meta as the main platform, the Facebook & Instagram app may already send Conversions API data. The full argument is in the note You don't need server-side tracking.
- Does server-side tracking get around cookie consent or ad blockers?
- Consent, no, and it shouldn't. Built right, the server passes on the consent state the browser sends, and Google's own tags adjust to it as they do in the browser. Google's consent handling covers its own tags only; for anything else, Meta's Conversions API included, the trigger or the tag's own consent setting has to check it. Passed through properly, Google's consent mode can still model some of the sales from visitors who decline, once the account has enough traffic to qualify (F-201). Ad blockers, partly: a blocker can still stop the browser's call to your tagging server. The note Server-side vs client-side GTM has the detail.
- What access is needed for server-side work?
- Edit access to GTM (web and server containers), the Google Cloud project or hosting account, DNS or CDN settings for the tagging address, GA4, Google Ads and Meta Events Manager.
- How is server-side tracking work priced?
- There is no published rate card. Each job is quoted after a short scoping call and fixed once agreed. What moves the number: how many platforms are routed, whether the browser tracking needs fixing first, and whether it's a new build or a repair. Hosting is billed to you directly by your host.
Sources, read 30 Oct to 1 Nov 2026: Server-side tagging introduction · Server-side preview and debug · Custom domain for the tagging server · Cloud Run set-up guide · Consent mode in server-side GTM · Google Ads: Enhanced Conversions set-up · Meta: deduplicating Pixel and server events · WebKit tracking prevention · Shopify: Facebook data sharing · Shopify: webhook topics (GraphQL) · Shopify: checkout_completed · GA4: transaction_id deduplication · Google Ads: transaction IDs.
Related services
- Tracking audit: what a full check of GTM, GA4, Google Ads, Meta and consent covers.
- Google Tag Manager consultant: who builds and looks after the GTM container.
- GA4 consultant: who sets up and repairs the GA4 property itself.
- GA4 reconciliation: why GA4, the store and the ad platforms report different numbers.
- Consent Mode v2: who sets up and repairs Consent Mode v2.
- Meta Conversions API: setting up CAPI with the Pixel, deduplicated.
- Shopify tracking: GA4, Google Ads and Meta tracking on Shopify.
- White-label for agencies: tracking work under your agency's name.
- How I work: scoping call, fixed quote, then the work.
Email what you
run today.
The site, the platform it runs on, the ad platforms you use, and whether there's a server container already. That's enough to book the scoping call. I reply myself, and the quote comes after the call.
Example shop.example.com · Shopify · Google Ads and Meta · server container on Stape, Meta purchases up since CAPI went live
[email protected]