无 Cookie 统计对你的数字意味着什么

「无 Cookie」已经成了厂商贴在任何与隐私沾边的东西上的标签，所以值得说得精确一点。在 TapCub 里它指一件具体的事：浏览器里不存任何标识，访客由一个不可逆、每天都变的哈希来计数。这一个设计决定，对你的数字、你的同意弹窗和你的合规位置都有后果。这篇文章讲机制、讲你放弃了什么、得到了什么，以及哪些情况下你仍然需要身份。

这里的「无 Cookie」指什么

基于 Cookie 的统计往浏览器里写一个标识，每次访问再读回来。这个标识在大多数隐私法规下属于个人数据，弹窗就是为它存在的。无 Cookie 统计什么都不写。它明天认不出你，这正是目的；它也不会被 Cookie 设置拦住，这正是覆盖更好的原因。

TapCub 不做什么同样重要：它不做指纹。指纹用设备特征拼出一个稳定标识，好在没有 Cookie 的情况下跨天认出你，那不过是多绕几步的 Cookie。每日哈希的设计目的就是遗忘。

访客是怎样被计数的

每次请求到来时，采集端把几个本来就会随请求到达的属性（站点、粗粒度的网络标识、用户代理）和一个每天重新生成的秘密盐组合起来，做哈希，只保留哈希值。输入被丢弃。同一天来自同一浏览器的两次请求产生同一个哈希，算一个访客；明天盐变了，哈希也变了，昨天的访客无法和今天的关联。用伪代码写：

// 盐在 00:00 UTC 轮换，从不落盘
salt = dailySalt(today)

// 这些输入本来就随每次请求到达
visitorId = sha256(siteKey + salt + coarseNetwork(ip) + userAgent)

// 保留哈希，丢弃输入
store(event, visitorId)
forget(ip, userAgent)

你失去什么

诚实的取舍是跨天身份。基于 Cookie 的工具能告诉你本月 40% 的访客后来某天又回来了；无 Cookie 的工具不能，因为它选择了不具备这个能力。月独立访客会比基于 Cookie 的工具高（每天的访客都是新的），「新访客 vs 回访」只在一天之内、或对已识别的用户有效。

所以留存报表需要你提供的身份：登录、账号 ID、客户编号。没有它，留存是按已识别用户算的，不是按匿名访客。对大多数生意这条线划得正好：你要的是客户的留存，而客户有账号。

你得到什么

三样东西。第一，多数情况下不需要为统计单独弹同意窗口，因为什么都没存、什么都不是个人数据。第二，完整覆盖：拒绝 Cookie、用严格隐私浏览器、清除存储的访客照样被计数，数字不再取决于每个地区的同意率。第三，更干净的合规位置，写在隐私与安全页上。

实际上覆盖的提升很大。从基于 Cookie 的工具迁到 TapCub 的网站通常会看到日访客数上升，不是流量变了，而是那 30–40% 拒绝 Cookie 的人现在看得见了。比较两者之前，先读UV 核对那篇。

Cookie 与无 Cookie，并排比

下表总结了两种模型各自能回答和不能回答的问题。哪一列都不「更好」；它们回答不同的问题，怎么选取决于你对匿名访客和已识别用户分别需要回答什么。

什么时候你仍然需要身份

无 Cookie 统计是地板，不是天花板。访客登录后，你的应用可以用一个稳定的用户 ID 调用 identify()，从此这个人的事件跨天、跨设备挂在这个 ID 上。这是经过同意的、第一方的，正是留存、生命周期价值和用户档案需要的东西。用户分析视图就建在它之上。

我们推荐的规则：匿名流量用无 Cookie 方式度量，不要弹窗；已识别用户按账号度量，用拥有账号时附带的同意。中间不留灰色地带。

这个划分也让工程保持简单。一段代码、登录时一次 identify() 调用，没有决定丢弃哪些事件的同意模式逻辑。开发者不用维护两条度量路径，报表也不用加一个「哪些地区被低估了」的脚注。

切换时要核对什么

如果你正从基于 Cookie 的工具迁过来，预期三个变化：日独立访客上升（覆盖），月独立访客上升更多（不做跨天关联），回访报表需要围绕已识别用户重新定义。更新所有引用月独立访客的看板，决定统计弹窗能不能撤掉，把 identify() 接进登录流程。迁移指南讲了并行运行那一周，数据平台页列出了默认采集的内容。