Server-side tracking for Shopify
Shopify exposes exactly what a server container needs: an orders/create webhook carrying the order ID, value, currency and customer data. That makes the money event independent of whether the customer ever loaded the thank-you page — which matters because Shop Pay and PayPal can complete a payment and never get there. The browser side stays for funnel events and match signals, deduplicated on the Shopify order ID.
Free30 minutesNo obligation
Shopify server-side · what breaks
What goes wrong on Shopify
- 01
Purchase tracking stopped on a specific date
The checkout extensibility cutover. Anything in checkout.liquid or additional scripts died silently, and the checkout kept working perfectly.
- 02
Wallet payments never reach the thank-you page
Shop Pay and PayPal can be abandoned after payment completes. The order exists in Shopify and no platform hears about it.
- 03
Several apps all sending purchase
The Meta channel app, a pixel app and a container is three conversions for one order.
- 04
Refunds never reversed
Reported revenue only climbs, diverging from your books by your entire return rate.
Shopify server-side · the fix
What changes — Shopify server-side
Purchase from the order record
Immune to what the customer's browser did after paying.
One conversion per order
Deduplicated on the Shopify order ID at every destination.
Refunds reversed
From the refund webhook, so the number can fall as well as rise.
Shopify server-side · architecture
What Shopify exposes to a server container
Shopify is one of the better platforms for a server container, because the webhook gives you a clean, authoritative money event with no browser involved.
- 1
orders/create as the event source
Fires from the order record, so wallet payments and abandoned confirmations are still counted.
- 2
Order ID as the deduplication key
Stable, unique, and identical on the browser and server paths without either coordinating.
- 3
Customer data from the order
Email and phone on the order record, normalized then hashed at the container — not scraped from a checkout DOM you can't reach.
- 4
Customer Events still forwards browser context
fbp, fbc and funnel events, so match quality doesn't fall when you move purchase server-side.
- 5
Refunds wired from refunds/create
The step that makes reported revenue honest.
Shopify server-side · diagnose
Where Shopify tracking breaks, in diagnostic order
Each check rules out a class of cause, so by the last one there is usually a single explanation standing.
- 01
Find the date purchases dropped
If it matches your checkout extensibility cutover, that's the whole diagnosis.
- 02
Check additional scripts and checkout.liquid
They often still contain tags, doing nothing.
- 03
List every app that could be sending
Then check the ones nobody mentioned.
- 04
Test a wallet payment specifically
Shop Pay or PayPal, abandoning the confirmation page after paying.
- 05
Match a closed week on order ID
Shopify web orders against each platform's purchase count.
Shopify server-side · prove
The QA evidence — Shopify server-side
Run on Shopify specifically, on a live conversion rather than in preview mode.
Source of truth
your Shopify order records, web orders only
- A live order placed and the payload read field by field, not previewed.
- Shopify order ID present as transaction_id and event_id at every destination.
- A wallet payment tested with the confirmation page abandoned after payment.
- Purchase count within a few percent of Shopify web orders for a closed week.
- A real refund issued and confirmed reversing.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Shopify server-side · free audit
What we check in the free audit
- Find the date purchases dropped
- Check additional scripts and checkout.liquid
- List every app that could be sending
- Test a wallet payment specifically
- Match a closed week on order ID
Checked against
your Shopify order records, web orders only
Free30 minutesNo obligation
Shopify server-side · when not to buy
When you don't need this on Shopify
Worth reading before you buy anything, from us or anyone.
- If your purchase count already matches your Shopify web orders within a few percent and refunds reverse, nothing here needs doing. Reconcile a closed week and find out — it takes an hour and it's free.
- If you're a small store on a standard checkout with no wallet payments and one destination, Shopify's native channel integrations are free and genuinely sufficient. We'd rather you used those.
- Server-side matters most when wallet payments are a real share of your orders, when your consideration window is longer than a week, or when you need refunds reversed. If none of those apply, the browser-side path may be fine.
- Whatever you do, don't add a second sending path without removing the first. On Shopify that is the single most common cause of doubled conversions, and it makes your data worse than doing nothing.
Shopify server-side · what we deliver
What the server-side build gives you on Shopify
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from Shopify orders
orders/create carries the order ID, value, currency and customer data, with no dependency on the browser.
Deduplicated at every destination
On a shared event ID, verified before any existing path is removed.
Consent enforced before dispatch
A denied destination receives nothing, verified by capture rather than configuration.
Written guarantee
95%+ tracking accuracy
Measured against your Shopify order records, web orders only. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies the browser-side setup you already have, on a live conversion. Honest about its ceiling on this platform.
- Root cause fixed, not worked around
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Money events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, with monitoring so the next break surfaces in days.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring on every destination
FAQ
Shopify server-side questions, answered
If wallet payments are a real share of your orders, or your consideration window exceeds seven days, yes. If your numbers already reconcile, no.
No. Customer Events still supplies funnel events and browser context like fbp and fbc. The webhook supplies the money event.
In an account you control. Whoever holds the hosting holds your measurement, and that shouldn't be an agency — including us.
POS, draft and phone orders belong in your Shopify total and not in a platform comparison. Filter them out of the reconciliation.
Free · 30 min
Move Shopify events off the browser
WhatsAppFree30 minutesNo obligation
