Why is time in app the riskiest success metric for a children's product?

What is wrong with measuring a child's product by time in app?

Time a child spends inside an app, daily active users, and the length of a consecutive-day streak: three common metrics for measuring any digital product's success, and all three can work against a child's interest instead of serving it. These metrics were originally designed for products whose revenue model lives on continuous attention, where every extra minute inside the app is direct commercial value. When the same metric is carried over to a child's product with no question asked, the design goal quietly shifts from helping the child achieve something to keeping them inside the app as long as possible, and those are two different goals that can conflict in the very same decision.

We hold, in everything we build, that a child's experience is never measured by their inability to stop, an extension of what we state plainly in our own safety stance: we use no addictive techniques such as daily streaks or random rewards, because they build a motive to return, not a motive to learn.

Where do these metrics come from, and what are they actually good for?

These metrics are not wrong in every context; they are correct in an entirely different one. An advertising platform genuinely sells user attention, and session length there is an honest indicator of the product's value to its business owner. A product serving a child has a different purpose: a skill gained, knowledge understood, a behaviour changed, or time spent better with a parent. When a child's product borrows its success metric from an advertising product with no adjustment, it borrows the entire design goal along with it, without anyone on the team intending to.

The evidence level here is Dawani's own internal practice, not a published comparative study measuring each metric type's effect on children specifically, and we state that plainly so the difference between what we observe and what we prove stays clear to any reader.

What happens when we apply an adult-designed metric to a child's product?

First, every design decision tilts toward extending the session rather than ending it well: autoplay for the next piece of content, notifications luring the child back at an unsuitable time, a screen that makes the exit button harder to find, intentionally or not. Second, the product team starts celebrating a rising number nobody can tell is a sign of health or a sign of harm: a high session length might mean a beloved product, and might mean a child who cannot stop, and the number alone does not distinguish between the two.

Third, any harm caused by this design stays unwatched, because nobody set a metric to name it. A team measuring only session length and daily return will never see that a child has started hiding their usage time from their parents, because that behaviour shows up in neither metric.

What metrics replace time in app?

We replace the time metric with a set of metrics describing what actually changed in the child. A completion metric: did the child finish what they started, a task, a story, a level, instead of being measured only by how long they stayed. A transfer metric: did the child use what they learned outside the app, in a conversation with a friend or a real situation at home. A voluntary-stopping metric: did they end the session themselves feeling complete, or stop only because they had to, upset about it. A parent-child interaction metric: did the session produce a conversation or shared activity between them afterward. A recall metric: does the child remember what they did a day or a week later, not only in the moment of use. Indirect behaviour metrics observed from a distance, such as a child asking to repeat an activity they learned from the app during their own free play. And finally, a mandatory guardrail metric every time: a specific harm that must stay close to zero, such as a child feeling anxious if the app is not opened at its usual time.

What does a good pattern and an anti-pattern look like for this swap?

An illustrative anti-pattern: a reading app measures its success by daily minutes, so it adds a cheerful sound after every page to push the child toward opening another one, regardless of how well they actually understood what they read. The wanted number rises, and nobody knows if the child is reading with understanding or just sliding through pages.

An illustrative good pattern for the same app: it measures success by the child's ability to retell the story in their own words after closing the app, and by how often they asked a parent to read them the same book aloud again. This number is harder to measure automatically, and incomparably more honest about what the child actually learned.

How do you use the KPI Translator on your current metric?

The KPI Translator asks for the children's age, your product's kind, the vanity metric you currently use to measure success, and the goal the product was originally designed for. It then suggests two alternative outcome metrics describing what actually changed in the child, a mandatory guardrail metric watching the harm your current metric hides, and a way to keep your old metric as a supporting operational metric rather than the sole measure of success.

Use it in your next product review meeting, and ask one question about every number on the dashboard: if this number goes up further, does the child benefit, or only the product?

What does this swap not guarantee?

Swapping the metric does not by itself guarantee the product has become better for the child. Completion, transfer and recall metrics need good design to measure honestly, not just a new label on the dashboard. These metrics describe what happened during use, not proof of a long-term effect, exactly as we explain in our distinction between proximal and distal indicators when measuring any program's impact. Reviewing these metrics is part of a wider review we run against the Dawani Child-Safe Design framework, where measurement without addiction sits as its own axis examined alongside others such as data and content, not on its own in isolation. The full policy behind this commitment is detailed on our safety page.

Where should you start?

Open your product's current dashboard, pick the number the team celebrates most, and ask it this piece's question: what does it actually measure? If you are not sure of the answer, try the KPI Translator, and read also how we translate safety principles into concrete design decisions. You can also tell us about your current metrics through the Start a project form.

References

• Our safety stance, and the detail of its second commitment (no daily streaks, no random rewards): our safety page, an internal Dawani publication.
• The Dawani Child-Safe Design framework: an independent internal Dawani framework, not a government standard.

Quick questions

Does this mean time in app is a number to ignore completely?

No. It stays a useful operational number for understanding usage, but it stops being the sole or primary success metric. The difference between an operational metric and a success metric is what decides which choice gets made.

Do these alternative metrics apply to every kind of product?

The general idea applies to any children's product, but the specific metric differs by product type, the children's age, and the goal the product was designed for, which is exactly what the KPI Translator suggests case by case.

Who decides the right guardrail metric for a given product?

The product team, with input from someone who understands the risks of the target age group. The guiding question is simple: what is the worst thing that could happen to a child if this metric succeeded in the wrong way?