あなたは、読者を観察するための1本のスクリプトを設置した。
それはこちらを観察し返し、どこか別の場所へ報告する。

多くの場合はイエスであり、その理由は「セルフホストだから大丈夫」よりもう少し精密である。ここには2つの別個のルールが関わっている。eプライバシー指令第5条(3)——誰もが「クッキー法」と呼ぶもの——は、訪問者が求めたサービスに厳密に必要な場合を除き、訪問者のデバイスに情報を保存すること、またはそこから情報を読み取ることに同意を要求する。これはクッキーに適用されるが、localStorageやsessionStorage、その他あなたが残していくものすべてにも適用され、そのデータが個人データであるかどうかにかかわらず適用される。デバイスに何も書き込まないツールは、単純にこれを発動させない。GDPRは2番目のルールであり、これは消えてなくならない。すべてのリクエストで、あなたは依然としてIPアドレスとユーザーエージェント文字列を受け取っており、IPアドレスはウェブサイト運営者の手元にあるとき個人データである(欧州司法裁判所、Breyer判決、C-582/14)。クッキーレスなアナリティクスサーバーが行っているのは、そのIPを毎日ローテーションされるソルトでハッシュ化し、その後破棄することであり、データベースに残るのは、人物ではなく、日単位・サイト単位の仮名である。これは狙いの絞られた、十分に文書化された処理業務であり、多くの運営者は正当な利益を根拠としており、複数の監督機関が、純粋なオーディエンス測定が同意の対象外となる基準を公表している。これは弁護可能な立場であって、魔法の言葉ではない。何を、なぜ、どれだけの期間収集するのかを書き留め、ベンダーのランディングページではなく自分の監督機関のガイダンスを読むこと。このページの内容は法的助言ではない。

Umamiである。単一のNodeアプリケーションと1つのPostgreSQLデータベースであり、1 GBのメモリの中で余裕を持って動き、ダッシュボードは最初に訪れた時点で読みやすく、標準でクッキーレスであり、1つのインスタンスが自分が所有するすべてのサイトを問題なく処理してくれる。ブログ、ドキュメントサイト、店舗、あるいは企業サイトでGoogle Analyticsを置き換えようとしている大多数の人にとって、これが正しい答えであり、残りの3つは、そもそも交わす必要のなかった議論である。代わりにPlausible Community Editionを選ぶのは、ファネル、収益ゴール、より強力な公開ダッシュボードが欲しく、そのためにClickHouseを動かす覚悟がある場合である。Matomoを選ぶのは、Google Analyticsの機能セット——セグメント、コホート、カスタムレポート、eコマースアトリビューション、生ログのインポート——を本当に必要としており、スケジュール実行されるアーカイブジョブを持つ大規模なPHPアプリケーションを運用することを受け入れられる場合である。GoAccessを選ぶのは、ページ上にJavaScriptを一切置きたくない場合である。

なぜなら、両者は異なるものを数えており、そのずれは両方向に同時に生じているからである。上振れの要因その一。同意バナーの背後にあるGoogle Analyticsは、「同意する」を押した訪問者しか見ておらず、ヨーロッパではそれが全体の半数程度になるのが日常的だが、バナーのないクッキーレスなカウンターは全員を見ている。上振れの要因その二。新しいエンドポイントは自分自身のドメイン上にあり、よく知られたトラッカーへのリクエストを捨てるフィルターリストには載っていない。下振れの要因その一。日次でローテーションするハッシュは、同じ人物を翌日には認識できないため、月曜日と木曜日に訪れた読者は、1人のリピーターではなく2人の訪問者として数えられる——セッションは1日の範囲内でのみつなぎ合わされ、日をまたいだり、デバイスをまたいだりすることは決してない。下振れの要因その二。ほとんどのセルフホスト型ツールは、控えめなボットフィルターを標準搭載しており、Discoverのような膨張は起きない。実践的な助言は、数字を突き合わせるのをやめることである。両方を2週間動かして自分なりの比率を把握し、それを付箋に書き留め、それからGoogleのタグを削除して、新しい数値を今後の基準として使う。意思決定にとって重要なのは、トレンドの形状とページや参照元の相対的な順位であり、そのどちらも、この移行を経てそのまま生き残る。

