代理页面门禁
代理页面门禁统计
门禁保有它自己的统计，和一个站点密钥的 验证统计 分开。验证页回答“真人在通过游戏吗？”；这一页回答一个更窄的问题：“门禁挑战访客，相对于放一个已放行访客通过，有多频繁？”它是你确认门禁已接好、已调好的方式，也是 预览模式 在你还在测试时写入的同一个界面。
它住在哪
有两个视图：
- 按站点密钥：一个站点密钥下的 代理统计 页，针对一个受门禁的源。
- 按团队：团队一级的 代理统计 页，跨团队里每个站点密钥聚合。
两者都需要 Alpha 套餐或更高；低于此，该页改为展示一张升级卡。
四个计数
每个门禁决定都被记录为四类之一：
- 直接放行：一个请求带着有效通行证到来并被允许。这是取胜条件；一个已放行访客浏览站点会生成这些。
- 已展示挑战：一个请求没有有效通行证，于是访客被送去验证。
- 签发通行证：一位访客完成了验证，一张通行证被铸出（回调随后设置了 Cookie）。
- 拒绝：一个请求带着一张无效的通行证到来：已过期、被篡改、或是为另一个站点密钥签发的。完全没有 Cookie 的首次访问 不 计在这里；那会显示为一次挑战。
直接放行对挑战的比率
头号数字是直接放行相对于挑战。一旦访客们通过了门禁，他们的大多数请求应当是 直接放行，只在一次访问开始时、或一张通行证过期之后才有一次挑战。一个高的直接放行比率意味着你的 通行 TTL 在做它的活儿，一次解题买下许多请求。如果挑战相对于直接放行一直很高，那 TTL 可能太短（访客在会话中途被重新挑战），或者 Cookie 没被设置（检查回调）。
在推出期间读它
预览模式开着时，在一次测试访问里留意这个序列：一个 challenge_served（还没有 Cookie），然后在你通过验证后一个 pass_issued，然后随着你刷新，passthrough 在爬升。缺失的挑战意味着授权方块没被命中；一个从不变成直接放行的 pass_issued 意味着 Cookie 没粘住。
计数接近，但不精确
门禁结果在写入前会先攒成批，所以如果边缘在某一秒中途被回收，一个计数器可能丢掉少量事件。比率和趋势是可靠的；把单个计数当作非常接近，而不是精确，在流量小的站点上尤其如此。
保留
历史按套餐档保留，更旧的桶按每日计划被修剪，所以你能回望的窗口随你的套餐变宽。实时比率和近期活动始终可用。
这里没有什么
- 没有来自你代理的失败模式放行或拦截。 失败即开放和失败即关闭都是你的代理在够不到 Caputchin 时自行做出的决定。Caputchin 从不看见这些请求，所以两种结果都不会出现在这里，任何一列都不会。
- 没有逐访客数据。 只有计数，没有 IP、没有 user agent、没有请求内容，与 Caputchin 的隐私立场一致。