The UK Online Safety Act’s age assurance requirements have moved from “read the guidance” to “expect an audit.” As of February 2026, Ofcom has opened investigations into more than 90 platforms and issued six fines, including an £800,000 penalty against one operator, and enforcement focus for the rest of 2026 is shifting from whether services have age checks in place to whether those checks actually work. For any app or site in scope — not just adult content platforms, since the Act reaches services that host or facilitate access to age-restricted material more broadly — age assurance has gone from a legal checkbox to a live product surface that Ofcom, and your own users, are both watching.
The trouble is that age assurance is usually built and shipped as a compliance feature, not a product feature, so it often ships without the instrumentation a product team would normally insist on. A verification flow that adds friction at exactly the point a new user decides whether to bother is a conversion problem hiding inside a legal requirement, and most teams have no visibility into how much of it is happening. Worse, age assurance vendors vary widely in method — document checks, facial estimation, credit card checks, reusable third-party tokens — and each carries a different false-rejection rate. Without tracking drop-off and rejection by method, a compliance fix that satisfies Ofcom can simultaneously be costing the business new signups, and nobody finds out until growth numbers are already down.
Data Points to Track
- Verification funnel step and exit point, logged at each stage of the age check (method selection, document or facial capture, third-party redirect, result), so drop-off is attributable to a specific step rather than a single blended “verification failed” number
- Verification method used and outcome, since different providers and methods carry very different pass rates, and blending them hides which one is disproportionately rejecting legitimate users
- False-rejection appeals or retries, tracking how many users who fail verification attempt again or contact support, as a proxy for how many genuine users are being wrongly blocked rather than correctly filtered
- Time-to-complete for the verification step, since a check that takes noticeably longer than the rest of onboarding is a strong predictor of abandonment even among users who technically could pass
- Compliance audit trail fields, logged separately from product analytics (verification method, timestamp, provider decision, retention period), because Ofcom’s evidentiary requirements and a product team’s conversion analysis need different data shapes from the same event
Setup Steps
- Instrument the verification flow as its own funnel, distinct from general onboarding, with a named event at every step rather than a single pass/fail flag at the end.
- Tag every verification event with the method and provider used, especially if more than one age-assurance option is offered, so method-level pass rates can be compared rather than assumed equal.
- Separate the compliance log from the analytics log at the point of capture — the compliance record needs to satisfy Ofcom’s retention and evidentiary rules, while the analytics record needs to be queryable for drop-off analysis, and conflating the two schemas early makes both harder to maintain.
- Set an internal false-rejection threshold per verification method, using retry and appeal data as the leading signal, and review it monthly rather than waiting for a support complaint spike to notice a method has degraded.
- Build a before/after comparison for any change to the verification flow — new provider, added method, adjusted UI — comparing completion rate and drop-off point against the prior baseline, since a well-intentioned compliance improvement can just as easily make conversion worse as better.
Actionable Insights
A high exit rate concentrated at the method-selection step, before verification has even started, usually signals the options themselves are the deterrent — worth testing whether a faster or less invasive method first changes completion without weakening compliance. A high exit rate after a specific provider’s redirect, isolated from the rest of the funnel, points at that provider’s flow rather than your product, and is worth raising with them alongside your own data. And a rising retry-and-appeal rate on one method, even without a matching complaint volume, is an early warning its false-rejection rate is drifting — cheap to catch from event data, expensive to discover from an Ofcom enquiry instead.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert