Moving Shopify purchase tags out of Additional Scripts into a Custom Pixel

Kamran Arshad — Wed, 21 Oct 2026 09:38:54 +0000

On 26 August 2026 Shopify auto-upgraded the Thank you and Order status pages on every non-Plus store that hadn't done it manually. Per Shopify's docs, code pasted into Additional Scripts on those pages is removed by the upgrade, not migrated. If a store's Google Ads, Meta or Snapchat purchase tag lived there, it stopped firing while the ad accounts kept spending.

If you inherit a Shopify store, here's the migration I'd do, in order.

1. Read what was actually in Additional Scripts

Shopify admin → Settings → Checkout → Additional scripts. It's been read-only since August 2025, but you can still read it. Copy the contents out and search for:

gtag(   fbq(   googletagmanager   snaptr(   ttq.   <script src=

Every hit is a conversion tag that needs a new home. That list matters more than any generic migration table, because it's what this store was really running.

2. Prefer the official channel apps where they exist

The Google & YouTube and Facebook & Instagram sales channels send purchase events without depending on the old page, so they survived the upgrade. If a hand-pasted tag duplicated what a channel app already sends, don't rebuild it. Delete it. Two sources for one purchase is how double counting starts.

3. Rebuild the rest as a Custom Pixel

Settings → Customer events → Add custom pixel. Custom Pixels run in a sandbox and subscribe to standard events. The purchase one is checkout_completed:

analytics.subscribe('checkout_completed', (event) => {
  const checkout = event.data.checkout;
  const orderId = checkout.order?.id;          // use as transaction / event id
  const value = checkout.totalPrice?.amount;
  const currency = checkout.currencyCode;

  // Load the vendor script inside the sandbox, then send the event with
  // the same order ID your server-side integration uses for deduplication.
  console.log('purchase', { orderId, value, currency });
});

Two things to get right here:

Pass the order ID through. If you also send purchases server side (Conversions API, Enhanced Conversions, Snap CAPI), the platforms deduplicate on a shared ID. Generate it nowhere: reuse the order's.
Don't trust the preview. The pixel sandbox is not the live checkout.

4. Test the path that breaks

checkout_completed isn't guaranteed to fire on the thank-you page. With post-purchase upsells enabled it can fire on the first upsell page instead. Practitioners also report events firing before customer data is populated, which shows up as poor match quality. I haven't reproduced either on a store I control, so treat them as things to test, not facts. If the store runs upsells, test that path first.

5. Verify with a real order and a before/after

Place a real order on a phone. Confirm the event arrived in each platform, not just that it fired in DevTools. Then compare daily purchase counts in Google Ads and Meta for the weeks before and after 26 August against Shopify orders. That comparison is your proof that something broke and that you fixed it.

The real lesson

The only tracking that was never at risk was server-side, because it doesn't depend on a page the platform controls. Browser tags will keep getting broken by changes underneath you. Pair them with a server-side feed and a shared ID.

I wrote a longer version for store owners, with a table of what survived the upgrade and what didn't: Shopify's Additional Scripts deadline and your purchase tracking.

I'm Kamran Arshad. I run Google Ads, Meta Ads and SEO with conversion tracking behind every campaign at Marketing Kamran.

Meta Conversions API deduplication: generate the event_id once, then pass it

Kamran Arshad — Sat, 10 Oct 2026 18:05:09 +0000

If you send purchases to Meta from both the browser (Pixel) and your server (Conversions API), Meta receives every order twice. The only thing stopping it from counting both is a shared identifier.

Meta deduplicates when event_name and event_id match across the two events. That's the whole rule. Most broken setups I audit break it in one of two ways.

Failure 1: each side invents its own ID

This is the classic. The theme or tag manager generates something for the browser event, and the server integration generates something else:

// Browser (Pixel)
fbq('track', 'Purchase', { value: 49.0, currency: 'GBP' }, { eventID: crypto.randomUUID() });

// Server (Conversions API)
{ "event_name": "Purchase", "event_id": "1047", "action_source": "website" }

Two different IDs, so Meta has no way to know they're the same order. It counts both, and your reported revenue doubles.

Failure 2: the ID isn't unique

The quieter bug. If the "ID" is a checkout ID that gets reused, a session ID, or a timestamp, two genuinely different orders can share it. Meta then correctly merges them into one, and real sales disappear from reporting with no error anywhere.

Double-counting looks like good news, so someone investigates. Silent loss looks like a slow decline and gets blamed on the ads.

The fix: derive it from the order, once

Use something that is unique per order and that both sides can read: the order ID.

// Browser: on the order confirmation page
const eventId = `order_${order.id}`;
fbq('track', 'Purchase', { value: order.total, currency: order.currency }, { eventID: eventId });

// Server: when the order is created
const payload = {
  data: [{
    event_name: 'Purchase',
    event_time: Math.floor(Date.now() / 1000),
    event_id: `order_${order.id}`,   // same string as the browser
    action_source: 'website',
    user_data: { em: [sha256(order.email.trim().toLowerCase())] },
    custom_data: { value: order.total, currency: order.currency }
  }]
};

If you must use a random UUID, generate it once and pass it to the other side (for example, store it on the order). Two independently generated UUIDs are a duplication machine.

Also watch for prefixes: order_1047 on one side and 1047 on the other is a mismatch, not a detail.

Hash customer data before it leaves your server

em, ph and the other user fields must be SHA-256 hashed (after normalising, e.g. trimming and lowercasing email). Check a real payload before going live. A bug here isn't a tracking bug, it's sending raw personal data to a third party.

Prove it works

Place one real order. Note the order number.
In DevTools, filter the Network tab for facebook and read the eventID on the Purchase request.
Find the server event for the same order in your logs or Events Manager and read its event_id.
Compare them character for character.
Reconcile a settled week of orders against Events Manager purchases. Well above your order count means duplication; well below means loss.

I wrote a longer version for store owners, including a table of which identifiers are safe to use, here: Meta CAPI duplicate purchase events: how deduplication actually works.