--- type: explanation title: Statistik und Sessions summary: Wie du den Verifizierungs-Funnel, das Volumen und das Timing eines Keys liest, was dir jedes Diagramm sagt und was du dagegen tust. --- Öffne einen Site-Key, um auf seiner Statistik zu landen. Alles hier ist aggregiert, nie Daten pro Besucher, und es existiert, um zwei Fragen zu beantworten: kommen echte Menschen durch, und wo fallen sie raus? Wähl oben einen Zeitraum: **Heute**, **Gestern**, **7 Tage**, **28 Tage** oder ein **benutzerdefiniertes** Fenster. Jede Kachel und jedes Diagramm unten folgt dem gewählten Zeitraum, und du kannst die ganze Ansicht auf ein einzelnes Spiel verengen, um eins gegen ein anderes zu vergleichen. ## Der Funnel auf einen Blick Vier Schlagzeilen-Kacheln, von oben nach unten als Funnel gelesen: - **Sessions gestartet**: das Widget wurde für einen Besucher gemountet. - **Im Browser bestanden**: der Besucher hat die Aufgabe in seinem Browser gelöst. - **Serverseitig verifiziert**: dein Backend, oder [gehostete Verifizierung](/docs/hosted-verification/overview), hat das Token bestätigt. - **Bedrohungen blockiert**: Anfragen, die die Aufgabe gestoppt hat. Darunter benennen zwei abgeleitete Prozentsätze die Lecks direkt, sodass du die Subtraktion nicht selbst machen musst: - **Besucher-Abbruch** = (gestartet minus im Browser bestanden) geteilt durch gestartet. Der Anteil der Besucher, die vor dem Abschluss aufgaben. - **Unverifizierte Abschlüsse** = (im Browser bestanden minus serverseitig verifiziert) geteilt durch im Browser bestanden. Der Anteil guter Tokens, die dein Backend nie geprüft hat. Ein gesunder Key hält beide Prozentsätze niedrig und stabil. ## Volumen über die Zeit Das Volumen-Diagramm plottet **gestartet**, **im Browser bestanden** und **serverseitig verifiziert** über deinen Zeitraum. Die drei Linien sollten zusammen steigen und fallen. Spreizen sie sich auf, ist die Lücke zwischen zwei Linien dieselbe Diagnose wie die Kacheln, aber jetzt siehst du, *wann* sie begann, und so verknüpfst du einen plötzlichen Einbruch mit einem bestimmten Deploy oder einer Kampagne. ## Fehlschläge und Bedrohungen Ein zweites Diagramm schlüsselt auf, was die Aufgabe tatsächlich gestoppt hat: **fehlgeschlagene Client-Abschlüsse**, **fehlgeschlagene Server-Verifizierungen**, **Rate-Limit-Ablehnungen** und **Challenge-Blockierungen**. Jedes ist eine andere Art Ärger. Ein plötzlicher Anstieg ist deine Frühwarnung: ein Sprung bei den Challenge-Blockierungen heißt oft, dass eine Bot-Welle eintraf und abgewiesen wurde, während stetige Rate-Limit-Ablehnungen entweder auf einen Angriff oder ein für deinen echten Traffic zu niedrig gesetztes [Rate-Limit](/docs/site-keys/security) hindeuten. ## Timing Das Timing-Diagramm zeigt, wie lange Besucher brauchen, als **Median (p50)**, **p95** und **Durchschnitt**, für vier Spannen: - **Spielzeit**: wie lange der Besucher im Spiel selbst verbringt. - **Zeit bis Abschluss**: vom Mounten des Widgets bis zum Lösen der Aufgabe. - **Zeit bis Verifizierung**: vom Abschluss bis dein Server das Token bestätigt. - **Gesamte Session**: das Ganze, von Anfang bis Ende. Beobachte den **p95** statt des Durchschnitts. Eine Handvoll sehr langsamer Besucher verschwindet in einem Durchschnitt, taucht aber bei p95 klar auf, und sie sind die, die aufgeben. Klettert **Zeit bis Abschluss** bei p95, ist die Aufgabe für die langsamsten Geräte zu schwer, also lockere die [Schwierigkeit](/docs/site-keys/security). Ist **Zeit bis Verifizierung** der langsame Teil, liegt die Verzögerung an deinem eigenen Backend, nicht am Widget. ## Effektiv genutzt Lies die Seite als schnellen Gesundheitscheck, dann bohr nur dort tiefer, wo etwas nicht stimmt: - **Volumen-Linien laufen zusammen, beide Prozentsätze niedrig, p95-Timings komfortabel** heißt, es funktioniert. Lass es in Ruhe. - **Steigender Abbruch** ist Reibung. Senk die [Schwierigkeit](/docs/site-keys/security), bestätige, dass das Spiel schnell lädt, und prüf, dass es auf einem Smartphone und mit Tastatur funktioniert. - **Steigende unverifizierte Abschlüsse** heißt, Tokens werden verdient, aber nicht geprüft, also ist das Formular nicht wirklich geschützt. Schau dir [auf deinem Backend verifizieren](/docs/integration-guides/verify-on-your-backend) noch einmal an. - **Bedrohungen oder Fehlschläge im Anstieg** sind meist ein Angriff, der gehandhabt wird, oder ein zu eng gesetzter Filter. Bestätige, dass echte Besucher nicht erwischt werden, bevor du irgendetwas lockerst. Auf ein Spiel zu filtern macht aus der Seite einen Vergleich: ein Spiel mit merklich schlechterem Abbruch oder längerem p95 ist ein Kandidat, ihn aus deiner Rotation zu nehmen. ## Das Session-Log In bezahlten Tarifen listet das Session-Log einzelne Verifizierungs-Sessions. Greif dazu, *nachdem* die Diagramme dir sagen, dass etwas nicht stimmt, und du die konkreten Fälle sehen willst. Jede Session trägt ein Ergebnis, auf das du filtern kannst: | Ergebnis | Bedeutung | |---|---| | Verifiziert | das Token wurde serverseitig bestätigt | | Verifizierung abgelehnt | die Server-Prüfung lief, schlug aber fehl | | Einlösung abgelehnt | die Browser-Aufgabe wurde nicht abgeschlossen | | Ausstehend | gestartet, noch nicht aufgelöst | | Abgelaufen | das Token lief ab, bevor es genutzt wurde | Du kannst das Log auch nach Spiel filtern. Sessions, die durch den [Vorschaumodus](/docs/site-keys/preview-mode) gingen, tragen eine **Vorschau**-Markierung, sodass sich Test-Traffic leicht von echten Durchgängen unterscheiden lässt. ## Was Caputchin nicht erfasst Diese Zahlen sind bewusst dünn beim Besucher. Caputchin ist gebaut, um keine Daten pro Person zu sammeln, und sowohl die Statistik als auch das Session-Log spiegeln das wider. Sie enthalten nie: - **Die IP-Adresse des Besuchers.** Sie wird an der Plattformgrenze entfernt, bevor eine Anfrage die Verifizierung erreicht (siehe [erforderliche Header](/docs/site-keys/security)), also gibt es nichts aufzuzeichnen. - **Den User-Agent des Besuchers oder irgendeinen Geräte- oder Browser-Fingerabdruck.** An derselben Grenze entfernt. - **Irgendeinen Namen, eine E-Mail oder Identität** des Besuchers. Caputchin weiß nicht, wer er ist. - **Kein Tracking-Cookie** beim Besucher und kein Profil, das ihm von einer Seite zur nächsten folgt. Ein Session-Eintrag hält nur die Verifizierung selbst: ihr Timing, welches Spiel lief, und das Ergebnis (plus, wo ein Spiel ein Scoreboard bietet, das kurze Handle und die Punktzahl, die der Besucher eingeben wollte). Die Statistik sind aggregierte Zähler und Timings, gebaut aus diesen Einträgen, nie eine Historie pro Besucher. ## Siehe auch - [Auf deinem Backend verifizieren](/docs/integration-guides/verify-on-your-backend) - [Sicherheit](/docs/site-keys/security) für die Einstellungen, die diese Zahlen formen.