The Metrics Sheet Publishers Ask For, Filled In

A publisher metrics sheet needs five sections: test setup, acquisition, retention, engagement, and monetisation. Every number needs the sample size and the window it was measured over. A small, clearly qualified result is more persuasive than a large number presented without context.

Why this matters

Reviewers compare your numbers against tests they have run themselves. That comparison only works if they can tell what your numbers mean.

An unqualified figure is treated as unreliable, because it usually is. A precise figure with a small sample stated honestly is treated as a real data point.

Producing this sheet consistently also improves your own decisions, since it forces you to state what you actually measured.

Every field publishers request

The full list, grouped.

Test setup

• Build version tested
• Test start and end dates
• Total spend
• Markets, listed individually
• Channel and campaign type
• Creatives used, by name

Acquisition

• Impressions
• Clicks and click-through rate
• Installs
• Cost per install, per market
• Click-to-install rate

Retention

• Day one, per market where volume allows
• Day three and day seven if the test ran long enough
• Cohort size behind each figure

Engagement

• Sessions per user per day
• Average session length
• Levels attempted and completed
• Drop-off point by level

Monetisation, if instrumented

• Ad impressions per user per day
• Revenue per user per day
• Purchase conversion, if any purchases exist

Every row needs two companions: the number of players it is based on, and the window it covers. Without those it is an anecdote.

How each metric should be calculated

The most common disputes are definitional, so state your method.

Two of these cause most confusion. Retention measured on calendar days gives a different number from a rolling twenty-four hour window, sometimes substantially. And a completion rate measured against all installs looks far worse than one measured against players who reached the level.

Neither method is wrong. Presenting one without saying which is.

Sample sizes that make a number credible

Small numbers are fine. Undeclared small numbers are not.

Three practical guides.

1. Report the cohort size beside every retention figure. A day-one figure from a small cohort is directional at best, and reviewers will treat it accordingly if you are honest about it.
2. Do not report a metric at all if the sample is tiny. Write "insufficient volume" rather than a number that will be dismissed and damage the credibility of the rest.
3. Split by market before drawing conclusions. A blended figure across markets with different costs is close to meaningless, for the reasons in Why Your CPI Went Up After the Test Ended.

Presenting bad numbers honestly

Weak results are normal and how you present them matters more than the results themselves.

Three rules.

Lead with the number. Burying a poor result under context reads as concealment, and reviewers find it anyway.

Give one hypothesis, not three. "Day one is low and we believe the first level is too difficult, based on the drop-off at level two" is credible. A list of possible explanations reads as guessing.

State what you would change. A submission showing weak numbers plus a specific planned change is far more interesting than one showing weak numbers alone. It demonstrates that you can read your own data.

Never adjust the window until a number improves. Reviewers recognise it immediately, and it costs more credibility than the original figure ever would.

The filled-in example and the blank template

Structure the sheet as one page with the five sections in order, each row carrying its value, its sample size, and its window.

A worked example row for retention might read: day one retention, per cent value, cohort of a stated number of installs, measured on a rolling twenty-four hour window, single named market, build version stated.

Two additions that make the sheet more useful than most.

• A one-line summary at the top. What you tested, what you found, what you would do next. Many reviewers read only this.
• A notes column. Anything unusual: a market added mid-test, a creative swapped, a day of broken tracking. Volunteering these is what makes the rest believable.

Keep the blank version in your repository beside the prototype template, so it is filled in as the test runs rather than reconstructed afterwards.

What we would do

Fill the sheet during the test rather than at the end. Reconstructed numbers are where errors and rounding creep in, and where the notes column gets forgotten.

Write the definitions once and reuse them across every test. Consistency across your own tests is worth more than matching anyone else's method, because it makes your results comparable to each other.

Then send the sheet with the build every time, including when the results are poor. A studio that reports honestly on a failed test is much easier to work with than one that only submits winners, and publishers notice.

The short version

• Five sections: test setup, acquisition, retention, engagement, monetisation.
• Every number needs a sample size and a measurement window beside it.
• State your definitions, especially for retention windows and completion rates.
• Write "insufficient volume" rather than reporting a number the sample cannot support.
• Split by market before concluding anything.
• Lead with weak numbers, give one hypothesis, and state the change you would make.

Build the blank sheet now and fill it during your next test rather than after. If you want a read on a metrics sheet before it goes to a publisher, send it over.

Related reading: The Publisher Submission Checklist, Game Analytics to Track From Day One, and A Game Test Report Template.