部分的にはそうであり、その仕組みを正確に知っておく価値がある。人々が思っているよりも、この仕組みは単純だからである。大規模なフィルターリストはパターンで動作する。ホスティングサービスのホスト名と、よく知られたファイル名・パス名の集合である——plausible.js、umami.js、matomo.phpのいずれかで終わるリクエストは、どのサーバーへ向かうものであれ識別可能である。ソフトウェアを標準のファイル名のままstats.example.comに移しても、技術に詳しい層の一部は依然として失われる。誠実な対処法は2つあり、それらは積み重ねられる。スクリプトと収集用エンドポイントを、トラッカーらしくない名前に変更すること——これらのツールはいずれもそれを許しており、設定1行分のコストで済む。それらを、リバースプロキシが転送するメインドメイン上のパスを通じて、サイト自体と同じオリジンから配信すること。これで、ブロックされるべきサードパーティのリクエストは残らなくなる。両方を組み合わせれば、失われた分の大半を取り戻せる。すべてを取り戻すことはできないし、それを望むべきでもない。厳格なリストとJavaScript無効化を組み合わせている訪問者は、それを選んだのであり、それに対する正しい応答は軍拡競争ではなく、サーバーログである。

その問いには答える価値があり、答えはそのブロッカーが何を守っていたかによって決まる。フィルターリストは1つの鈍い道具しか持たず、それが向けられる対象は2種類、まったく性質の異なるものである。1万のサイトを横断して人を追跡し、プロファイルを構築するアドテックネットワークと、あるサイトのオーナーに、そのドキュメントページが昨日400回読まれたと伝えるだけのカウンターである。前者をブロックするのは、監視に対して自分自身を守る行為である。後者をブロックするのは、両者を区別できないルールによる巻き添え被害である。自分のカウンターを自分のドメインから配信することは、トラッカーを防御の網をすり抜けて密輸することではなく、そもそも存在すべきでなかったサードパーティのリクエストを取り除くことであり、同じ訪問はいずれにせよあなたのアクセスログに1行を生み出す。この立場が正当化できなくなるのは、プロキシしている対象がここで説明したものとは異なるものになった瞬間である——クロスサイトの識別子、フィンガープリンティング、あるいは広告プラットフォームへのパイプラインを追加するなら、ブロッカーは正しく、そのプロキシは欺瞞である。テストは単純であり、一度は自分自身に適用する価値がある。このエンドポイントが正確に何を収集しているかを説明するページを公開できるか、そして読者はそれを見て肩をすくめるだけで済むか。答えがイエスなら、プロキシしてよい。ノーなら、問題はプロキシそのものではない。

恐れているより小さくて済み、例外は1つだけである。UmamiはNodeプロセスとPostgresデータベースであり、通常のサイトなら1 GB未満のメモリに収まり、データベースはページビューごとにおよそテキスト1行分の大きさで増えていくため、Sentinel——2 vCPU、4 GB、120 GB NVMe、月額$3.90——には数年分の余裕がある。GoAccessは誤差のようなものである。Matomoはその中間に位置する。PHPとMariaDBはアーカイブジョブが走るまでは要求が少ないが、そのジョブこそがサイズを見積もる際に考慮すべきCPUスパイクであり、生テーブルは1ヒットあたりに保持する情報が多い分、他より速く肥大化する。例外はPlausible Community Editionであり、その理由はPlausible自体ではなくClickHouseにある。カラムストアはクエリ速度のためにメモリを使うように作られており、置いてあるものは何でも使い切ってしまう。出荷時設定でキャッシュに上限を設ければ4 GBでも動くが、8 GBあれば余裕がある——これが、$7.90のGarrisonティアがそのツールにとって妥当な下限である理由である。いずれの場合も、最終的にアップグレードを迫るのはメモリではなくディスクであり、ステップ06はそれを止める方法である。

できる。そしてそれが、これらを運用する通常の方法である。3つのJavaScriptツールはいずれも、最初からマルチサイト対応として設計されている。ダッシュボードで各ドメインを登録すれば、それぞれが自分専用の識別子を得て、同じスクリプトエンドポイントがそのすべてのヒットを受け付けながら、レポートは別々に保たれる。1台のマシン、1つの証明書、1つのバックアップ、1つのアップグレード——それで20サイトを処理できる。リストが増えていくにつれて、留意すべき点が2つある。レポートはサイトごとに分かれているため、クライアントのサイトを管理しているなら、全員に管理者アカウントを渡すのではなく、そのツール自身のユーザー権限とチーム権限を使うこと。そして、共有インスタンスが何を意味するのかを、契約でそれに同意する前に確認すること。あなたは、彼らの訪問者データを保持する当事者になるのである。そしてトラッキングエンドポイントは共有される名前であるため、それを配信するドメインが、リスト上のすべてのサイトのソースに現れることになる——これは、競合他社がページソースを読むようなクライアントに伝える価値のある事実であり、ステップ04のファーストパーティの経路を選ぶ根拠にもなる。

