A weekly metrics review for an indie app business

A useful weekly review ends with a decision. It might be to investigate a broken purchase flow, leave a noisy advertising metric alone, or test a clearer explanation of a paid feature. Opening every dashboard and collecting screenshots is not a decision.

Here is a review routine you can adapt to a small app business. It is a suggested working method, not an industry benchmark.

Start with a question and a complete period

Write one question before opening the reports: “What changed enough to deserve attention this week?” Compare equal-length, completed periods with the same weekdays. Record the actual dates, provider time zones and any missing reports.

If one source is delayed, use a common completed period for the comparison or label its shorter window explicitly. A missing day is unknown, not a day with no revenue.

Keep the current state separate from the period's activity. Active subscriptions are a snapshot; new subscriptions and cancellations are events. Adding daily active counts produces neither unique subscribers nor new subscriptions.

Keep a small review sheet

Use a compact table rather than a long list of disconnected percentages:

Google recommends examining estimated earnings and impressions alongside eCPM when investigating changes. See its eCPM fluctuation guidance. A higher eCPM alone does not establish that the business earned more.

Keep overlapping provider views separate. RevenueCat and store reports may describe the same purchases; Network and Mediation may overlap too. Follow the revenue comparison guide before constructing a combined figure.

Write an observation before a hypothesis

An observation might be: “Advertising earnings fell, impressions were similar, and the reported eCPM was lower.” A hypothesis might be: “A change in country mix contributed.”

Those statements have different levels of certainty. Break the change down by a relevant segment, check recent releases and configuration changes, and look for contradictory evidence. Do not promote a plausible explanation to a proven cause.

Avoid opening every possible segment until one produces an interesting story. Choose a small set relevant to the original question and record what you checked.

Leave with one action

Finish the review with an entry containing:

• The observation and the reporting limitations.
• The first check or experiment.
• The person responsible and the next review date.
• The metric that would support or challenge the hypothesis.

In AppCradle, use Statistics to inspect the available provider reports and Settings → Imports to check reporting progress. Keep the action log in your own notes; this article does not imply that AppCradle stores experiment assignments or proves causality.

For a proposed advertising change, the ad revenue calculator can make assumptions explicit. Its output is an illustrative scenario, not a forecast. The next review should compare those assumptions with what actually happened.