The D7 ROAS Kill Line: How to Decide a Creative's Fate in One Week
Anna Danyi
8 August 20269 min read
Every creative test ends in the same meeting. Someone likes the ad. Someone points at a cheap CPI. Someone else mutters about "letting it exit learning". And a creative that will never pay back gets another two weeks of budget because nobody in the room agreed — before the test started — what number would kill it.
The fix is a kill line: a D7 revenue ROAS threshold, derived from your payback maths, that a creative must clear or die. Not a vibe, not an industry average — a number computed backwards from the month your CFO needs the spend to be whole. This post is the Exp(G) operator manual: definition, why the checkpoint is day seven, the three-step derivation, a worked example, the weekly ritual, failure modes, and how the line plugs into a real growth system.
What a D7 ROAS kill line actually is
Day-N ROAS is cohort revenue in the first N days divided by the ad spend that acquired that cohort. A D7 ROAS kill line is the minimum D7 revenue ROAS a creative (or concept cluster) must hit for the underlying unit economics to still clear your payback target at scale. Clear the line and you have evidence the creative selects users who pay on a trajectory your model can live with. Miss it and you stop — not because the ad "looks tired", but because the maths says it cannot become whole in time.
Two definition choices matter before you compute anything. First, prefer net contribution (revenue after store fees and refunds) over vanity gross platform ROAS. Apple's Small Business Program and Google's Play service fees are not optional footnotes; ignoring them invents survivors. Second, prefer MMP or internal cohort revenue over self-reported auction dashboards. AppsFlyer's ROAS glossary and Adjust cohort analysis exist so "ROAS" is not whatever the platform flatters you with after modelled conversions. Write the definition in one sentence and refuse cross-definition comparisons.
Why gut-feel creative calls are so expensive
A creative that runs two weeks past its true kill point does not just waste its own spend. It occupies a test slot another concept could have used, it feeds the algorithm signals from users who will never pay, and it delays the compounding that comes from reallocating budget into winners early. Across a year, teams that decide in seven days simply run more experiments per quarter than teams that decide in thirty — the engine described in our 60-day creative testing framework runs on exactly this discipline.
There is also an emotional cost. Without a pre-committed number, every kill becomes a political act: the designer who made the ad, the UA lead who liked the CTR, the founder who "has a feeling". Pre-committing the kill line turns killing into maintenance. In Exp(G) operating experience across the accounts we run, that cultural shift is often worth more than the spreadsheet itself — because the spreadsheet only works if people actually stop the losers. Creative fatigue makes the politics worse: a decaying winner looks "almost fine" on blended charts while it quietly fails the line.
Why D7 is the checkpoint (and when it is not)
Day seven is usually the earliest point where revenue data stops lying enough to act. D1 ROAS is noisy — dominated by whales, refunds not yet visible, trial conversions not yet through. D30 is accurate but slow: waiting a month to kill a creative means burning four weeks of budget for information you could often have had in one. For many subscription and hybrid-monetisation apps, the ratio between D7 revenue per user and longer-horizon revenue per user is stable enough that a D7 reading predicts the destination even though most of the cash has not arrived yet.
When D7 is the wrong primary checkpoint: annual-plan products that collect almost all cash on day zero or day three (judge earlier, on trial-start or purchase ROAS); mid-core games where whale spend arrives late (lean on D14/D30 with a smaller early screen); and ultra-low volume tests where one whale decides the cohort (raise sample size before you raise the window). The principle is unchanged: pick the earliest mature-enough signal that maps to your payback model, then freeze it. Public category tables from Business of Apps benchmarks can sanity-check whether your D7/D30 relationship looks weird for the vertical — they still do not set your line.
Deriving your kill line in three steps
- 01
Step one: fix the payback target
Decide the month by which a cohort's contribution must cover its acquisition cost — month 6 is typical for funded consumer apps, month 12 for cash-rich or high-LTV products. This is a finance decision, not a marketing one. Our payback period guide walks through choosing it without theatre.
- 02
Step two: find the CPI that hits it
Run unit economics backwards from that target to the maximum CPI you can afford on your real revenue curve. The Payback Engine does this in Solve backwards mode: give it a payback month and it returns the break-even CPI on your assumptions.
- 03
Step three: translate CPI into D7 ROAS
Divide your cohort's typical D7 revenue per user by that maximum CPI. That percentage is the kill line. If your model says you can pay at most $3.20 per install and your cohorts typically show $0.35 of revenue per user by day seven, your kill line is roughly 11% D7 revenue ROAS.
The number must exist before the creative launches. The meeting stops being a debate and becomes a reading. If you want a sanity check on whether that line sits in a sane category band, compare it to the ranges in what is a good ROAS for mobile apps and the interactive benchmarks tool — as context, never as a substitute for your own maths.
Worked example: from payback month to Tuesday's kill
Take a consumer subscription app targeting month-6 payback. After store fees and refunds, historical cohorts show roughly $0.40 of net revenue per install by D7, and the Payback Engine says the CPI ceiling for month-6 payback is $3.50. Kill line = 0.40 / 3.50 ≈ 11.4% D7 net ROAS. You launch three concepts with equal test budget. Concept A lands at 16% — scale. Concept B lands at 10% — iterate the hook (not the whole idea) using the hook analyzer before you spend another cycle. Concept C lands at 6% — kill without a meeting. Same spend envelope, three different decisions, zero theatre.
Notice what we did not do: we did not ask whether 11% is "good" versus a Sensor Tower category average, and we did not wait for the ad platform's learning phase to "finish". SKAdNetwork and modelled conversions will still distort the platform number — which is why the kill line should be read on MMP/internal data, with a quarterly calibration against channel dashboards so the gap is known rather than surprising. Project alternate CPI and revenue assumptions in the ROAS calculator before you argue about moving the line.
Running the weekly ritual
- 01
Fuel every new creative enough to clear noise
— enough installs per concept that D7 revenue is not decided by one whale, before you read anything.
- 02
Read at day seven, act at day seven
Above the line: scale. Within striking distance (in Exp(G) operating experience we use roughly 80–100% of the line): iterate the hook or the offer, not the whole concept.
- 03
Below 80% of the line: kill without discussion
The whole value of the system is that this step requires no meeting.
- 04
Log every reading
Ten weeks of kill-line data tells you which concepts, hooks and formats systematically clear the bar — that is your creative strategy, written by your own economics.
- 05
Recompute the line when the model moves
New pricing, new trial length, or a changed payback target means a new kill line. Stale lines are how teams accidentally scale losers after a monetisation change.
- 06
Separate test budget from scale budget
Winners earn scale; tests do not get infinite runway because someone liked the edit.
The ritual only works if production keeps up. A kill line with an empty creative pipeline becomes a reason to keep losers alive. Build the replacement queue first — variants and new concepts — then enforce the line. That is also why we treat creative ops as a unit-economics function, not a brand side-quest.
Failure modes that silently wreck the system
First, using platform-reported ROAS unedited. SKAdNetwork windows and modelled conversions distort early revenue differently by channel; calibrate against MMP or internal data, or your kill line silently drifts. Second, setting the line from benchmarks instead of your own maths. A "good" D7 ROAS from a benchmark table is a sanity check, not a target. Third, raising the line because a creative is "almost there". The almost-there creative is how budgets die politely. Fourth, judging at the campaign blend. Blends hide losers under winners; read per creative or per concept cluster. Fifth, under-fuelling the test so every D7 number is noise — then declaring the method broken when the real issue was sample size. Sixth, forgetting fees: celebrating a gross kill-line hit that fails after Apple or Google take their cut.
A subtler failure mode: changing the optimisation event mid-test (installs → trial start → purchase) and pretending the D7 ROAS series is still comparable. If the event changes, restart the experiment clock and restate the line in the new event's revenue language.
From kill line to growth engine
A kill line is not a reporting trick. It is the connective tissue between finance and creative production: payback sets the CPI ceiling, the ceiling sets the D7 line, the line decides which ads live, and surviving ads are the only ones allowed to eat scale budget. Pair it with a real production cadence so you always have something ready to replace the dead — otherwise teams "cannot kill" because they have nothing else to run. That loop is what we install inside engagements: model, line, weekly ritual, creative pipeline.
If your team still decides creative fate by committee, recompute the line in the Payback Engine, then book a discovery call. We will derive your kill line on the spot and tell you honestly whether your current winners would still be alive under it.
Sources & further reading
Anna Danyi
Founder at Exp(G) — building and scaling mobile apps with AI-powered growth systems. About the team