User-Level Ad Revenue Attribution for Mixed-Monetisation Apps

An app that earns from both subscriptions and advertising typically reports 40 to 60 percent of its real revenue back to the channels bidding for its users. The ad half arrives as a monthly network payout, aggregated, attached to nobody. Google and Meta then bid against half a picture and quietly under-buy the users who monetise through inventory rather than checkout. This engagement closes that gap: impression-level ad revenue, joined to install cohorts, sent back to the systems that make bids. The wiring: Impression-level revenue out of AppLovin MAX, ironSource LevelPlay or AdMob's impression-level ad revenue feed into Firebase. Into the MMP through the AppsFlyer ad revenue API or Adjust's ad revenue SDK, tagged by mediation source and ad unit so a rewarded video and an interstitial never collapse into one number. Out again as ad_impression to Google and as a value event to Meta, with the network fee treated consistently on both sides so your revenue does not silently change definition between two dashboards. Everything lands in BigQuery as well, modelled in dbt, because the MMP is a routing layer and not your book of record. The part that is judgement rather than plumbing: Deciding what number you bid to. Realised day-7 revenue is honest and too slow. A predicted value is fast and wrong in a way you have to bound. We fit a prediction on your own cohorts, hold out the most recent ones, and report the error rather than the correlation. We tell you at which cohort size the prediction stops being usable, and we set the day at which the bid switches from predicted to realised. On the SKAdNetwork side we encode combined subscription and ad revenue into the conversion value schema, choose the bucket boundaries from your actual revenue distribution rather than a template, and set the SKAN 4.0 coarse tiers so the low tier still carries information. What we will not sign off: We will not call any of this truth. Deterministic in-app events, modelled SKAN postbacks and Meta's own attribution will disagree with each other by twenty to forty percent, permanently, and the deliverable includes the reconciliation memo that says which number governs which decision. We will not migrate your MMP and rebuild attribution in the same quarter; one of them has to be the stable reference while the other moves. We will not put revenue events behind a client-side SDK call we cannot verify server side. We will not build a prediction on fewer than twenty-six weekly cohorts, and when the data is thinner we say so and hand you realised-revenue bidding instead of a model with a confidence interval wider than your margin. Who this is not for: Apps monetised only by advertising with no in-app purchase path. The work is worth its price when the two revenue types are pulling bidding in different directions; with one revenue type your mediation partner's own reporting is close enough. Also not for teams without engineering capacity for roughly ten days of SDK and server work inside the engagement window, since none of this can be delivered from the ad accounts alone. How it runs: Four to eight weeks. Week one is a written audit of what your current setup actually measures, which usually differs from what your team believes it measures. Then instrumentation with your engineers, a two-week parallel period where old and new numbers run side by side and we explain every divergence, and finally the handover: the dbt models, the conversion value schema with its boundaries justified, the reconciliation memo, and a runbook for the three things that break most often - a mediation SDK upgrade, an ad unit added without tagging, and an iOS release that changes consent timing.