多くの種類のサイトにとっては、ログだけで十分であり、それは手に入る中で最も誠実な計測手段である。行はすでに存在しているのだから、余分なものは何も収集しないからである。GoAccessはウェブサーバーのアクセスログを読み込み、ターミナルレポートまたは自己完結型のHTMLダッシュボードを生成する——上位ページ、リファラー、ステータスコード、帯域、応答時間、ユーザーエージェント——静的サイトやドキュメント集、APIにとっては、これがスクリプトタグが教えてくれるはずだったことのほとんどである。それが自分にとって十分かどうかは、2つの限界によって決まる。ログはページの内部で起きることを見ることができない。スクロール量も、外部リンクのクリックも、ボタンイベントも、シングルページアプリケーションのルート変化も、どれもサーバーに触れないため記録されない。そしてログは人ではなくリクエストを数えるため、キャッシュと、今では生トラフィックの過半数を占めるボット群の言いなりになる——フィルタリングは、セットアップの一手順ではなく、恒久的な保守作業である。さらに、予想とは逆方向のプライバシーの落とし穴もあり、それはステップ06で扱う。分析しているそのログには完全なIPアドレスが記録されており、それは拒否したはずのJavaScriptツールが保持していたものより、多くの個人データを含んでいるのである。

現実的には、できないと考え、それを前提に計画したほうが、抗うよりもうまくいく。4つのうちインポートについて何かしら真剣な手段を持つのはMatomoだけであり、そこでも現実的な方法は、自分のウェブサーバーログをインポートすることと、古いMatomoインスタンス向けの移行ツールを使うことであって、Googleが処理済みのレポートをそのまま移すことではない。UmamiとPlausible Community Editionは、マッピングを自分で書く覚悟があれば、APIを通じた一括読み込みを受け付けられるが、それは集計済みのエクスポートからセッションや訪問者を作り出すことになり、結果として、連続しているように見えて実際には接合点をまたいで比較できないグラフができあがる。実際に効果があるのは次の方法である。プロパティが消える前に、気にかけているレポート——月間合計、上位ページ、上位参照元、コンバージョン数——をCSVとしてGoogleからエクスポートし、それを他の記録と同じ場所に保管し、新しいツールは、書き留めた日付を起点とする新しいベースラインとして始めることである。その古いエクスポートを参照するのは最初の1年に2度ほどで、その後は二度と見返さないだろう。そこに含まれるどの数字も、どうせ別の定義で計測されたものなのだから。

思っているより少なくて済み、その短さこそが要点である——自分で説明しきれる1段落は、どこかからコピーした1ページに勝る。そのツールが何であり、自分自身で運用していることを述べる。サーバーの所在地と法的な運営者名を明記すること。「フィンランドで借りているマシン上で」と言えること自体が、この取り組み全体の利点だからである。訪問ごとに記録される内容を述べる。ページ、リファラー、国、デバイスとブラウザの系列、そして毎日変わるソルトを使ってIPアドレスとユーザーエージェントから導出される、元のIPを復元できない仮名の識別子である。記録されないものも述べる。クッキーはなく、クロスサイトの識別子もなく、プロファイルもなく、データの販売や共有もない。依拠する法的根拠と保持期間を明記し、そこに書く数字がツールに実際に設定されている数字と一致していることを確認する。リバースプロキシがアクセスログを保持しているなら、それは独自の保持期間を持つ別個の処理業務であるため、それについても言及すること。これは人々が忘れがちな点である。そして、その文章を設定内容と同期させ続けること。2年前の構成を説明したままのポリシーは、曖昧なポリシーより悪い。

なぜなら、「ページビューだけ」という表現は、アナリティクスデータベースが本当は何であるかを過小に言い表しているからである。1年分を集計すれば、それはあなたのサイトの読者層そのものである。どのページを、どの順番で、どの国から、何時に、どのリンクから来て読んだか——小規模な出版者やニッチな店舗にとっては、これは事業計画と取引先リストが1つのテーブルに収まっているに等しい。また、法域という観点で見れば、これはまさに、敵対的な当事者があなたに尋ねるのではなくプロバイダに尋ねる類のデータである。そこから二つの性質が導かれる。まず、マシンがどこにあるかによって、どの法的手続がそこに及ぶかが決まる。StockholmやHelsinki、Oslo、Reykjavíkにあるマシンは、EEAの内側にあり、それによって国際移転の論点はコンプライアンス上の検討事項から完全に外れ、さらに、報道の自由の伝統が強い4つの立憲体制の内側にもある。次に、アカウントに誰の名前が載っているかによって、そのアカウント自体が何を明らかにするかが決まる。NordBastionでは本人確認書類も、法的な氏名も、カードもなく、請求はMoneroまたはBitcoinで決済され、あなたの読者データを保持するマシンは、どこかの顧客データベースにパスポート情報付きで記録された一行ではない。法域ガイドが、四つそれぞれの法的な最低水準を詳しく扱っている。