跳出率需要一个比特，不需要追踪器

到 8 月 28 日为止，这个站点不显示跳出率，而「关于」页面说这是有意的：它需要跨多个页面追踪的会话，而那需要一个同意横幅。

前一半是真的。后一半在我们开始记录退出页面的那一刻就不再成立，而没有人去改那句话。

为什么它没法直接算出来

有一张页面到页面的跳转表。它看起来正是跳出率所需要的一切：一次从一个页面走到另一个页面的访问不是跳出，所以数一数没有跳转的访问就好。

这样不行，原因写在记录代码的三行里。当两个页面相同时，跳转被丢弃；当它们之间隔了超过三十分钟时，被丢弃；在一个计数器一天里出现三百个新配对之后，也被丢弃。每一条规则对这张表的用途来说都是对的 — 显示哪个页面通向哪个 — 而每一条都让一个真实的第二页面变得看不见。

与此同时，一次访问若要被计数，持续一小时：那是实时表里那一行的寿命。于是分子用一种访问的定义，分母用另一种。那个数字不会是稍微错，而是没有着落。

8 月 27 日和 28 日共有 8,669 次访问和 2,817 次跳转，平均每次访问 1.32 个页面。572 个计数器里有 99 个记录到过任何跳转。

这不是开关关着 — 路径记录默认打开，全部 166,453 个计数器都是打开的。那些站点是真的只有一个页面：个人资料页、单页站点、别人平台上的一个图库。它们里的大多数，跳出率会接近百分之百，而那是对的。

一次访问本来就有一行，存活一小时。它现在多带一样东西：这次访问是否曾看过第二个、不同的页面。这个值在本来就会执行的那条语句里设定，不需要额外查询：

ON DUPLICATE KEY UPDATE mehr = mehr | (url <> VALUES(url)),
                        last_seen = UNIX_TIMESTAMP(), url = VALUES(url)

这几个赋值的顺序就是全部诀窍。数据库从左往右求值，所以比较发生时 url 里还是上一个地址。把 url 放到前面，这一行就会拿新地址和它自己比，比特永远是零，跳出率对所有人都显示百分之百。这种故障看起来和一个可信的结果一模一样，所以值得先在一行用完就丢的数据上证明它，再去相信它。

一小时过后，夜间清理会数一数即将过期的行 — 多少次访问，其中多少是多页的 — 每个计数器每天写一行，然后把它们删掉。比特活一小时。没有 cookie，也没有任何比它活得更久的东西。

有趣的问题从来不是怎么追踪一个会话。而是我们本来就记下来的东西里，哪一样恰好回答了这个问题 — 以及那个答案是否和问题绑在同一个定义上。

两个看起来都在量访问的来源，一个用三十分钟的规则，一个用六十分钟的，会给出一个比值，它是一个数字，什么也不表示。给一行已经存在的数据加一个比特，比事后解释这个比率为什么是这样要便宜。