Attribution Windows for Hybrid-Monetisation Games

By UA Ledger staff — Archive date: 6 min read

Abstract illustration of two overlapping timeline curves converging on a single dashboard axis

Attribution windows for hybrid monetization games often run on two separate timelines. How to reconcile IAP and ad revenue into one dashboard that holds.

Most measurement setups still treat in-app purchase attribution and ad-revenue attribution as two separate problems. They run on two separate windows, and most teams reconcile them by hand or not at all. For a hybrid-monetisation title generating meaningful revenue from both IAP and rewarded or interstitial ads, that split creates a dashboard that looks coherent and is quietly wrong. Getting attribution windows for hybrid-monetisation games onto one timeline is one of the more valuable, least glamorous fixes a measurement lead can make this quarter.

Why the two revenue types drift apart

IAP attribution windows are typically long: seven days, fourteen, sometimes thirty. Purchase behaviour can take time to develop, and a meaningful share of lifetime value arrives well after install. Ad-revenue attribution runs on a much shorter window, often just the session in which an impression served, because ad revenue accrues continuously and a short lookback still counts it accurately.

Run both windows side by side without reconciling them, and a title's blended ROAS curve tells two different stories depending on which day you check it. Early on, ad revenue dominates. It counts immediately, while IAP is still accruing inside its longer window, so by day fourteen or thirty IAP revenue catches up and can overtake the picture the ad-revenue-only view gave a UA team in week one. Anyone making scale-or-cut decisions off a day-three or day-seven blended number, without knowing which revenue type is doing the work, is making that call on an incomplete signal that will look different in three weeks.

Building one attribution window timeline

The fix is not to force both revenue types onto an identical window. That loses information in both directions. It is to build a single reporting timeline that shows both curves against the same day-since-install axis, clearly labelled, so a reviewer can see how each component matures rather than reading one blended number that hides the mix.

A practical structure: report gross revenue per user at day 1, day 3, day 7, day 14, day 30, but split every one of those figures into its IAP and ad-revenue components rather than presenting only the sum. Track the ratio between the two components at each checkpoint as its own metric. A title where ad revenue makes up 70% of day-three revenue and 40% of day-thirty revenue is telling you something specific about how its monetisation matures, and that ratio shift is exactly the kind of signal a blended number erases.

A worked example

Consider a hypothetical hybrid-casual title with a $4.50 day-three blended ROAS target. At day three, the dashboard shows $3.10 from ad revenue and $1.40 from IAP, a mix that looks healthy against the target. By day fourteen, IAP has grown to $5.60 as the longer attribution window catches later purchasers, while ad revenue has grown more modestly to $4.20, for a day-fourteen blended figure of $9.80. A UA manager reading only the day-three number might under-value this cohort's true payback and cut spend on the exact user segment that would have paid back handsomely by week two, simply because the reporting window for one revenue stream matured faster than the other.

Flip the scenario. Now the risk runs the other way: a cohort that looks strong on day-three blended ROAS purely because of an early ad-revenue spike, with IAP that never materialises at scale by day fourteen, can lead a team to scale spend against a cohort that was never going to pay back on the timeline the initial number implied.

Refunds and reversals complicate the picture further

The reconciliation problem gets harder once refunds and chargebacks enter the picture. A platform can reverse IAP revenue long after it was first attributed; ad revenue essentially never reverses. A user who purchases a currency bundle on day two and requests a refund on day nine will show positive IAP revenue in a day-three snapshot and a corrected, lower figure by day fourteen, even though nothing about the underlying ad spend or targeting changed in between. Ad-revenue attribution doesn't carry this problem in the same way, since an impression that served is not later un-served.

A dashboard that doesn't flag which historical figures are still subject to revision, and which have settled, risks a UA manager treating an early, pre-refund IAP number as final when it is not. Mark each checkpoint's IAP figure as provisional until a defined settlement window has passed, typically tied to the platform's own refund policy window. Then re-run the blended ROAS calculation once that window closes, rather than only at the moment of first attribution.

What to check in your own setup

  • Confirm your MMP is reporting IAP and ad-revenue attribution on explicitly labelled, separate windows rather than one combined figure, and that your dashboard preserves that split downstream.
  • Pick the same day-since-install checkpoints for both revenue types so the two curves are genuinely comparable rather than measuring different points in a user's lifecycle.
  • Track the IAP-to-ad-revenue ratio at each checkpoint as a first-class metric, not an afterthought, since a shifting ratio is often the earliest warning that a cohort's monetisation mix is changing.
  • Set scale and cut thresholds using the checkpoint where both revenue types have had time to mature, not the earliest available blended number, even if that means a slower decision.
  • Re-run this reconciliation whenever a monetisation change ships, such as a new ad placement or IAP bundle, since the two windows can drift apart again quickly after any change to the underlying mix.

As we argued in A cohort quality checklist before you scale UA spend, most measurement mistakes come from checking a cohort before it has finished telling its story rather than from a broken tool. Attribution window mismatches are a specific case of that broader habit. None of this requires new tooling. Most MMPs already capture both revenue types on their native windows; the gap is usually in how a team builds its own reporting layer on top, not in what the platform provides. A dashboard that shows one attribution timeline, split by revenue type and checkpoint, gives a UA team the ability to distinguish a cohort that is genuinely underperforming from one that simply has not finished attributing yet.

Related archive reading

These articles provide related context and remain subject to their stated review status.

Featured

Related posts

measurement

media buying

·

2 min read

Murka: an attribution-window change is also a measurement change

measurement

media buying

·

3 min read

MobilityWare: splitting UA and creative still requires a shared acceptance contract

measurement

media buying

·

3 min read

Mamboo Games: define migration acceptance before celebrating a growth change

measurement

media buying

·

3 min read

Magic Tavern: require placement evidence before making CTV a performance channel

More from the Measurement desk

measurement

platforms

·

2 min read

AppLovin Ad Review drops user-level journeys for aggregate-only reporting

measurement

platforms

·

2 min read

Apple adds an EU alternative ATT prompt from iOS 27.2 — mandatory in five markets

measurement

platforms

·

1 min read

When to turn rewarded ads off for payers (and how to measure the loss)

measurement

platforms

·

1 min read

When custom product pages need their own MMP campaign mapping