Troop statistics

A troop's statistics answer the team-level question: how is verification going across everything this troop owns, not just one site key. It is the same dashboard as a single key's statistics, pointed at the whole troop: the same funnel tiles, the same charts, the same time ranges, summed across every site key in the troop. You watch the product as a whole here, then open a single key when something stands out.

Everything is aggregate, the same posture as the rest of Caputchin: counts and timings, never per-visitor data. Pick a time range at the top (Today, Yesterday, 7 days, 28 days, or a custom window) and every tile and chart follows it.

The funnel at a glance

Four headline tiles, read top to bottom as a funnel, summed over every key in the troop:

Sessions started: the widget mounted for a visitor.
Client-completed: the visitor cleared the challenge in their browser.
Server-verified: a backend, or hosted verification, confirmed the token.
Threats blocked: requests the challenge stopped.

Underneath, the same two derived percentages a single key shows, computed troop-wide:

User drop-off = (started minus client-completed) divided by started: visitors who gave up before finishing.
Unverified completions = (client-completed minus server-verified) divided by client-completed: good tokens a backend never checked.

A healthy troop keeps both low and steady. Because these are troop-wide, one misbehaving key can move the troop number without the others changing, which is exactly the signal to drill in.

Volume over time

The volume chart plots started, client-completed, and server-verified across your range for the whole troop. The three lines should rise and fall together; when they fan apart you can see when it began, which ties a troop-wide drop to a specific deploy or campaign on one of the keys.

Failures and threats

A second chart breaks down what the troop's challenges stopped: failed client completions, failed server verifications, rate-limit rejections, and challenge blocks. A spike is the early warning. A jump in challenge blocks across the troop often means a bot wave hit one or more keys; steady rate-limit rejections suggest an attack or a rate limit set too low somewhere.

Timing

The timing chart shows the median (p50), p95, and average across the troop, for the same four spans a single key reports: game-play time, time to complete, time to verify, and total session. Watch the p95: a climbing troop-wide time-to-complete points at a challenge that is too heavy on the slowest devices, while a slow time-to-verify points at a backend, not the widget.

What differs from a single key

The troop view is the rollup, so two per-key tools are not here, by design:

No per-game filter. A single key can narrow the whole page to one game to compare games; the troop cannot, because each key registers its own games. The per-game breakdown lives on each key's own page.
No session log. The per-session list (with its per-session outcomes and game filter) is a per-key tool. Open the specific key to see individual sessions.

So the pattern is: spot the trend troop-wide here, then open the key it points to and use its per-game filter and session log to find the specific cause.

Delivery across the troop

If the troop's site keys use hosted verification, the troop also has a delivery view: webhook and email delivery successes and failures rolled up across every key that has it enabled. It is the troop-wide version of the per-key delivery statistics, so you can confirm submissions are reaching their destinations everywhere at once.

What is not here

No per-visitor data. The rollups are counts and timings; no IPs, fingerprints, or identities.
No cross-troop view. Statistics are scoped to one troop. To compare troops, read each troop's own page.