Multi-Touch Attribution Built on Server-Side Event Data

Nine of the last eleven attribution rebuilds we inherited had a counting problem before they had a modelling problem. Duplicate and mistimed conversion events were overstating tracked revenue by 4 to 31 percent against the client's own settled ledger. A path model built on that data allocates money that was never earned. So the first weeks of any attribution engagement here go on making the event layer reconcile, and we do not model until it does. How we sequence it: We take your settled revenue — the payment processor for fintech and ecommerce, the net gaming revenue ledger for casino and sportsbook operators — and match it to conversion events day by day, by transaction identifier, not in aggregate. Gaps get named: dedupe keys missing between browser and server, refunds and chargebacks never written back, deposits counted at authorisation rather than settlement, bonus-funded stakes counted as revenue. Then we fix collection: a server container in your own cloud project, an event_id contract enforced across Meta's Conversions API, TikTok Events API, Google's Data Manager API and Reddit CAPI, and for app-first operators a single server-to-server postback path through AppsFlyer or Adjust so app and web share one revenue definition. Only then the model. We fit a Markov removal-effect model and a Shapley allocation on the same cleaned path set and report where they disagree, because the disagreement is the interesting part: it names the channels sitting on paths they do not cause. Decay is fitted to your observed lag, not assumed. A sportsbook's registration-to-first-deposit curve and a fintech account's application-to-approval curve are weeks apart, and a default seven-day window quietly punishes upper funnel in both. Every model we ship is checked against a withheld experiment. You hold spend out of one channel or one region for two to three weeks and we compare the model's predicted contribution against what the holdout shows. If the model is wrong by more than the test's own error bar, it does not ship. We say so and we rebuild. This is the step most shops skip, and it is why attribution has the reputation it has. What we do not do: We do not replace your reporting stack or build dashboards. You get a model, a documented event contract and the query layer to run it; your BI team owns the pixels on the screen. We do not attribute paid channels for gambling operators without the affiliate postback feed in the same dataset — affiliate and paid claim the same depositor constantly, and any model missing one side is arithmetic theatre. We do not fit path models to channels running fewer than roughly 300 conversions a week; below that the interval is wider than any decision you would take from it, and we will point you at geo testing instead. We do not tune a model until it flatters a channel your team has already committed to, and we have ended an engagement over that request. Who this is not for: Brands under about 2,000 conversions a month. Teams who need a number by Friday for a board deck. Anyone whose collection is entirely client-side and who will not move to server-side collection — we cannot repair identity loss caused by browser policy from inside the browser, and we will not pretend otherwise. Working in the Gulf: For UAE and Saudi operators we build consent and retention logic against the local personal data protection regimes as well as GDPR where EU traffic exists, and we specify the Arabic campaign and event taxonomy alongside the English one. Retrofitting a bilingual naming convention after two years of spend is a rebuild, not an edit.