Ad-blockers and ITP
They block scripts they recognise. Ours is not built to be recognised.
A blocker matches addresses against a list. ITP expires what a script wrote seven days ago. Tracyn’s browser bundle is built to match neither pattern — and underneath it, every purchase is read straight from your Shopify order, so the browser half never has to be the thing that saves the sale.
The two forces
One takes the request. The other takes the memory.
They are usually named in the same breath and they are not the same problem. Knowing which is which is what tells you whether a vendor’s answer is real.
Ad-blockers
Filter lists, not intelligence.
uBlock, Brave and AdGuard do not inspect what a script does. They match its address against EasyList and EasyPrivacy, plus generic rules for URLs that look like telemetry. A vendor pixel loses because it is recognisable: same domain on every store, same filename, a path with "collect" or "track" in it.
Safari and iOS ITP
A clock, not a blocklist.
ITP does not stop the script. It shortens its memory: third-party cookies are gone outright, and storage written by JavaScript expires in seven days — often twenty-four hours for a visitor who arrived from an ad. The pixel keeps firing; it just stops recognising anyone.
The browser half
Four reasons the usual rules do not fire.
A blocker recognises a pixel by its shape: the same vendor domain on every store, the same script name, a path that announces what it is doing. Tracyn’s bundle has none of those shapes — which is why, in practice, it keeps running where a standard pixel does not.
-
A delivery zone with no brand fingerprint
The bundle and the event endpoint are not served from the domain this website sits on, and share no registration footprint with it. The usual route onto a blocklist — a maintainer notices a vendor, looks up the vendor’s domains, adds them — does not start.
-
A different filename for every store
Each merchant gets their own bundle, named after their own shop, built at install. There is no single script name to write a rule against, so a rule written for one store matches nothing anywhere else.
-
Paths that do not read as telemetry
Generic filter rules fire on URLs that announce themselves: collect, track, beacon, analytics, pixel. None of those words appear in the requests Tracyn makes.
-
Loaded the way Shopify loads its own code
The purchase pixel runs inside Shopify’s own Web Pixels sandbox and the storefront bundle ships as a theme app extension — not as a third-party tag bolted into your theme or a tag manager container, which are exactly the shapes blockers are tuned for.
And none of it has to work. Every purchase is also read from your Shopify order, server to server — so the worst a blocker can do is cost you detail on one visitor, never the sale itself.
Safari and iOS
Identity that Safari cannot expire, because it is not in the browser.
Most answers to ITP are cookie tricks that buy a few more days before the same clock runs out. Tracyn takes the clock out of the path: the reference that ties a purchase back to the ad that produced it travels inside Shopify’s own order data.
- 01
At the click
The ad platform’s click ID arrives on the landing URL. It is recorded against the visit server-side immediately, rather than being parked in a cookie and hoped for later.
- 02
Through the cart
A single reference for the visit is written into the Shopify cart. Shopify carries its own cart data through checkout — that path is not browser storage and no privacy policy expires it.
- 03
On the order
The reference arrives back attached to the order itself. Tracyn reads it and resolves the full identity for that visit — click IDs, browser identifiers, hashed customer data — on the server.
- 04
At the send
The conversion goes to Meta, Google Ads and TikTok with that identity attached. Whether the buyer’s browser still remembered anything never enters into it.
95%
Purchases sent with full customer identity
Up from about half. The reference travels on the Shopify order, so identity is resolved server-side rather than read from browser storage Safari has already cleared.
The honest part
What nobody can promise you here.
This category is full of vendors selling total immunity. Immunity is not a thing a browser script can have. Here is where the line actually sits.
-
Nobody can promise permanence
Filter lists are maintained by people, and any address can be added to one. Anyone selling you lifetime ad-block immunity is selling you a snapshot. What survives a listing is the server-side half, which is why the architecture does not rest on the browser winning.
-
A blocked bundle still costs you something
The sale is safe — it comes from the order. What is lost for that visitor is on-site behaviour and the browser identifiers that raise match quality, so the conversion is forwarded with the order data and whatever was captured at the click.
-
ITP still shortens the browser’s memory
Nothing here changes what Safari does to browser storage. It removes the dependency on it: identity for a purchase is resolved from the order, not from what the browser managed to keep.
-
A strict CSP needs one line added
If your theme sets a custom Content-Security-Policy, the bundle host has to be allowed in script-src. It is one entry, documented at install, and it is the only theme-side change Tracyn asks for.
Before you install
What merchants ask about blockers.
Is this legal, and is it a workaround for GDPR?
It is legal, and it is not a consent workaround. Ad-blocking is a filter list matching addresses; nothing about serving your tracking from a different address breaks a law or a browser policy. Consent is a separate matter and is handled separately: your banner’s verdict travels with every event and is sent to each ad platform as its own restricted-processing flag, EU traffic is processed in the EU, and you get a data processing agreement.
What happens the day the domain does end up on a list?
Your purchases keep arriving, because they are read from the Shopify order rather than from the browser. That is the whole reason the server-side copy exists. Match quality on blocked visitors drops, since the browser identifiers stop reaching us for those sessions, and the delivery zone can be rotated. No merchant loses sales data to a list update.
Does this work on Safari and on iOS in-app browsers?
Yes, and those are the cases it is built for. The purchase is captured from the order, and the identity for that visit is resolved from a reference carried on the order itself rather than from browser storage that ITP expires after seven days — often twenty-four hours for someone who clicked an ad.
Do I have to change my theme or add a tag manager?
No. The storefront bundle installs as a Shopify theme app extension and the purchase pixel runs in Shopify’s own pixel sandbox. There are no theme file edits and no container to maintain. The only exception is a custom Content-Security-Policy, which needs the bundle host allowed in script-src.
Will my numbers suddenly jump when I install this?
Tracked conversions go up, because purchases that never reached the platforms start arriving. Reported revenue does not double, because both copies of a purchase carry the same event ID and each platform collapses them into one. Bidding performance moves later, once the platforms’ models have retrained on the fuller signal.
Keep reading
Ready to scale on numbers you can trust?
Run Tracyn free for 14 days. We do not charge at all in that window, so if your tracked revenue and match quality have not moved, you walk away having paid nothing.
- Five-minute setup, no developer
- Tracking live the same day
- No contract, cancel anytime