Статистика прокси-барьера

Барьер ведёт свою собственную статистику, отдельную от статистики проверки ключа сайта. Страница проверки отвечает "проходят ли реальные люди игру?"; эта страница отвечает на более узкий вопрос: "как часто барьер бросает посетителям испытание против того, чтобы пропустить пропущенного посетителя?" Так ты подтверждаешь, что барьер подключён и настроен, и это та же поверхность, на которую режим предпросмотра пишет, пока ты ещё тестируешь.

Где она живёт

Есть два вида:

• По ключу сайта: страница Статистика прокси под ключом сайта, для одного закрытого источника.
• По команде: страница Статистика прокси на уровне команды, сведённая по каждому ключу сайта в команде.

Обе нужны на плане Alpha или выше; ниже этого страница показывает карточку апгрейда вместо этого.

Четыре счётчика

Каждое решение барьера записывается как один из четырёх видов:

• Прямой пропуск: запрос пришёл с валидным пропуском и был разрешён. Это условие победы; пропущенный посетитель, просматривающий сайт, порождает их.
• Испытание показано: у запроса не было валидного пропуска, так что посетителя отправили к игре.
• Пропуск выдан: посетитель решил игру и был отчеканен пропуск (callback затем поставил cookie).
• Отказано: авторизатор отклонил запрос при политике fail-closed, пока не мог подтвердить пропуск.

Отношение прямого пропуска к испытаниям

Заглавное число это прямой пропуск относительно испытаний. Как только посетители проходят барьер, большинство их запросов должны быть прямым пропуском, с испытанием только в начале визита или после того, как пропуск истёк. Высокое отношение прямого пропуска значит, что твой TTL пропуска делает своё дело, одно решение покупает много запросов. Если испытания остаются высокими относительно прямого пропуска, TTL может быть слишком коротким (посетителей заново испытывают посреди сессии) или cookie не ставится (проверь callback).

Читая её во время раскатки

Пока режим предпросмотра включён, следи за последовательностью в одном тестовом визите: один challenge_served (ещё нет cookie), затем pass_issued после того, как ты решишь, затем passthrough, растущий, пока ты перезагружаешь. Пропавшие испытания значат, что блок авторизатора не задевается; pass_issued, который никогда не превращается в прямой пропуск, значит, что cookie не липнет.

Хранение

История хранится по уровню плана, и старые корзины подрезаются по ежедневному расписанию, так что окно, на которое ты можешь оглянуться, ширится с твоим планом. Живое отношение и недавняя активность доступны всегда.

Чего здесь нет

• Нет прямых пропусков в режиме fail-open от твоего прокси. Когда твой прокси настроен fail-open и Caputchin недостижим, прокси пропускает запрос сам по себе; Caputchin его никогда не видит, так что его нельзя посчитать здесь.
• Нет данных по посетителю. Только счётчики, ни IP, ни user agent, ни содержимого запроса, в согласии с позицией приватности Caputchin.

См. также

• Обзор: что такое барьер и cookie пропуска.
• Настрой прокси-барьер: режим предпросмотра пишет на эту поверхность, прежде чем ты запустишь в бой.
• Статистика размещённой проверки: равнозначная поверхность для варианта без бэкенда.