AppsFlyer Implementation and Conversion Value Schema

SKAdNetwork 4 gives you a six-bit fine conversion value in the first postback window and a three-way coarse value after it. Sixty-four numbers, then low, medium or high: that is the whole vocabulary available for describing a paid iOS install to a network. Most schemas we inherit spend it on install-day revenue buckets that were never going to predict anything. Designing that schema is the part of an AppsFlyer implementation that decides whether the next year of iOS spend can be optimised at all, and it takes about a week of argument with your data team, not an afternoon in a dashboard. The schema question, concretely: For a fashion app, first purchase commonly lands outside the measurement window, so we encode first-session catalogue depth, add-to-bag and account creation state rather than day-zero revenue, and we set the activity window accordingly. For a food or local services app the first completed order usually falls inside 48 hours, so revenue bucketing earns its place and the resulting schema looks nothing like the fashion one. This is why we ask what you sell before we ask what you spend, and why a schema copied from another client is worth nothing. Scope: Integration audit of the SDK as your engineers have shipped it, read against the current AppsFlyer iOS and Android guides, with findings written as tickets in your tracker rather than as a slide. Server-to-server event validation across a recorded test device matrix, so every event is observed firing rather than assumed. OneLink configuration and deferred deep linking, including the paths that habitually break: cold install from a web landing page, and re-open from an email client that rewrites links. Attribution window settings, meaning the seven-day click and 24-hour view-through defaults and the re-engagement lookback, which is wrong out of the box for nearly every subscription and repeat-purchase app. Protect360 rules tuned against your own install profile rather than the shipped defaults. Cost and raw data out through the Pull API and Data Locker into BigQuery or Snowflake. Reconciliation between SKAN postbacks, aggregated advanced privacy and your own event data, with the variance explained rather than averaged away. The boundary on code: We specify and we review. Your engineers implement. We have watched enough agencies take commit access to an app they do not maintain to know how that ends, and a measurement spec your own team wrote the code for is a spec your own team can defend in six months when we are gone. Sign-off: An implementation is not finished when the SDK compiles. We call it done when network-reported installs and AppsFlyer installs agree inside an agreed band, every in-app event fires in a recorded session on both platforms, and someone on your side has reproduced the checks without us in the room. What we refuse: We will not accept the AppsFlyer dashboard as the reporting layer for a media budget past roughly 150,000 euro a month; raw data goes to your warehouse or this engagement does not work. We will not sign off a setup whose headline numbers depend on probabilistic matching in an ATT-declined population, and we will put that in writing rather than in a footnote. We do not buy media and we will not work underneath an agency that does, because the party checking the attribution cannot be paid on the numbers it produces. Who this is not for: Pre-launch apps with no event stream to model a schema against. Teams who want a migration from another vendor rather than a build, which is separate work. Anyone expecting this finished in a fortnight around an engineering team that has not yet been told it is happening.