AppsFlyer Implementation With an Owned Event Taxonomy

The SDK takes an afternoon. What takes six weeks is the event taxonomy, the SKAdNetwork and AdAttributionKit conversion value schema, and the attribution window settings, because all three get written into the historical series and changing them later means your before and after are not comparable. Apple gives you sixty-four fine-grained values and three postback windows to describe everything that happens after an install. Deciding what those sixty-four values mean is the engagement; installing the SDK is a task on it. The conversion value schema: Most schemas I inherit spend all sixty-four values on revenue buckets, which produces a postback saying a user paid and nothing about whether they will pay again. For a booking app I usually spend the first window on intent depth — search performed, dates selected, checkout opened — because the first twenty-four to forty-eight hours rarely contain a booking, and the second window on realised value. For a subscription app with a trial the split is different and the trial start is the only event worth encoding early. I write the mapping, the lock window logic and the decoding query, then test the schema against your last ninety days of real events, so the dead values are found before Apple finds them for you. Events: The taxonomy is named, versioned and documented before anything is instrumented: parameter names, types, currencies, and which events fire client-side against which are posted server to server. Revenue goes server side with receipt validation on, because client-reported revenue and your billing system will disagree, and that disagreement always surfaces during a board reporting cycle rather than on a quiet Tuesday. The settings that quietly decide your numbers: Click-through and view-through windows per partner. Re-engagement against re-attribution windows, and what each does to your retargeting reporting. Self-reporting network deduplication with Meta and Google. Agency permissions and transparency, so an agency cannot see or claim installs it did not drive. Protect360 rules, where I turn on blocking for the patterns worth blocking and leave the rest in reporting, because an over-tuned fraud configuration quietly starves your best campaign and the team blames the creative. Where the data goes: Data Locker into your warehouse from the first day, in raw form. The dashboard belongs to your media team; the warehouse is what you still own when you change provider, and that day arrives for most apps. Excluded: Migration of historical data from a previous provider. It can be loaded, but it will not reconcile, and I will explain exactly where rather than pretend. Media buying and campaign management. Engineering: I specify and review, your developers ship. Running a second provider alongside for comparison, which I will not do at any price. Not for you if: You have no server-side revenue source, so receipt validation cannot be wired properly. You want somebody to configure a dashboard to a specification you have already written. You need this live in two weeks; the schema testing alone takes longer, and shipping it untested is the expensive kind of fast. Order of work: Reading first: current implementation, event list, network mix, and what finance reconciles against. Then the schema and taxonomy documents, reviewed with your engineers and your media lead in the same room, because a taxonomy signed by only one of them does not survive contact with the other. Then implementation support while your team ships, a validation pass against live traffic before sign-off, and a first-month reconciliation where every gap between the provider, the stores and the warehouse gets an explanation or a fix.