Cookieless Measurement and Consent Architecture Rebuild

On the iOS traffic we have measured across three fintech accounts, moving identity from browser-written cookies to a server-set first-party identifier recovered between 11 and 19 percent of signups that had previously landed in direct or unassigned. That is the honest size of the prize. It is not the 40 percent that vendors selling identity resolution will quote, and the recovery is uneven: large for considered purchases with lags past seven days, close to nothing for same-session impulse orders. We size it for your account before you commit to the rebuild. What the constraint actually is: Safari caps script-written first-party cookies at seven days, and at 24 hours when the landing URL carries link decoration. A fintech approval funnel runs 9 to 30 days from first click. That gap, not third-party cookie policy, is what breaks most measurement in this region, where iOS share in the UAE and Saudi Arabia sits well above the global average. So the work is a first-party collection endpoint on your own registrable domain, setting an HttpOnly identifier server-side, with the event contract enforced there rather than in the browser. We do not use CNAME cloaking to get there. It is capped by the same policy on Safari, it breaks on certificate renewal, and it reads to a regulator exactly as it is designed to read to a browser. We will not implement it, including on request. The rest of the architecture: Consent Mode wired to an actual consent record, with the advertising data and personalisation signals sent as distinct values rather than collapsed into one flag. Enhanced conversions and platform advanced matching built on hashed identifiers you already hold lawfully, hashed server-side so raw values never reach a tag. SKAdNetwork and AdAttributionKit conversion value schemas designed against your real early revenue signal instead of the default install postback. For gaming and gambling apps that means choosing between measuring first deposit and measuring day-three retention, because the postback window will not give you both. That is a commercial choice we make with you, not for you. For Gulf operators the collection endpoint runs in region. UAE and Saudi personal data protection law both constrain cross-border transfer, and standing the endpoint up in a Gulf region rather than in Frankfurt or Iowa removes an argument with your legal team that otherwise arrives after launch. The retention schedule and the deletion path go into the design, because a measurement system with no deletion path is a liability someone eventually has to unpick. On modelled conversions and clean rooms: The browser attribution APIs return aggregated, noise-injected summaries. They answer campaign-level questions and cannot answer user-path questions, and we label every modelled number as modelled in every deliverable we produce. Clean rooms are useful for overlap and reach questions and are governed by aggregation thresholds that will silently drop your smaller segments. We tell you which of your questions each one can actually answer before you sign a data agreement, not after. What we refuse: We do not implement fingerprinting or probabilistic device matching. We do not connect third-party identity graphs whose consent provenance we cannot trace. We do not promise full recovery of lost conversions, and where a vendor in your evaluation has promised it, we will put that claim in writing next to what their method can actually support. We take no commission or referral fee from any vendor we recommend, here or anywhere else. Who this is not for: Teams with no engineering capacity to own a server endpoint after we leave. Anyone who wants a tag added rather than a system changed.