Statistik und Sessions
Ö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, 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 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. 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, 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 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.
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), 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
- Sicherheit für die Einstellungen, die diese Zahlen formen.