Статистика страничного шлюза на прокси

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

Где она живёт

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

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

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

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

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

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

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

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

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

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

Счётчики близки, но не точны

Исходы шлюза собираются в пачки до записи, так что счётчик может потерять несколько событий, если край переработается посреди секунды. Отношения и тренды надёжны; относись к отдельному счётчику как к очень близкому, а не точному, особенно на тихом сайте.

Хранение

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

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

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

См. также

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