チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
トラッキングスクリプトなしで国別に分析をセグメント化する
ほとんどのアナリティクスプラットフォームは、「訪問者はどこから来ているのか」という問いに、訪問者のブラウザでスクリプトを読み込み、収集できた情報を送り返すことで答えます。ページを高速に保ち、スクリプトの量を小さく抑えたいと考えていたあるパブリッシャーは、数値がダッシュボードに表示されるまでに読み込み、実行、送信を行わなければならないクライアントサイドのコードをさらに1つ追加することなく、同じ答えを得たいと考えていました。
代わりの方法は、パブリッシャー自身のサーバーがページビューごとに処理しているリクエストの中に、すでにありました。訪問者のIPアドレスです。このアドレスを/v1/ipに渡すと、国、地域、都市、郵便番号、座標、タイムゾーン、ASN、組織が判定され、訪問者のブラウザは何もする必要がありません。パブリッシャーのサーバーは、すでに記録していた各ページビューとあわせて国と地域のフィールドを記録しました。こうして国別のトラフィック分析は、新たに追加しなければならないデータソースではなく、サーバーがすでに持っているデータから生成されるレポートになりました。
これはピクセルやビーコンとは大きく異なるアプローチです。訪問者のブラウザから第三者へ何かが送信されることはなく、広告ブロッカーや、サードパーティのトラッカーを黙って遮断するプライバシー設定をスクリプトがくぐり抜けられるかどうかにも左右されませんでした。こうした設定のあるトラフィックは、ほとんどのサイトで現実に存在し、増え続けています。検索は、リクエストがすでに処理されているその瞬間に完全にサーバーサイドで実行され、結果は、スクリプトに協力した一部の訪問者のブラウザから推測されるのではなく、直接記録されました。
パブリッシャーは、得られた国のデータをすぐに2つの用途に使いました。編集部門は、どの国の人がどのセクションを読んでいるかを、初めて確かな自信を持って把握できるようになりました。国のフィールドが、JavaScriptベースのツールで取得できた一部だけでなく、すべてのページビューに付与されていたからです。広告営業部門は、別々で時に食い違う2つのアナリティクスシステムを維持するのではなく、編集チームがすでに見ているのと同じ基盤の数値を使って、広告主に地理的なリーチを報告できるようになりました。
これには、特に機微な情報を保存する必要は一切ありませんでした。国や地域レベルの詳細は本質的に大まかなもので、個々の訪問者を特定するためではなく、集計レポートに役立つものです。また、このデータに対するパブリッシャーの保存ポリシーは、同社がサーバーログ全般にすでに適用していたのと同じルールに従っていました。
リクエスト量はページビューに直接連動します。ある程度の規模のパブリッシャーであれば、利用量はかなり早く1日あたりの無料枠を超え、1リクエストあたり€0.0001のプリペイドクレジットに移るか、量が多く予測可能になった時点で、月額€50のUnlimitedキーのほうがシンプルな選択肢になります。どちらの場合でも、同じ国別の内訳に料金を課すサードパーティのアナリティクスプラットフォームのコストと比較する計算は簡単でした。しかもそうしたプラットフォームは、スクリプトベースの手法で取りこぼしが多いために、信頼性の低いデータしか得られないこともよくあります。
より大きな変化は、技術的なものであると同時に考え方の変化でもありました。アナリティクスのための位置情報は、訪問者のブラウザで動作する何かから得る必要はありません。リクエストをすでに処理しているのと同じサーバーから、サーバーがすでに見ているデータを使って得ることができます。このエンドポイントのドキュメントは、/docs/ipv4-lookup/と/docs/ipv6-lookup/にあります。