Proxy-Gate-Statistik
Das Gate führt seine eigene Statistik, getrennt von der Verifizierungsstatistik eines Site-Keys. Die Verifizierungsseite beantwortet "kommen echte Menschen durch das Spiel?"; diese Seite beantwortet eine engere Frage: "wie oft fordert das Gate Besucher heraus, statt einen freigegebenen Besucher durchzulassen?" Sie ist, wie du bestätigst, dass das Gate verdrahtet und getunt ist, und sie ist dieselbe Fläche, auf die der Vorschaumodus schreibt, während du noch testest.
Wo sie lebt
Es gibt zwei Ansichten:
- Pro Site-Key: die Seite Proxy-Statistik unter einem Site-Key, für einen abgesicherten Origin.
- Pro Team: die Seite Proxy-Statistik auf Team-Ebene, aggregiert über jeden Site-Key im Team.
Beide brauchen den Alpha-Plan oder höher; darunter zeigt die Seite stattdessen eine Upgrade-Karte.
Die vier Zählwerte
Jede Gate-Entscheidung wird als eine von vier Arten festgehalten:
- Durchgang: eine Anfrage kam mit einem gültigen Pass an und wurde erlaubt. Das ist die Gewinnbedingung; ein freigegebener Besucher, der die Site durchstöbert, erzeugt diese.
- Challenge gezeigt: eine Anfrage hatte keinen gültigen Pass, also wurde der Besucher zum Spiel geschickt.
- Pass ausgestellt: ein Besucher hat das Spiel gelöst und ein Pass wurde geprägt (der Callback setzte dann das Cookie).
- Abgewiesen: der Autorisierer hat die Anfrage unter einer Fail-closed-Richtlinie abgelehnt, während er keinen Pass bestätigen konnte.
Das Verhältnis von Durchgang zu Challenge
Die Schlagzeilen-Zahl ist Durchgang relativ zu Challenges. Sobald Besucher das Gate freigeben, sollten die meisten ihrer Anfragen Durchgang sein, mit einer Challenge nur am Anfang eines Besuchs oder nachdem ein Pass abläuft. Ein hohes Durchgangs-Verhältnis heißt, deine Freigabe-TTL tut ihren Job, ein Lösen kauft viele Anfragen. Bleiben Challenges hoch relativ zum Durchgang, ist die TTL vielleicht zu kurz (Besucher mitten in der Session erneut herausgefordert) oder das Cookie wird nicht gesetzt (prüf den Callback).
Sie während des Rollouts lesen
Solange der Vorschaumodus an ist, achte auf die Abfolge in einem einzelnen Testbesuch: ein challenge_served (noch kein Cookie), dann ein pass_issued, nachdem du löst, dann passthrough, das klettert, während du neu lädst. Fehlende Challenges heißen, der Autorisierer-Block wird nicht getroffen; ein pass_issued, das nie zu Durchgang wird, heißt, das Cookie hält nicht.
Aufbewahrung
Die Historie wird nach Plan-Stufe aufbewahrt und ältere Buckets werden nach einem täglichen Zeitplan beschnitten, sodass sich das Fenster, über das du zurückblicken kannst, mit deinem Plan weitet. Das Live-Verhältnis und die jüngste Aktivität sind immer verfügbar.
Was hier nicht ist
- Keine Fail-open-Durchgänge von deinem Proxy. Ist dein Proxy fail-open konfiguriert und Caputchin nicht erreichbar, lässt der Proxy die Anfrage von sich aus durch; Caputchin sieht sie nie, also kann sie hier nicht gezählt werden.
- Keine Daten pro Besucher. Nur Zählwerte, keine IP, kein User-Agent, keine Anfrage-Inhalte, im Einklang mit Caputchins Datenschutzhaltung.
Siehe auch
- Überblick: was das Gate ist und das Freigabe-Cookie.
- Das Proxy-Gate einrichten: der Vorschaumodus schreibt auf diese Fläche, bevor du live gehst.
- Statistik der gehosteten Verifizierung: die entsprechende Fläche für die Option ohne Backend.