Age signals travelling across your whole SDK stack

Age-based obligations have expanded across markets and the technical requirement they create is consistent: certain things must not happen for players below certain ages.

Establishing the age signal is the part that gets planned. Making sure it reaches every component that could act on it is the part that gets discovered later.

Where the signal has to arrive

A typical game has several components capable of doing something age-relevant. Advertising, analytics, purchasing, any social or communication feature, anything that personalises.

Each of these makes decisions independently. Each needs to know. And each has its own way of being told, if it has one at all.

The common failure is that the age signal reaches the two or three components that were in the game when the requirement was implemented, and does not reach the ones added afterward. Nothing errors — a component that was never told simply behaves as it would for an adult, which is its default.

The second failure is components that have no way to be told. Not every third-party piece exposes a way to set a restricted mode, and discovering that at integration time is much better than discovering it during a compliance review.

The signal is not one thing

Part of the difficulty is that "age" resolves into several different signals with different obligations, and they are not interchangeable.

Whether the player is below the age of digital consent in their market — which varies by market — governs data processing.

Whether they are below the threshold for certain purchases or content governs commerce and what they can see.

Whether the market treats them as a child for advertising purposes governs what advertising components may do, and that threshold is frequently different from the other two.

A single boolean cannot express these, and a stack built on one will be wrong somewhere. What each component needs is the specific determination relevant to it, derived from the underlying age and market.

Verifying propagation

The check that finds gaps is to test behaviour rather than configuration.

Set the age signal to a restricted value and observe what each component actually does. Not what it is configured to do — what it does. Components that continue behaving normally are components that did not receive the signal or ignored it.

This is worth doing as a repeatable test rather than a one-off, because the failure mode is regression: a new component added six months later, integrated correctly for its own purposes, wired to nothing that tells it about age.

The related check is what happens when the signal arrives late. If age is determined after startup — from a login, or a prompt — anything that initialised before then started in an unrestricted state. Whether that matters depends on what it did in the interval, and the interval is usually longer than people assume.

See how player attributes flow through the stack →

Defaulting in the right direction

The design decision that prevents most incidents is what happens when age is unknown.

Defaulting to unrestricted means every gap in the signal path produces a compliance exposure, and gaps are the normal state during integration and after any change.

Defaulting to restricted until a determination is made means gaps produce a slightly degraded experience for some players until the signal arrives. That is a much better failure to have.

The objection is that restricted-by-default costs revenue and engagement during the unknown window. That is true and the window should be short. But the trade is between a small amount of degraded experience and an obligation breach, and those are not comparable in cost.

The same principle applies to markets. If the market is not yet determined, applying the most restrictive rule among plausible markets until it is known is the safe direction, and the window is typically seconds.

The general pattern is that age and market are attributes that many things depend on, and dependencies that are established at startup and never revisited are the ones that quietly fall out of step. Reading them at the point of decision, and defaulting conservatively when they are absent, removes most of the ways this goes wrong.

This is general commentary rather than legal advice; the specific thresholds and obligations vary by market and are worth confirming with counsel.

One thing worth documenting explicitly is which component is the authority. In most stacks the age determination is made in one place and consumed in several, and when they disagree — because one cached an older value, or because a re-prompt updated one path and not another — there needs to be a stated answer about which wins. Teams that have not named an authority discover during an audit that two components hold different values for the same player, and nobody can say which was correct at the time a given decision was made.

Talk to us about compliance-aware architecture →