Ad Revenue Attribution for Apps Monetised by Impressions

Ad revenue attribution is a join, not a dashboard. Impression-level revenue arrives from the mediation layer — AppLovin MAX and Unity LevelPlay expose it per impression per user, AdMob through the Firebase ad_impression event — purchase revenue arrives from your billing receipts, and the install source sits in a third system. The work is deciding how those three reconcile into one revenue figure that your bidding algorithms and your finance team will both sign. On the last three apps where I rebuilt this, corrected D7 blended ROAS moved between eleven and thirty-four percent against the average-eCPM allocation that was there before, and twice it moved down. That is the point. A number you can defend is worth more than a flattering one. What actually gets built: The path that carries impression-level revenue three ways at once: into the MMP as an ad revenue event, into your warehouse in raw form, and into SKAdNetwork and AdAttributionKit conversion values in a compressed form that has to survive six bits. Those are three encodings of the same money and each one needs its own decision. In the warehouse the revenue is modelled on install date rather than event date, because advertising revenue keeps arriving for months after an install, and event-date reporting quietly rewards whichever campaign happened to run during a high-eCPM week. The decisions I take a position on: Whether advertising revenue enters your Meta and Google value optimisation feeds at all, and at what lag. For most travel and utility apps it should not: the first-day signal is thin and it teaches the algorithm to find people who tolerate advertising rather than people who book. For a pet care app with a free tier feeding a subscription, the answer went the other way and we sent blended value. Which currency and precision the revenue lands in, because mediation reports micros in the network's settlement currency and a naive conversion introduces a drift that surfaces as an unexplained gap at month end. Whether rewarded impressions inside a single session are deduplicated, which changes ARPDAU more than anybody expects. Where I stop: Mediation waterfall and bidding optimisation is a different discipline and I will name someone who does it properly. SDK engineering: I write the schema and review the implementation, your engineers ship it. Dashboard building. I hand over models and SQL; putting them into Looker Studio or Amplitude is half a day I will quote separately rather than fold in silently. Not worth it below: Apps earning under roughly ten thousand euros a month from advertising, where the reconciliation costs more than the error it removes. Apps with no warehouse and no plan for one, because the raw impression stream is the whole asset and an MMP dashboard aggregates it away within days. Teams who have already decided what the number should say. Sequence: The first week is reading: mediation configuration, MMP event list, the current revenue query, and the last three months your finance team reconciled. The second week is the schema and the decision record, naming what joins to what, on which key, with which lag, and why. The third is implementation review with your engineers, then the first reconciled month recomputed against your existing figures with every delta explained line by line. I stay through the following month end, because the first close that uses the new number is where it either gets adopted or quietly abandoned. Languages: English and French. The decision record is written in both when your finance team reads French, at no extra cost.