直帰率に要るのは一ビットで、追跡装置ではない

八月二十八日まで、この場所は直帰率を出していなかった。案内の頁はそれを意図だと書いていた。複数の頁にまたがって追う会話が要り、そのためには同意の帯が要る、と。

前半は本当だった。後半は、離脱の頁を書き留めはじめた瞬間に本当でなくなり、その一文を誰も直さなかった。

なぜそのまま計算できなかったか

頁から頁への移りを記した表がある。直帰率に要るものが全部そろっているように見える。ある頁から別の頁へ進んだ訪問は直帰ではないのだから、移りのない訪問を数えればよい。

それでは足りない。理由は書き留める側の三行にある。移りは、二つの頁が同じとき、あいだが三十分を超えたとき、そして一つのカウンターで一日に三百の新しい組を越えたときに捨てられる。どの規則も、この表の目的 — どの頁がどの頁へ導くかを見せること — には正しく、そしてどれもが本物の二枚目の頁を見えなくする。

一方、訪問は数えるためには一時間続く。生きた表のその行が生きている長さだ。分子と分母が二つの異なる訪問の定義を使うことになる。その数はわずかに誤るのではなく、どこにも繋がれていないものになる。

それでも数字が言ったこと

八月二十七日と二十八日で、訪問は 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 を先に置けば、行は新しい住所を自分自身と比べ、ビットは永久にゼロのまま、直帰率は誰に対しても百パーセントを示す。それは、もっともらしい結果とまったく同じ顔をした故障である。だから信じる前に、捨ててよい一行で確かめる値打ちがあった。

一時間が過ぎると、夜の片づけが切れる行を数える — 訪問がいくつ、そのうち複数頁がいくつ — カウンターと日ごとに一行を書き、行を消す。ビットは一時間だけ生きる。クッキーはなく、それより長生きするものもない。

ここから一般化できること

面白い問いは、会話をどう追うかではけっしてなかった。すでに書き留めているもののうち、どれがたまたまその問いに答えるのか — そしてその答えが、問いと同じ定義に繋がれているかどうかだった。

どちらも訪問を測っているように見える二つの出どころが、一方は三十分の規則、もう一方は六十分の規則を使えば、出てくる比は数ではあっても何も意味しない。すでにある行へ一ビット足すほうが、あとでその割合がなぜそうなのかを説明するより安い。