Your Shopify dashboard shows 68 orders. Meta shows 41. Google Ads shows 29. TikTok shows 18. The gap is real revenue your ad algorithms are optimising blind on. This guide fixes it free in under 20 minutes using Make.com — no code, no app, no agency.
Server-side tracking (also called Conversions API, server-to-server tracking, or S2S tracking) sends conversion events directly from your web server to advertising platforms — completely bypassing the customer’s browser. Instead of relying on a JavaScript pixel in the browser to fire when a purchase completes, a webhook fires from Shopify’s backend the moment payment is confirmed, routing event data directly to Meta’s Conversions API, Google’s Enhanced Conversions endpoint, and TikTok’s Events API.
The key distinction is where the event originates. A browser pixel depends on the customer’s device: their browser settings, installed extensions, network conditions, and whether they accepted your cookie banner. A server event originates from Shopify’s infrastructure — it fires regardless of what the customer’s browser does, making it immune to ad blockers, iOS privacy restrictions, and Safari’s Intelligent Tracking Prevention.
Server-side tracking does not replace your browser pixel — it runs in parallel with it. The pixel handles upper-funnel events (ViewContent, AddToCart, InitiateCheckout) that server webhooks cannot capture since they only fire on confirmed payment. Together, the two methods give each ad platform the most complete signal possible.
The browser tracking environment has degraded dramatically since 2021 and continues to worsen. iOS 14.5 introduced App Tracking Transparency (ATT), requiring explicit opt-in for cross-app tracking — approximately 62% of iOS users decline. iOS 17 added Link Tracking Protection, which strips UTM and click-ID parameters from URLs in Safari Private Browsing and Mail. Safari’s Intelligent Tracking Prevention deletes first-party cookies after 7 days and blocks all third-party cookies. Firefox Enhanced Tracking Protection blocks third-party cookies by default. Chrome’s Privacy Sandbox continues its phased rollout despite delays.
The cumulative effect: on a typical Shopify store with normal UK or US traffic mix, 30–40% of actual purchases are invisible to your browser pixel. Your ad platforms are optimising delivery on incomplete data — which means higher CPAs, suppressed ROAS, and budget allocated to audiences that look unprofitable but aren’t.
Safari’s Link Tracking Protection in iOS 17+ strips fbclid and gclid parameters from URLs, breaking click-attribution for users who tap your ads in Safari. Server-side CAPI with hashed email matching is the only way to attribute these conversions. If your store has more than 40% iOS traffic, this alone justifies implementing CAPI.
Server-side tracking does not recover every lost event — it recovers the events that were lost due to browser restrictions, not events from users who genuinely did not convert. The 20–40% recovery figure represents real purchases that happened but were invisible to your pixel.
You need four things before you begin. All are free. None require a developer.
Keep all four credentials in a secure note — you will paste them into Make.com HTTP modules during setup. Never share your access tokens publicly or commit them to GitHub.
This method fires directly from Shopify’s backend on payment confirmation — no browser dependency, no thank-you page required, no Shopify app to install. Total time: 18 minutes.
No credit card. Free plan covers 330 orders/month. Setup takes 18 minutes.
Meta’s Conversions API (CAPI) is the server-side counterpart to the Meta Pixel. It was introduced after Apple’s iOS 14.5 ATT update and has since become Meta’s primary recommended tracking method for e-commerce. When your browser pixel fires and your CAPI event fires for the same purchase, Meta deduplicates them using the event_id field — so you see one conversion, not two.
Every field below improves your Event Match Quality score. The more fields you send, the better Meta can match the event to a real user in its database and attribute the conversion correctly.
Endpoint: POST https://graph.facebook.com/v18.0/{PIXEL_ID}/events?access_token={TOKEN}
Required: event_name Purchase • event_time Unix timestamp • action_source website • event_id Shopify order ID (must match browser pixel)
User data (all SHA-256 hashed): em email • ph phone • fn first name • ln last name • ct city • zp zip code • country 2-letter code • client_ip_address raw IP • client_user_agent raw UA
Custom data: currency • value • order_id • content_ids array of SKUs • num_items quantity
Without deduplication, every purchase generates two “Purchase” events in Meta Events Manager — one from your browser pixel and one from CAPI. This inflates your reported ROAS and causes Meta’s algorithm to optimise on false data. The fix is simple: set the same event_id value in both events. In your browser pixel, pass eventID: '{{order.id}}' in the Purchase event parameters. In Make.com, pass the same order ID as event_id. Meta matches them and counts one conversion.
In Meta Events Manager, navigate to Test Events. You will see a Test Event Code. Add this as a test_event_code parameter in your Make.com HTTP module during testing. Place a real test order. Within 60 seconds you should see a Purchase event appear with source labelled “Server”. Once confirmed, remove the test_event_code from your production scenario.
Google Enhanced Conversions improves conversion measurement accuracy by sending hashed first-party customer data alongside your conversion tags. When a customer who is logged into a Google account makes a purchase on your store, Google can match the hashed data to their Google profile and attribute the conversion even if no cookie was set — including cross-device conversions where the customer first clicked your ad on desktop but purchased on mobile.
There are two implementation approaches: via Google Tag Manager Server-Side container, or via the Google Ads Enhanced Conversions for Web feature. For Make.com users, the simplest approach is to configure Enhanced Conversions for Web in Google Ads and send the hashed data in your existing conversion tag, then complement this with an order-level upload via the Make.com HTTP module.
In Make.com, use the built-in sha256(lowercase(trim(email))) function to hash customer data. Apply this to every user data field before sending. Never send raw PII to any advertising platform — all platforms require SHA-256 hashing as a condition of their API terms.
In Google Ads, navigate to Tools → Measurement → Conversions. Click your purchase conversion action, then Diagnostics. The Enhanced conversions tab shows your match rate percentage. A match rate above 40% is good; above 60% is excellent. If your rate is below 20%, check that you are hashing email correctly (lowercase and trimmed before hashing) and that phone numbers are in E.164 format.
TikTok’s Events API uses an Event Match Quality (EMQ) score to measure how well your server events can be matched to TikTok users. Scores range from 0–10. A score above 7 is considered good; above 9 is excellent. The EMQ score directly affects TikTok’s ability to attribute conversions and optimise delivery — a higher score means more conversions attributed and better ROAS.
The single most important difference between TikTok and Meta/Google: TikTok requires the event name CompletePayment, not “Purchase”. If you send “Purchase” to TikTok’s Events API, it will appear in your Events Manager but will not be used for purchase campaign optimisation. This is the most common TikTok setup mistake.
POST https://business-api.tiktok.com/open_api/v1.3/event/track/
Headers: Access-Token: YOUR_TOKEN • Content-Type: application/json
Required body fields: pixel_code • event CompletePayment • timestamp ISO 8601 • event_id order ID • context.user with hashed signals • context.ip • context.user_agent • properties.currency • properties.value
Sending all four high-impact signals (email, phone, external_id, IP/UA) typically achieves an EMQ score of 8–9/10. TikTok’s own published data shows that stores achieving EMQ 7+ see a 19% average increase in attributed events compared to browser-pixel-only measurement. Check your EMQ score in TikTok Events Manager → your pixel → Overview → Event Match Quality.
Server-side tracking is a solved problem. The question is whether you need to pay £400–2,000/month for a managed solution or whether the free Make.com method gives you equivalent tracking quality. Here is the honest comparison.
| Solution | Cost/month | Platforms | Setup | Reliability | Support |
|---|---|---|---|---|---|
| Make.com (this guide) | £0 | Meta + Google + TikTok | 18 min, no code | ✓ Excellent | Community + this guide |
| Elevar | £400–2,000 | Meta + Google + TikTok + more | Managed onboarding | ✓ Excellent | Dedicated account manager |
| Triple Whale | £100–400 | Meta + Google + TikTok | Shopify app install | ✓ Good | Email + chat |
| Analyzify | £300–700 | Google Analytics 4 focused | Managed setup | ✓ Good | Dedicated support |
| Shopify native CAPI | £0 | Meta only | Settings toggle | ✗ Partial (browser-dependent) | Shopify Help Centre |
The tracking quality difference between Make.com and paid solutions like Elevar is minimal for stores sending the same data fields. Elevar’s premium justifies itself primarily through managed GTM setup, data layer configuration, and attribution reporting dashboards — not through superior API access. Both hit the same Meta CAPI and TikTok Events API endpoints with the same payload structure. The key advantage of paid solutions is that they handle edge cases automatically (order edits, refunds, subscription renewals). If your store processes over 1,000 orders/month, Make.com’s paid plan at £9/month is still dramatically cheaper than any managed alternative.
Our recommendation: Start with Make.com free. If you grow to 300+ daily orders or need refund/edit tracking and multi-currency handling, evaluate Elevar at that point. Until then, the Make.com method gives you 95% of the tracking quality at 0% of the cost.
Check in this order: (1) Is your Make.com scenario switched On? Scenarios default to Off. (2) Did you place a test order on a published product, not a draft? Shopify’s Order payment webhook only fires for real checkout orders, not test orders placed via the Shopify admin. (3) Is your access token correct and unexpired? Meta access tokens generated via Events Manager do not expire, but tokens generated via the Graph API Explorer expire after one hour. (4) Is your Pixel ID correct? The Pixel ID in your Make.com URL must match the pixel you are viewing in Events Manager.
This means deduplication is not working. Both your browser pixel and CAPI are firing but with different event_id values. Fix: ensure your browser pixel Purchase event passes eventID set to the Shopify order ID. In Make.com, ensure event_id is mapped to the same order ID field from the webhook payload. Both values must be identical strings.
Low EMQ almost always means missing user data fields. Check: (1) Is email being sent and SHA-256 hashed? It must be lowercase before hashing. (2) Is phone in E.164 format (+447911123456) before hashing? (3) Are IP address and user agent mapped from the Shopify order payload? In Make.com, map browser_ip from the order webhook for IP and client_details.user_agent for user agent.
The most common cause is incorrect email hashing. Google requires: lowercase the email → trim whitespace → SHA-256 hash → send. If any step is skipped, the hash will not match Google’s database. In Make.com use: sha256(lowercase(trim(email))). Also verify you are sending phone in E.164 format before hashing.
A 400 error from any platform API means your payload is malformed. The most common causes: (1) Missing required fields — check the platform’s API docs for required vs optional fields. (2) Incorrect data types — value must be a number, not a string. (3) Invalid timestamp — event_time must be a Unix timestamp (seconds since epoch), not a date string. In Make.com, use the toUnix(now) function to generate the correct timestamp format.
CAPI Shield is our free pre-configured server-side tracking setup for Shopify stores. Zero configuration required.
Shopify server-side tracking sends purchase events directly from your server to ad platforms (Meta, Google, TikTok) without going through the customer’s browser. When a Shopify order is paid, a webhook fires to Make.com which routes the event to each platform’s API endpoint — bypassing iOS restrictions, ad blockers, and cookie limitations. It works alongside your existing browser pixel, not instead of it.
No — keep your browser pixel running alongside server-side tracking. The pixel captures upper-funnel events (ViewContent, AddToCart, InitiateCheckout) that server webhooks don’t cover since they only fire on confirmed payment. Set a matching event_id in both your pixel and server events so each platform deduplicates and you see one conversion, not two.
Most Shopify stores recover 20–40% of previously invisible conversions after deploying server-side tracking. TikTok’s own data shows a 19% average increase in attributed events. The exact figure depends on your traffic mix — stores with high iOS and mobile traffic typically see higher recovery rates. The gap between your Shopify dashboard and ad platform reports should narrow significantly within 24–72 hours.
The data flows through your own Make.com workspace — you control what is sent and can delete the scenario at any time. All personally identifiable information (email, phone) is SHA-256 hashed before transmission as required by each platform’s API specification. Ensure your store privacy policy discloses server-side conversion data sharing with advertising platforms. For GDPR-specific advice consult a legal professional.
Server events start flowing immediately after your first paid order. More conversions will appear in your ad platform reporting within 24–48 hours. Meaningful CPA and ROAS improvement typically takes 7–14 days as ad platform algorithms recalibrate delivery optimisation using the more complete conversion signal.
Shopify’s native Maximum data sharing setting enables their own CAPI integration, but it is still partially browser-triggered — if the thank-you page pixel fails to execute, the server event may not fire. The Make.com webhook method fires directly from Shopify’s backend on payment confirmation with zero browser dependency, making it more reliable.
Yes. The Make.com webhook setup requires no code. You configure a Shopify webhook in Settings, build an HTTP module in Make.com’s visual drag-and-drop interface, and paste your API credentials. Most store owners complete the setup in under 20 minutes. No developer, no agency, no Shopify app installation required.
Yes — the Make.com webhook method works independently of and alongside Shopify’s native data sharing. You do not need to disable native CAPI. Running both adds redundancy: if one delivery method has a transient failure, the other ensures the event still reaches the platform. Use matching event_id values in both so platforms deduplicate correctly.