Statistiques de la porte de page au proxy
La porte tient ses propres statistiques, séparées des statistiques de vérification d'une clé de site. La page de vérification répond "les vraies personnes passent-elles le jeu ?" ; cette page répond à une question plus étroite : "à quelle fréquence la porte défie-t-elle les visiteurs plutôt que de laisser passer un visiteur dégagé ?" C'est ainsi que tu confirmes que la porte est câblée et réglée, et c'est la même surface sur laquelle le mode aperçu écrit pendant que tu testes encore.
Où elle vit
Il y a deux vues :
- Par clé de site : la page Statistiques proxy sous une clé de site, pour une origine protégée.
- Par équipe : la page Statistiques proxy au niveau de l'équipe, agrégée sur chaque clé de site de l'équipe.
Les deux ont besoin du plan Alpha ou supérieur ; en dessous, la page montre une carte de mise à niveau à la place.
Les quatre comptes
Chaque décision de la porte est notée comme l'une de quatre sortes :
- Passage direct : une requête est arrivée avec un laissez-passer valide et a été autorisée. C'est la condition de victoire ; un visiteur dégagé qui parcourt le site en génère.
- Défi affiché : une requête n'avait pas de laissez-passer valide, donc le visiteur a été envoyé à la vérification.
- Laissez-passer émis : un visiteur a passé la vérification et un laissez-passer a été frappé (le callback a ensuite posé le cookie).
- Refusé : une requête est arrivée en portant un laissez-passer qui n'était pas valide : expiré, trafiqué, ou émis pour une autre clé de site. Une première visite sans aucun cookie n'est pas comptée ici ; ça apparaît comme un défi.
Le ratio de passage direct sur défi
Le chiffre phare, c'est le passage direct relatif aux défis. Une fois que les visiteurs dégagent la porte, la plupart de leurs requêtes devraient être du passage direct, avec un défi seulement au début d'une visite ou après qu'un laissez-passer expire. Un ratio de passage direct élevé veut dire que ta TTL de laissez-passer fait son travail, une seule résolution achète beaucoup de requêtes. Si les défis restent élevés relativement au passage direct, la TTL est peut-être trop courte (visiteurs re-défiés en milieu de session) ou le cookie n'est pas posé (vérifie le callback).
La lire pendant le déploiement
Tant que le mode aperçu est actif, guette la séquence dans une seule visite de test : un challenge_served (pas encore de cookie), puis un pass_issued après que tu passes la vérification, puis passthrough qui grimpe pendant que tu recharges. Des défis manquants veulent dire que le bloc de l'autorisateur n'est pas atteint ; un pass_issued qui ne devient jamais du passage direct veut dire que le cookie ne tient pas.
Les comptes sont proches, pas exacts
Les issues de la porte sont regroupées par lots avant d'être écrites, donc un compteur peut perdre quelques événements si l'edge se recycle en plein milieu d'une seconde. Les ratios et les tendances sont fiables ; traite un compte individuel comme très proche plutôt qu'exact, surtout sur un site peu fréquenté.
Rétention
L'historique est retenu par palier de plan et les buckets plus anciens sont élagués selon un calendrier quotidien, donc la fenêtre sur laquelle tu peux regarder en arrière s'élargit avec ton plan. Le ratio en direct et l'activité récente sont toujours disponibles.
Ce qui n'est pas ici
- Pas de passages directs ni de blocages de mode d'échec depuis ton proxy. Le fail-open et le fail-closed sont des décisions que ton proxy prend quand il ne peut pas joindre Caputchin. Caputchin ne voit jamais ces requêtes, donc aucune des deux issues n'apparaît ici, dans aucune colonne.
- Pas de données par visiteur. Des comptes seulement, pas d'IP, pas d'user agent, pas de contenu de requête, en accord avec la posture de confidentialité de Caputchin.
Voir aussi
- Vue d'ensemble : ce qu'est la porte et le cookie de laissez-passer.
- Configurer la porte de page au proxy : le mode aperçu écrit sur cette surface avant que tu passes en direct.
- Statistiques de vérification hébergée : la surface équivalente pour l'option sans backend.