Statistics and sessions

Open a site key to land on its statistics. Everything here is aggregate, never per-visitor data, and it exists to answer two questions: are real people getting through, and where are they falling out?

Pick a time range at the top: Today, Yesterday, 7 days, 28 days, or a custom window. Every tile and chart below follows the range you choose, and you can narrow the whole view to a single game to compare one against another.

The funnel at a glance

Four headline tiles, read top to bottom as a funnel:

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

Underneath, two derived percentages name the leaks directly so you do not have to do the subtraction yourself:

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

A healthy key keeps both percentages low and steady.

Volume over time

The volume chart plots started, client-completed, and server-verified across your range. The three lines should rise and fall together. When they fan apart, the gap between two lines is the same diagnosis as the tiles, but now you can see when it started, which is how you tie a sudden drop to a specific deploy or campaign.

Failures and threats

A second chart breaks down what the challenge actually stopped: failed client completions, failed server verifications, rate-limit rejections, and challenge blocks. Each is a different kind of trouble. A sudden spike is your early warning: a jump in challenge blocks often means a bot wave hit and was turned away, while steady rate-limit rejections suggest either an attack or a rate limit set too low for your real traffic.

Timing

The timing chart shows how long visitors take, as the median (p50), the p95, and the average, for four spans:

Game-play time: how long the visitor spends in the game itself.
Time to complete: from the widget mounting to the challenge being cleared.
Time to verify: from completion to your server confirming the token.
Total session: the whole thing, end to end.

Watch the p95 rather than the average. A handful of very slow visitors disappear into an average but show up clearly at p95, and they are the ones giving up. If time to complete at p95 is climbing, the challenge is too heavy for the slowest devices, so ease Difficulty. If time to verify is the slow part, the lag is on your own backend, not the widget.

Using it effectively

Read the page as a quick health check, then drill in only where something is off:

Volume lines tracking together, both percentages low, p95 timings comfortable means it is working. Leave it alone.
Drop-off climbing is friction. Lower Difficulty, confirm the game loads fast, and check it works on a phone and with a keyboard.
Unverified completions climbing means tokens are earned but not checked, so the form is not actually protected. Revisit verify on your backend.
Threats or failures spiking is usually an attack being handled, or a filter set too tight. Confirm real visitors are not caught before you loosen anything.

Filtering to one game turns the page into a comparison: a game with noticeably worse drop-off or a longer p95 is a candidate to drop from your rotation.

The session log

On paid plans, the session log lists individual verification sessions. Reach for it after the charts tell you something is wrong and you want to see the specific cases. Each session carries an outcome you can filter on:

Outcome	Meaning
Verified	the token was confirmed server-side
Verify rejected	the server check ran but failed
Redeem rejected	the browser challenge did not complete
Pending	started, not yet resolved
Expired	the token timed out before it was used

You can also filter the log by game.

What Caputchin does not collect

These numbers are deliberately thin on the visitor. Caputchin is built not to gather per-person data, and both the statistics and the session log reflect that. They never include:

The visitor's IP address. It is stripped at the platform boundary before a request reaches verification (see required headers), so there is nothing to record.
The visitor's User-Agent, or any device or browser fingerprint. Stripped at the same boundary.
Any name, email, or identity for the visitor. Caputchin does not know who they are.
No tracking cookie on the visitor, and no profile that follows them from one site to the next.

A session record holds only the verification itself: its timing, which game ran, and the outcome (plus, where a game offers a scoreboard, the short handle and score the visitor chose to enter). The statistics are aggregate counts and timings built from those records, never a per-visitor history.