Proxy-Seiten-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.
- Aufgabe gezeigt: eine Anfrage hatte keinen gültigen Pass, also wurde der Besucher zur Verifizierung geschickt.
- Pass ausgestellt: ein Besucher hat die Verifizierung bestanden und ein Pass wurde geprägt (der Callback setzte dann das Cookie).
- Abgewiesen: eine Anfrage kam mit einem Pass an, der nicht gültig war: abgelaufen, manipuliert, oder für einen anderen Site-Key ausgestellt. Ein erster Besuch ganz ohne Cookie zählt hier nicht; der taucht als Aufgabe auf.
Das Verhältnis von Durchgang zu Aufgabe
Die Schlagzeilen-Zahl ist Durchgang relativ zu Aufgaben. Sobald Besucher das Gate freigeben, sollten die meisten ihrer Anfragen Durchgang sein, mit einer Aufgabe 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 Aufgaben hoch relativ zum Durchgang, ist die TTL vielleicht zu kurz (Besucher bekommen mitten in der Session erneut eine Aufgabe) 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 die Verifizierung bestehst, dann passthrough, das klettert, während du neu lädst. Fehlende Aufgaben heißen, der Autorisierer-Block wird nicht getroffen; ein pass_issued, das nie zu Durchgang wird, heißt, das Cookie hält nicht.
Die Zählwerte sind nah dran, nicht exakt
Gate-Ergebnisse werden gebündelt, bevor sie geschrieben werden, also kann ein Zähler ein paar Ereignisse verlieren, wenn der Edge mitten in einer Sekunde recycelt. Verhältnisse und Trends sind verlässlich; behandle einen einzelnen Zählwert als sehr nah dran statt als exakt, besonders auf einer ruhigen Site.
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-Modus-Durchgänge oder -Blockierungen von deinem Proxy. Fail-open und fail-closed sind Entscheidungen, die dein Proxy trifft, wenn er Caputchin nicht erreicht. Caputchin sieht diese Anfragen nie, also taucht keines der beiden Ergebnisse hier auf, in keiner Spalte.
- 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-Seiten-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.