Remove immature installs from a D7 retention denominator

Analysis

By Isaac Turner, Measurement Editor2 min read

View author profile
Remove immature installs from a D7 retention denominator

A seven-day retention rate needs installs that have had seven days to return. A reproducible synthetic example with editable inputs and explicit limits.

A seven-day retention rate needs installs that have had seven days to return. Mixing yesterday’s installs into the denominator can make an unchanged product appear weaker. This lab uses a deliberately small cohort ledger to show how the denominator changes the interpretation.

Define the calculation before using it

Select an observation cutoff and identify the installs old enough to meet the complete D7 definition. Count returners only among those eligible installs. Keep the retention convention explicit: activity on the seventh day is different from activity on or after it. The worksheet accepts aggregate eligible and immature counts after that upstream classification; it does not infer user age from a date label.

Work through the synthetic example

With 200 eligible installs, 50 immature installs and 40 eligible D7 returners, the valid rate is 20%. Dividing by all 250 would display 16%. The four-point gap is created by an observation rule, not by an observed change in player quality. Review eligibility first when a freshly scaled campaign appears to lose retention immediately.

Reference table
OutputWorked-example result
Mature retention %20.0000
Incorrect mixed rate %16.0000

Use the artifact and preserve its assumptions

Open the editable calculator to change the inputs and inspect the sensitivity view. The CSV records synthetic inputs and expected outputs; the JSON fixture keeps the equations available for reproduction. These calculations have been checked against the stated example. No measured campaign data is included.

The sensitivity rows vary only immature by 20% below and above the entered value. They are scenarios, not confidence limits or a forecast distribution. A row outside the model’s constraints is labelled rather than turned into a plausible-looking result. Save the chosen inputs with the decision so another reader can distinguish a changed assumption from a changed formula.

Evidence and limits

Google’s export schema separates the reporting date, UTC timestamp and event parameters. The worksheet uses simplified aggregate inputs; it does not claim that an export already contains a correctly reconciled cohort. See Google Analytics BigQuery Export schema, especially “event_date, event_timestamp, event_value_in_usd and event_params fields”.

The returner count must use the same cohort and day-boundary definition as the eligible denominator. This model cannot repair identity resets, missing events or a different definition of active use.

Background: UA metrics explained: CPI, ROAS, LTV and payback and Reading an MMP dashboard without fooling yourself. These existing articles provide context; the present calculation does not verify every archived claim.

Featured

Related posts

measurement

media buying

·

1 min read

Using predicted LTV in bids: disclosure checklist for the UA team

measurement

media buying

·

1 min read

Blended ROAS targets that hide channel failure in F2P portfolios

measurement

media buying

·

2 min read

Web-shop LTV with VAT-inclusive prices versus store net proceeds (labelled synthetic)

measurement

media buying

·

1 min read

View-through attribution windows on F2P rewarded and interstitial traffic

More from the Measurement desk

measurement

·

2 min read

Airbridge adds Amazon Ads as an app measurement channel

measurement

·

2 min read

When to freeze a cohort for payback review (and when not to)

measurement

·

1 min read

Web-shop purchaser quality vs store IAP purchaser quality

measurement

·

1 min read

Web-shop attributed revenue in MMP vs payment-provider settlements