Every workaround on this list is an attempt to answer one question Apple and the browsers no longer let you ask directly: did the money work?
The last post in this track covered the wall Apple built. SKAdNetwork hands you coarse, delayed, aggregated postbacks and nothing else. This post covers what the industry built to work around that wall, and the cookie deprecation wall on the web, and the consent wall under GDPR and ATT.
I own the reconciliation layer underneath a DSP and an ad exchange that process 200M+ devices’ worth of ad events a day at InMobi. Every technique below crosses my desk in one form or another, and the job is telling the legitimate engineering responses from the cat-and-mouse evasion and the marketing dressed up as measurement.
So that’s today’s post.
Today’s Post
Five workarounds to the privacy walls, graded for trust, in the order I’d rank them.
- Server-side Conversions APIs, and why relocating the event beats losing it
- Fingerprinting, the one Apple explicitly forbids
- Data clean rooms, and the aggregate questions they can and can’t answer
- Modeled conversions, an estimate wearing a count’s clothing
- First-party identity, and the Privacy Sandbox bet that just collapsed
- The ranking, and the one discipline that ties all five together
1. Server-side Conversions APIs: reclaiming the signal you used to get for free
The browser used to be generous. A pixel fired, a cookie was read, the event reached the platform. Safari’s ITP, third-party cookie deprecation and ad blockers made the browser hostile, so the event moved to a place you still control: your own server.
This is what Meta’s Conversions API and Google’s server-side tagging do. Your backend tells Meta a purchase happened, server to server, instead of asking the user’s browser to carry that message. You already observed the purchase. You’re changing the delivery route, not manufacturing new signal.
Three things make this defensible. The event is real and first-party, it happened on your property. It survives ad blockers and cookie loss because it never depends on the browser to carry it. The matching to a user identity is done by the platform, using hashed identifiers you send such as a hashed email or phone number, under the platform’s own terms, not by you re-identifying anyone yourself.
The catch is coverage. Server-side signal only recovers what you can already identify. It’s excellent for logged-in commerce, where you know the buyer’s email, and it does little for anonymous top-of-funnel traffic. And the match rate, how often the platform can tie your hashed email to a real profile, quietly determines how much signal comes back.
My read: this is the most trustworthy technique on the list, when the events are real and the match rate is decent. It’s not a trick. It’s moving a measurement you were always entitled to off a channel that stopped being reliable.
2. Fingerprinting: the one Apple explicitly forbids
When there’s no logged-in user and no identifier, the tempting move is to reconstruct one from signals the device leaks anyway: IP address, user agent, screen dimensions, OS version, language, timezone, install timing. Enough of these combined produce a probabilistic fingerprint, a statistical guess that an install probably came from the device that saw an ad 90 seconds earlier.
Here is the part people gloss over. Apple’s developer guidelines and SKAdNetwork’s terms both prohibit fingerprinting for attribution, even when the user has already granted ATT consent. Apple’s stated position is that fingerprinting is never permitted, because the user has no way to see it or refuse it the way they can refuse the ATT prompt.
So this technique lives in a contested zone. It’s technically effective, probabilistic IP-and-timing matching genuinely correlates ads to installs, which is exactly why it persists. It’s against the rules, and Apple can and does reject apps and SDKs caught doing it. It’s fragile, because Apple keeps shipping countermeasures: Private Relay masks IP for Safari traffic, the Required Reason API forces developers to justify any access to fingerprintable signals, and platform-level enforcement keeps tightening with each release.
My read: this is wishful thinking dressed as a strategy. The numbers it produces look plausible, but they sit on a foundation Apple is actively demolishing and explicitly forbids. Build your reconciliation on it and you’re one iOS update from a discontinuity you can’t explain to finance. I don’t put signals I’m not allowed to use into a system of record.
3. Data clean rooms: privacy-safe joins on aggregates
The most architecturally interesting response is the data clean room. Two parties bring their data, a join happens inside a sandbox, and neither party can read the other’s raw rows, only aggregated and privacy-thresholded outputs come out.
Google’s Ads Data Hub, Amazon Marketing Cloud and Meta’s own clean room all work the same way. You upload your conversion data, the platform holds its ad-exposure data, the join happens on hashed keys, and output constraints apply: a minimum group size before any number is returned, no row-level export, sometimes added noise. You learn that users exposed to a campaign converted at a certain rate, without ever seeing which users.
The join genuinely happens on rich data, so the aggregate answer is trustworthy. The limits are just as real: you can only ask aggregate questions, the thresholds suppress small segments the same way SKAdNetwork’s crowd-anonymity rule does, each clean room is walled to its own platform (Ads Data Hub won’t tell you anything about Amazon), and using one well takes real first-party data and engineering investment.
My read: clean rooms are trustworthy for the questions they’re built to answer, incrementality and overlap at aggregate scale. They are not a replacement for user-level attribution, and any vendor who implies otherwise is overselling a narrower answer than the deck suggests.
4. Modeled conversions: an estimate wearing a count’s clothing
When consent or platform rules block you from observing a conversion directly, the platforms increasingly model it instead. They watch the conversions they can still see, build a statistical relationship between observed signals and outcomes, and extrapolate to fill in the rest.
Google’s Consent Mode does this when a user declines consent: Google doesn’t see that person’s conversion, so it models what a similar consented cohort likely did and reports the modeled number in your account. Meta’s own modeled conversions blend CAPI signal, statistical modeling and aggregated SKAdNetwork-style data the same way.
The honest framing is that these are estimates presented as counts. A modeled conversion is the platform’s best statistical guess, not an event that was observed and logged. Two things make that treacherous. The model belongs to the platform, and the platform is also the seller, so Google modeling Google’s own conversion lift has an obvious incentive problem you cannot audit from outside. And a modeled number doesn’t reconcile to anything you own. If my deterministic log says 1,000 conversions and the platform reports 1,340, there is no row I can inspect for the extra 340. They’re a distribution, not events.
My read: useful as a directional signal, dangerous as a source of truth, and especially dangerous when the modeler is also the party being measured. I calibrate modeled conversions against my own deterministic logs wherever they overlap, and I never let them be the number of record.
5. First-party identity: the durable bet, and the bet that just collapsed
The longest-term answer is to stop relying on any third-party identifier and build measurement on a relationship you actually own.
Hashed first-party identifiers are the backbone here. If a user logs in and gives you an email, you have a durable, consented key across devices, and CAPI matching on that hashed key is only as strong as the login rate behind it. UID2, the Unified ID 2.0 framework, is the industry’s attempt at a shared version of the same idea: a hashed, salted, consented email or phone number as a deterministic key. The Trade Desk originated UID2 and in 2024 handed operation to the nonprofit Prebid.org, contributing the source through the IAB Tech Lab. It depends entirely on users sharing an email and consenting, so it works where login exists and fails on anonymous traffic.
Google’s platform-level answer was the Privacy Sandbox: instead of identifying users, the browser or the OS would derive coarse interest Topics for targeting, with attribution handled through aggregate APIs, a design conceptually close to SKAdNetwork’s device-side, aggregated model.
It never gained traction. Google reversed course on third-party cookie deprecation in July 2024 in favor of a user-choice prompt, then abandoned even that prompt in April 2025 and left third-party cookies in place, then retired Topics, the Attribution Reporting API and Protected Audience outright in October 2025 for low adoption. The most-hyped cookie replacement of the decade quietly folded in fifteen months.
My read: first-party identity is the only technique on this list that gets stronger over time instead of weaker, because it’s built on a consented relationship rather than a loophole or a platform’s roadmap. The catch is brutal honesty about coverage. It only measures the users who logged in. Everything anonymous, which is most of the top of the funnel, is still back on SKAdNetwork aggregates, clean rooms and modeling.
6. The ranking, and the discipline underneath it
Step back and the same pattern runs through all five. Measurement is migrating from deterministic and individual to aggregated and modeled, and that’s not a temporary inconvenience the industry engineers its way past. It’s the new equilibrium, and every regulatory and platform signal points the same direction.
So here’s my ranking, plainly, from a reconciliation seat that owns 200M+ devices’ worth of daily events. Server-side first-party events come first, trustworthy because you observed them yourself. Clean-room aggregates come second, trustworthy for the narrow aggregate questions they’re built to answer. First-party identity comes third, trustworthy where it has coverage and honest about where it doesn’t. Modeled conversions come fourth, directional only, never the number of record, especially when the modeler is the party being measured. Fingerprinting comes last, effective until it isn’t, and against the rules the entire time.
The techniques that fight the industry’s direction, fingerprinting most of all, are the fragile ones, one OS release from extinction. The techniques that embrace it, server-side first-party signal, clean rooms, owned identity and principled modeling, are the durable ones.
Takeaways
Five techniques, one ranking, one thesis: a deterministic log, a privacy-thresholded aggregate, a statistical model and a contested guess are four different kinds of truth, and the failure mode is pretending they’re the same number.
Final Words
The discipline that ties this whole track together is knowing which number you’re holding. A deterministic event you logged, a privacy-thresholded aggregate, a statistical model’s estimate and a contested probabilistic guess are four completely different kinds of truth, and the expensive mistake is having all four labeled “conversions” on one dashboard.
That closes out the ad-tech track. We went from the auction and the identifiers through SKAdNetwork and out the other side into a world where the identifier is gone and measurement is a modeling problem. Pick one dashboard your team reads every week and ask which of these five kinds of number is actually behind it.
Reply and tell me what you found.
Cheers, Hoshank