今ではどのアナリティクスベンダーもクッキーレスと言います。自分の実装が実際に何をするのかを説明するところは少なく、何ができないのかを語るところはほとんどありません。この記事では私たちの実装を、うまく機能しない部分も含めて説明します。ツールの数字を信頼するなら、その数字がどう作られるのかを正確に知っておくべきだからです。
なぜ端末には何も置きたくなかったのか
Zenovay を作り始めたとき、私たちは早い段階でひとつの決断をしました。ブラウザに何も保存しないトラッキングモードがあるべきだと。クッキーも、localStorage も、IndexedDB も、タブを越えて残るものは何もありません。これはサイトごとの設定で、新しく作成したサイトでは既定で有効です。オフにしたときにのみ、トラッカーはファーストパーティクッキーとブラウザストレージを使用します。保存を行わないという特性が重要なら、前提とせずスイッチを確認してください。
保存が悪だからではありません。保存はコミットメントだからです。誰かの端末に識別子を書き込んだ瞬間、保存と削除に関する義務を背負い、多くの場合バナーも背負います。私たちは、削除すべき保存データが存在しないモードを求めました。ただしそれで適法な根拠の問題が消えるわけではありません。ある訪問に同意が必要かどうかは、別の法に基づく別のルールであり、今も適用され、その責任は私たちではなくサイト所有者にあります。
この決断は、アナリティクスで最も基本的な問いに答えようとするまでは、きれいに聞こえます。このページビューは 5 分前と同じ人物からのものか、という問いです。保存された識別子がなければ、正直な答えは、推測するしかない、です。つまり本当の設計上の問いはこうです。どうすればうまく推測でき、その推測をどう失効させるか。
アイデンティティ関数
これが仕組みのすべてです。イベントが私たちのエッジに届くと、サーバーは次を計算します。
visitor_key = sha256(
ip_subnet // not the full IP
+ user_agent // the browser's own header
+ daily_salt // rotates at midnight UTC
)
セッションは、そのキーを基準にした 30 分間のウィンドウです。分析レコードが保存される前に、Cloudflare Workers 上のサーバー側でハッシュが計算されます。クッキーレスモードでは、開いているタブ内のイベントをまとめるために、トラッカーがウィンドウ限定のランダムな訪問者 ID とセッション ID を送信します。これらの ID はブラウザに保存されず、取り込み処理では永続化の前に訪問者 ID が日次のサーバーハッシュへ置き換えられます。端末上に Cookie、localStorage、IndexedDB の項目は作成されません。
3 つの材料があり、それぞれ理由があって選ばれています。
完全な IP ではなく、IP サブネット。 完全なアドレスを使うと、キーはより正確になると同時に、より侵襲的になります。サブネットは意図的にぼかされています。また、モバイルネットワークのゆらぎの一部も吸収します。そこではリクエストごとに末尾のオクテットが変わることがあっても、サブネットは変わらないままだからです。
ユーザーエージェント。 家庭用ルーターの背後にいる 2 人を、何もないよりはうまく分離します。単体では弱い信号ですが、それでかまいません。3 つの入力のうちの 1 つです。
日次ソルト。 ソルトは UTC 深夜に変わるため、キーは作成されたその日にしか有効でなく、単一のサイトに限定されます。弊社のインフラから外に出ないサーバー側の秘密値と組み合わせることで、データベースの複写を手にした者が ID を人物に戾すことはできません。その上で限界を正確に記します。ローテーションは破棄する乱数ではなく日付から導かれているため、私たち自身が意図して行えば過去のキーを再計算できます。より強い文が真実である方が望ましいので、ローテーションを破棄される日次の乱数値に移行しています。それが出荷されるまでは、これが正確な記述です。
欠点
このソルトのローテーションは欠点でもあり、脚注に隠すのではなく、それについて正確でありたいと思います。
UTC 深夜には、地球上のすべての訪問者キーが変わります。同じ人物が、同じネットワークで、同じブラウザで、まったく新しい訪問者になります。つまり、こういうことです。
- 複数日にわたるユニーク訪問者数は過大にカウントされます。毎日読む読者は、週次のビューでは 7 人として現れます。
- 複数日にわたるリピート訪問者率は、クッキーレスモードでは正直に計算できるものではないので、できるふりはしません。
- 月曜に料金ページを読み、金曜に登録するような 5 日間の検討ジャーニーは、無関係な 2 人のように見えます。
事業が日をまたいだ訪問者の安定性に依存しているなら、この設計はあなたを苛立たせるでしょう。これは私たちが直せるバグ報告ではありません。上で述べた性質の代償であり、その代償ははっきりと述べる価値があると考えています。
それでも機能するもの、そしてなぜ収益アトリビューションが生き残るのか
1 日の中で起きることはすべて通常どおり機能します。セッション、ジャーニー、ファネル、ライブビュー、そして今まさに起きている訪問のチャネルアトリビューションです。
興味深いのは収益のケースです。アイデンティティが深夜に消えるなら、最初の訪問から 3 週間後に、どのチャネルが有料顧客を生んだのかを、どうやってお伝えできるのでしょうか。
なぜなら、コンバージョンの時点で推測は止まるからです。誰かが登録または支払いをすると、その人はあなたのプロダクトに対して自分を名乗り、あなたのプロダクトはそれを私たちに伝えられます。その瞬間からジャーニーは実在のアカウントに固定され、アトリビューションの問いは、コンバージョンからさかのぼって、再び答えられるものになります。コンバージョン前の段階は個人を特定しないままです。支払いの段階は正確です。私たちは、そこが境界を置くのに正しい場所だと考えます。精度は、人があなたとの関係を選んだ、まさにそのときに訪れます。
私たちが退けたもの
より重いフィンガープリンティング。 キャンバスのエントロピー、フォントの列挙、オーディオコンテキストの癖。それはキーをより安定させ、同時に私たちを、より見栄えのよいランディングページを持つ監視企業にするでしょう。いいえ。
週次ソルト。 継続性は向上し、プライバシーの物語は柔らかくなります。しかしいったん週次でローテーションすれば、月次までは設定変更ひとつ、決してしないところまではもうひとつです。日次は明確な一線であり、明確な一線はプロダクトの圧力に耐えます。
localStorage のフォールバック。 ヒューリスティックが問題ないと判断したときだけキーを保存するというのは、私たちのランディングページの正直な一文に注釈が必要になることを意味します。その一文は継続性よりも価値があります。
衝突、なぜなら正直さは双方向だから
上記の欠点は 1 人を多数に分けます。
逆の失敗も存在します。同じオフィスの、同じサブネットの、同一のブラウザバージョンを持つ 2 人は、1 日だけ 1 人の訪問者に統合されることがあります。それを受け入れます。過少カウントも過大カウントもどちらも歪みですが、境界があり、毎日失効し、そのどちらも誰かの端末に書き込む必要はありません。
それでも日をまたいだ安定性が必要な場合
クッキーレスはモードであり、教義ではありません。Zenovay のすべてのサイトにはスイッチがあり、新しく作成したサイトでは既定で有効です。オフにするとトラッキングはファーストパーティクッキーを使い、訪問者は日をまたいで安定し、それに伴う同意義務は、どのツールでもそうであるように、あなたの側にあります。セッションリプレイ、ヒートマップ、クロスドメイントラッキングはそれぞれ別の機能で、独自の保存と同意上の影響を伴います。これらを有効にすることは、このモードで運用することと同じではありません。
要点
これを書いたのは、たいていのクッキーレスの主張がマーケティングの文章であり、マーケティングの文章には故障モードがないからです。本物の仕組みにはあります。私たちの仕組みは UTC 深夜に人を分け、一部の同僚を統合し、正直に答えられない問いには答えることを拒みます。それを知ったうえで、私たちの数字が何を意味するのかを、あなたが判断できます。
もしあなたがアイデンティティのシステムを作ったことがあり、私たちが見落としたより鋭いトレードオフに気づいたなら、ぜひ聞かせてください。
