You build a 30 day Add to Cart audience in Meta Ads Manager on a Monday. Shopify counted thousands of add to carts last month. The audience comes back a fraction of that size. The product is fine. The offer is fine. Safari deleted the cookie your pixel wrote, seven days after each visit.
A pixel is the small piece of code that tells Meta what someone did on your store. A cookie is the file it writes in that person’s browser. A retargeting audience is the list Meta builds from those signals. You own the store. You do not own the browser.
The short answer. Your audiences shrink because Safari deletes the cookie your pixel wrote after seven days. The people are still shopping. Your pixel forgot them. You fix it by sending hashed checkout identity from your own server through Meta’s Conversions API, then reading Event Match Quality in Events Manager.
You pay for a visitor once, then lose the right to speak to them a week later. That is money, not data. Signal loss, meaning tracking data going missing, is why this sits inside our growth and measurement work. Autonomous Technologies builds and runs the systems behind Shopify stores, for founders and operators who own the store after launch.
Who this is for. You run a Shopify or Shopify Plus store. You spend your own budget on Meta ads. Your audiences look far smaller than your store analytics say they should. Who this is not for. Stores with no paid social spend. Anyone who wants a legal opinion on consent, because your privacy counsel owns that, not your pixel.
Safari deletes the cookie your pixel wrote after seven days
Safari runs a set of anti tracking rules called ITP, short for Intelligent Tracking Prevention. Safari is the default browser on every iPhone. This is not a small slice of your traffic.
Apple’s WebKit team, the group that builds Safari’s engine, set out the seven day rule on 24 March 2020. ITP now deletes “all of a website’s script-writable storage after seven days of Safari use without user interaction on the site”. That includes the cookie your Meta pixel writes. The same post says cross site cookies, which are set by a different site than the one being visited, “are now blocked by default across the board”.
There is a shorter cap too. ITP 2.2 was published on 24 April 2019. It caps some cookies at “one day of storage”. That happens when a site Safari has flagged as a tracker sends a visitor to your page on a link with a query string, which is extra tracking text after the web address. The old version of this article called it “in some cases, 24 hours”. It is narrower than that.
| What it measures | The figure | Source | Dated |
|---|---|---|---|
| Safari cap on the cookie your pixel writes | 7 days | WebKit | 24 March 2020 |
| Safari cap after a tagged link arrival | 1 day | WebKit, ITP 2.2 | 24 April 2019 |
| Meta audience retention, default | 30 days | Meta Business Help Centre | checked 21 Sep 2026 |
| Meta window for dropping a duplicate event | 48 hours | Meta Conversions API docs | checked 21 Sep 2026 |
| Event Match Quality scale | 0 to 10 | Meta Business Help Centre | checked 21 Sep 2026 |
The third row matters. The old version of this article said audiences are “artificially capped at 7 days”. It said identity work stretches that window to 180 days. Retention, meaning how long someone stays in your audience, is a number you set on the audience. Meta’s stated default is 30 days, checked on 21 September 2026. The cookie lifetime is Safari’s. Only one of the two is a field you can type in.
The identity you collect at checkout outlives the cookie
First party data is what the customer handed you: an email at checkout, a phone number, a shipping city. You own it. No browser release deletes it.
Meta’s Conversions API is a direct link from your server to Meta’s, with no browser in between. Meta calls it a connection “from an advertiser’s server, website platform, mobile app, or CRM to Meta systems”. You send each event yourself. An event is one recorded action, such as a purchase. The browser stops being the messenger.
Hashing keeps that safe. Hashing scrambles a value into a code that cannot be turned back. SHA-256 is the standard recipe, and it turns an email into a fixed string that nobody can read back. Meta matches it against its own hashed records. It never holds the address. Meta is strict about which fields get that treatment.
| Field | What it is | Hashing |
|---|---|---|
| `em`, `ph`, `fn`, `ln` | Email, phone, first name, last name | SHA-256 required |
| `ct`, `st`, `zp`, `country` | City, state, postcode, country | SHA-256 required |
| `external_id` | Your own customer ID | Hashing advised |
| `client_ip_address`, `client_user_agent` | The visitor's IP and browser | "Do not hash" |
| `fbc`, `fbp` | Meta's click and browser cookies | "Do not hash" |
The effect is the one the old article described well. Someone taps your ad on Instagram at lunch. They buy on a laptop that night. The browser sees two strangers. The hashed email from checkout gives Meta one person. The sale attaches to the ad, and the buyer drops out of your non buyer list.
A toggle is not a delivery. Advanced matching switched on in a settings screen proves only that a switch moved. We open stores where the setting reads on and the server sends nothing usable. Check the data, not the checkbox.
Event Match Quality tells you whether the match worked
Event Match Quality is Meta’s score out of 10. It rates how well your customer data matches an event to a Meta account. Meta labels it Poor, OK, Good or Great. Three things drive it: which fields arrive, how clean they are, and the share of events that find an account. You read it in Events Manager, Meta’s dashboard for your tracking data.
The Dataset Quality API, a feed that lets software pull Meta’s quality report, shows the same thing in detail. It reports coverage for each field. It also reports which identifying keys arrived to match duplicate events. That view catches a store whose settings screen looks tidy.
De-duplication stops one sale being counted twice. Your pixel and your server both report the same sale, so Meta needs a shared label to merge them. The pixel’s eventID has to match the event_id your server sends. Meta drops the copy only if it lands “within 48 hours of when we receive the first event”.
Get that wrong and you do not lose signal. You inflate it. That is the same failure from the other side, and it is the subject of the ghost tags problem.
On Shopify this starts as a setting, not a developer ticket
Shopify’s Facebook and Instagram channel, the app that connects your store to Meta, has three data sharing levels. Standard uses the Meta pixel alone. That is the path ad blockers and browser rules cut off. Enhanced and Maximum both add the Conversions API. Maximum also shares customer name, location, email and phone. Shopify says data sent server to server “can’t be blocked by browser-based ad blockers”. You set the level in your admin, under Sales channels.
Two Shopify deadlines have already passed. Either one may be the real cause of a sudden drop. Shopify retired checkout.liquid, the old file for editing checkout, and the additional scripts box on the Thank you and Order status pages on 28 August 2025. Script tags there, which are small code snippets added to a page, ended the same day for Plus stores, and on 26 August 2026 for everyone else. If your Meta snippet lived in that box, it stopped running on your best page.
Anything custom now runs as a web pixel, Shopify’s approved way to run tracking code, in what Shopify calls a Lax sandbox. A sandbox is a fenced off space. Your code gets a set list of browser features, not the whole page. Shopify is blunt about the trade. Its page says that “adding and using custom pixels is unsupported by Shopify”. It adds that “compliance with applicable laws, consents, code security, troubleshooting, and updates are your responsibility”.
This work is dull and it lasts. The signup tracking we added to a client’s product has run in their live code for 142 days, 17 April to 6 September 2026. We wrote down what we changed and what we left alone. Durable measurement looks like that. It does not look like a dashboard that spikes for a fortnight.
What breaks, and who owns it
Server side tracking, where your server sends the data instead of the browser, fails quietly. So it needs an owner with a name. These are the failures we see repeat.
| What breaks | The signal it leaves | Who owns it |
|---|---|---|
| Pixel and server events with no shared `event_id` | One sale counted twice inside 48 hours | Whoever publishes the pixel |
| A raw email sent where SHA-256 is required | Match quality falls while the setting reads on | Your developer or app vendor |
| Consent refused, event sent anyway | An exposure on your domain, not Meta's | You, with your privacy counsel |
| More than 8 priority events on one domain | Events outside the eight stop steering delivery | Whoever holds the Business Manager |
| A Meta snippet left in additional scripts | Purchases missing since 28 August 2025 | Your theme or checkout owner |
Aggregated Event Measurement is Meta’s way of counting conversions from people who opted out of tracking, such as through the iPhone prompt called App Tracking Transparency (ATT). It limits each domain to eight priority conversion events, the actions Meta ranks highest. You set them in Events Manager, and the domain has to be verified, which means you have proved to Meta that you own it. Pick eight that map to money. The rest is reporting.
Consent belongs on the same list. Shopify’s Customer Privacy API records what shoppers agreed to and applies those choices to Shopify surfaces, pixels included. It covers four purposes: preferences, analytics, marketing, and sale of data. A server side setup that ignores those choices is not an upgrade. It is a liability with better numbers.
Fixing the plumbing changes which number you can trust. That is the argument in profit over return on ad spend. The same idea runs through server side tracking and data integrity. A short list of durable identities beats a long list of dying cookies.
Three things to do this week. Read your Event Match Quality score in Events Manager and write it down with today’s date. Check that a shared
event_idleaves both the pixel and your server. Confirm your Shopify data sharing level, and name the person who owns it.
Common questions
Does the Conversions API bring back the audience sizes I had before?
No. It changes which events Meta can match to an account, so more sales attach to the ad that caused them. Retention is still the window you set. Safari still deletes pixel cookies after seven days of use with no visit back.
Do I still need the browser pixel if I send events from the server?
Yes. Meta expects both and removes the duplicate. Send the same event_name and a shared event_id from each side. Meta drops the second copy if it arrives within 48 hours of the first.
What is a good Event Match Quality score?
Meta scores it out of 10 and labels it Poor, OK, Good or Great. The score reflects which fields you send, how clean they are, and the share of events matched to an account. Track your own score week on week.
My Shopify data sharing is already on Maximum. Am I finished?
Not yet. Maximum turns on the Conversions API and shares name, location, email and phone. It does not tell you what reached Meta. Open Events Manager and read the match quality and duplicate figures for the last seven days.
Did anything in my store stop sending events without telling me?
Possibly. Shopify sunset checkout.liquid and additional scripts on the Thank you and Order status pages on 28 August 2025. Script tags there ended for non-Plus stores on 26 August 2026. Code left in those places no longer runs.
Vendor documents checked on 21 September 2026. Meta: the Conversions API, its customer information parameters, its deduplication guidance, the Dataset Quality API, Event Match Quality and Aggregated Event Measurement. Shopify: the Web Pixels API, the Customer Privacy API and Meta data sharing. WebKit: full third party cookie blocking and ITP 2.2.
