If a large share of your traffic is on iPhone, some of your conversions never make it back to Meta or Google. The sale happened. The tracking did not. Your campaigns then optimize on a picture that is missing exactly the customers who bought.
This is not a bug in your setup. It is how Safari and iOS are designed to work. Here is what actually happens, why it hurts paid performance, and what a durable fix looks like.
What Intelligent Tracking Prevention does
Safari ships with Intelligent Tracking Prevention (ITP). Among other things, it caps how long client-side cookies survive:
- Cookies set from JavaScript are limited to 7 days.
- In some cross-site cases, that drops to 24 hours.
- Cookies tied to known trackers can be cleared much sooner.
The cookies your pixels rely on, like _fbp for Meta or _ga for Google, are set exactly this way. So a shopper who clicks an ad on Monday and buys the following week looks like a brand new, unattributed visitor by the time they convert. The purchase is real. The link back to the ad is gone.
iOS reinforces this at the app layer. After App Tracking Transparency, most users never grant cross-app tracking, so the signals that used to stitch a journey together simply are not there.
Why your ad platforms feel it
Meta, Google and TikTok bid and optimize on the conversions you send them. When a slice of conversions goes missing, three things follow:
- Wasted spend. The algorithm cannot learn from buyers it never sees, so it keeps paying to reach lookalikes of an incomplete set.
- Understated ROAS. Your dashboards show fewer conversions than really happened, which makes good campaigns look mediocre.
- Worse targeting over time. Optimization compounds. A model trained on partial data drifts further from your real customers each week.
The gap is largest for exactly the brands that should perform best: high-consideration purchases, repeat buyers, and anyone shopping on an iPhone.
Why client-side pixels cannot win this
A browser pixel runs inside the environment that is actively limiting it. It depends on cookies ITP shortens, and scripts that ad blockers and privacy browsers can drop before they ever fire. You can tune a client-side pixel, but you cannot opt out of the platform rules it runs under.
The only way to keep the data is to move the record of the conversion out of the browser.
The fix: server-side, first-party
Two changes solve most of the loss:
- Send conversions server-side. The purchase is reported from your own server or edge directly to the ad platform's conversions API. The browser is no longer in the path, so it cannot shorten or block the event.
- Set a first-party cookie on your own domain. Instead of a third-party cookie the browser distrusts, identity lives in a first-party cookie served from your domain. It survives ITP far better and keeps returning visitors recognizable.
| Client-side pixel | Server-side + first-party | |
|---|---|---|
| Cookie lifetime on Safari | Capped at 7 days | Durable, first-party |
| Affected by ad blockers | Yes | No, for the server event |
| Purchase after ITP window | Often lost | Retained |
| Data sent to ad platforms | Partial | Complete |
The goal is not to track people more aggressively. It is to stop losing conversions you already earned, from customers who consented, while respecting the choices of those who did not.
What good looks like
If you are evaluating a fix, look for all of the following, not just one:
- Conversions delivered server-side to each ad platform, not only a browser pixel.
- A first-party cookie on your own domain, so identity survives ITP.
- Data captured from the order or event itself, so a blocked script cannot cost you the sale.
- Consent enforced before anything is sent, per visitor and per region.
- Sensitive fields hashed before they leave, so the platforms match on identifiers without receiving raw personal data.
That is the model SetRoasFlow is built on: one first-party customer data layer, collected at the edge, delivered server-side to every channel you run.