iOS Signal Loss: How to Measure Ads Now
Short answer
App Tracking Transparency, browser tracking prevention and the decline of durable cross-site identifiers removed much of the identity that ad platforms once used to join a click to a purchase, so platform-reported conversions are now part observed and part estimated. The workable response is layered: send events from your server through Meta's Conversions API and Google's enhanced conversions to restore first-party signal, manage the business against blended numbers such as marketing efficiency ratio and new-customer acquisition cost, and run occasional geo or holdout tests to establish what spend is genuinely incremental. Expect platform totals and your own order data to disagree permanently, and decide deliberately which of the two governs budget decisions.
Published 2026-09-28 · Updated 2026-09-28
What actually changed
Three things happened in sequence. Apple's App Tracking Transparency required apps to ask before accessing the identifier used for cross-app tracking, and a large share of users declined, which removed the deterministic link between an in-app ad view and a later purchase. Safari's tracking prevention had already been shortening the life of client-set cookies, so a return visit a fortnight later frequently arrived as a stranger. Regulatory and browser pressure has continued in the same direction since.
The third-party cookie story has been far less tidy than the headlines suggested, with timelines moving repeatedly and the destination changing more than once. What has not changed is the direction of travel. Durable cross-site identity is becoming less available, whatever mechanism eventually replaces it, and any measurement approach that assumes a stable identifier across sites and sessions is built on something that keeps being withdrawn from under it.
The result is that the figures in your ad platform are now a mixture of observed and estimated events. That is not a fault waiting to be repaired; it is the new default. The useful question is which decisions those numbers remain good enough to support. They are reasonable for comparing two ad sets in the same account over the same period, and poor for telling you what the business actually earned last month.
Why platform totals and store totals disagree
Add up the conversions reported by Meta and Google and the sum will usually exceed the orders in your store. Each platform counts a conversion it believes it influenced inside its own attribution window, so a buyer who saw a Meta ad and then clicked a branded search result is counted twice. Neither platform is lying. Each is answering a narrower question than the one you are asking, and neither can see the other's contribution.
Underneath that there is a second, opposite effect. Signal loss causes genuine under-reporting on some paths, particularly in-app placements on iOS and European traffic where consent is refused, so the same account can over-count in aggregate while under-counting specific segments. Trying to reconcile all of this into one true number is a project that never finishes. The workable alternative is to keep platform numbers for in-platform decisions and hold a separate source of truth for the business.
Choose that source once and make it the one that governs budget. For most direct-to-consumer brands it is the store's own order data, net of refunds and cancellations, set against total marketing outlay for the same period. Everything else is instrumentation rather than truth. Agreeing this in writing at the start prevents the monthly argument about whose dashboard is correct, which is an argument nobody has ever won.
Restore first-party signal with server-side events
The first repair is sending conversions from your server as well as from the browser. Meta's Conversions API and Google's enhanced conversions both accept hashed customer information from a source that ad blockers, browser restrictions and dropped tags cannot interfere with. Done properly, with a deduplication key shared between the browser event and the server event, you recover a meaningful share of conversions that would otherwise never have been visible to either platform.
Two implementation details decide whether it works at all. Deduplication must use a consistent event identifier, or the same purchase arrives twice and every number downstream inflates quietly. And the server event should carry the same value, currency and content parameters as the browser event, because a stripped-down server event reporting a conversion with no value teaches the bidding algorithm very little. Check both by pushing a live test order through and following it in the platform's event debugger.
Match quality is the lever most accounts ignore
Server events only help if the platform can match them to a person, and that depends entirely on the customer parameters you send: email, phone number, first and last name, city, postcode, country, the click identifier and your own external identifier. Meta scores this in Events Manager out of ten, and Google reports diagnostics on enhanced conversions. Most accounts send two or three parameters when seven are available with a little plumbing.
The fastest gains come from plumbing rather than strategy. Capture the click identifier on landing and persist it in first-party storage so that it survives the journey to checkout, rather than trying to read it at the point of purchase. Pass postcode and country, which are usually available and rarely sent. Normalise formats before hashing, with lowercase text, trimmed whitespace and phone numbers in international format, because an inconsistently formed hash matches nothing and fails silently.
- Persist the click identifier at landing, not at checkout
- Normalise then hash consistently; a formatting slip destroys matching without warning
- Send value, currency and content identifiers on the server event as well
- Deduplicate with one shared event identifier across browser and server
Blended metrics: what to manage to
Once per-platform attribution is partly modelled, the number to steer by is a blended one. Marketing efficiency ratio, total revenue divided by total marketing spend, cannot be double counted because it does not care which channel takes credit. Alongside it, new-customer acquisition cost, calculated from the orders your store identifies as first purchases, tells you what growth is actually costing. Between them they answer the two questions a board asks, without depending on anyone's attribution model.
Use the platform figures for what they are good at, which is comparing creative and ad sets inside the same account over the same period, where the measurement bias is at least consistent across the options. Use blended figures for budget decisions between channels and for judging whether the month worked. Problems start when somebody optimises an individual campaign against a blended number that moves for a dozen reasons the campaign does not control.
Watch the lag as well. Blended metrics move slowly and respond to everything, including email, organic search, a wholesale order or a press mention, so a single poor week means less than it appears to. Set a review period, a fortnight for most brands, and resist rewriting the budget on daily noise. Longer purchase cycles need longer windows, and comparing like periods matters more than comparing like days.
Incrementality tests you can actually run
The honest answer to what a channel contributes comes from switching it off somewhere. A geo holdout splits comparable regions, keeps spend running in one set and pauses it in the other, then compares total sales rather than attributed sales. It is blunt, it costs some revenue while it runs, and it remains the closest thing to a real answer that most brands can produce without specialist tooling or a data science team.
Keep the design modest. Choose regions with similar historical baselines, run long enough to cover a normal purchase cycle plus a margin, avoid promotional periods, and change only one thing at a time. Smaller brands often lack the volume for a clean read, in which case a simpler on-and-off test on one campaign across matched periods gives a directional answer, provided everybody accepts in advance that directional is all it is.
Platform-native lift tests are the low-effort alternative and worth running, with one caveat: they are graded by the party being tested. Believe the direction more than the magnitude, and use them to decide which channel deserves a proper geo test rather than as a final verdict. A channel that cannot demonstrate lift in its own test almost certainly has none worth paying for.
What to stop doing
Stop trying to make the platform match the store. The reconciliation project consumes analyst time and ends in a fudge factor that has to be recalculated every time an attribution setting changes. Record the gap, watch whether it moves, and move on. A stable discrepancy is information. A discrepancy that suddenly changes is a signal that something in the tracking has broken, and that is the only version of this worth investigating urgently.
Stop changing attribution windows mid-flight. Switching from seven-day click to one-day click in the middle of a test invalidates the comparison and usually produces a panic manufactured by the setting rather than by the market. Pick the window that matches your purchase cycle, write down why you picked it, and change it deliberately with a dated note in the annotations so that future comparisons can be corrected for it.
And stop judging creative on a single day of platform data. Modelled conversions arrive late and unevenly, so a creative that looks dead on day one often reports respectably by day four. Give each test enough conversions to mean something before killing it, and apply the same window to every candidate so the comparison stays fair even when the absolute numbers are imperfect.
Measurement layers and what each one is good for
| Layer | What it recovers | Where it falls short |
|---|---|---|
| Browser pixel | The fastest in-platform optimisation signal | Blocked, shortened or refused for a large share of traffic |
| Conversions API and enhanced conversions | Events that never reach the browser tag | Worthless without deduplication and good match parameters |
| Modelled conversions | Estimated volume where consent is missing | Needs scale; small accounts get noisier estimates |
| Blended metrics | A figure that cannot be double counted | Slow, and credits nothing to a specific channel |
| Geo or holdout tests | Genuine incremental contribution | Costs revenue, needs volume and a quiet trading period |
Related questions
Is the Meta pixel obsolete now?
No. The browser pixel still delivers the fastest optimisation signal and remains the basis of in-platform learning. What changed is that it can no longer be the only source, because a substantial share of events never reach it. Run the pixel and the Conversions API together with proper deduplication and treat the pair as one system rather than as a primary feed and a backup.
What should our event match quality be?
Higher than it currently is, in almost every account worth auditing. Meta shows a score out of ten in Events Manager, and the practical work is sending more customer parameters, normalising them consistently before hashing, and persisting the click identifier from landing through to purchase. Chasing a specific target matters less than closing the obvious gaps, which are usually postcode, phone and external identifier.
Which attribution window should we use?
One that matches how long your customers actually take to buy, which you can read from your own order data rather than guess. Impulse products are fine on a short click window, while considered purchases lose real conversions on one. Whichever you choose, hold it constant across comparisons and record the date of any change, because the setting moves the numbers more than most campaign edits do.
How do we run a geo holdout on a small budget?
Pick two sets of regions with similar historical revenue, keep spend running in one and pause it in the other, and run for at least one full purchase cycle outside any promotional period. Compare total orders rather than attributed orders. If volume is too low for a clean read, test one campaign on and off across matched periods and accept that the answer is directional.
Does server-side tracking get around consent requirements?
No. Where consent is required it is required regardless of whether the request comes from a browser or a server, and building a server container to sidestep a banner creates a compliance problem rather than solving a measurement one. Used correctly, server-side collection respects the consent state and improves the quality of the events you are actually permitted to send.