空のリファラーが最大グループである理由

ウェブトラフィックの発生元データをレビューする際、管理者は、未割り当てまたは空のカテゴリが最大の単一ボリュームを形成していることに頻繁に気づきます。これが発生する理由を理解するには、最新のブラウジング習慣とセキュリティ構成が受信ナビゲーション参照をどのように処理するかを調査する必要があります。

この欄はどこから来るのか

技術的な用語では、発生元インジケータ（歴史的にはリファラーと呼ばれる）は、前のページのアドレスを示すブラウザによって送信されるテキストの一部です。訪問者がアドレスバーに直接入力されたリンク、保存されたブラウザのブックマーク、外部のメッセージングアプリ、デスクトップメールクライアントなどを経由して到着した場合、この送信フィールドは完全に空のままになります。

この欄は、はじめから保証ではなかった。ブラウザが礼儀として渡すものであり、省くことも、書き換えることも、そのまま偽ることもできる。受け取る側にその区別はつかない。手がかりではなく計測として扱うことが最初の誤りで、その後の混乱の大半はそこから出ている。

ブラウザがそれを渡さない理由

さらに、最新のオペレーティングシステムやウェブブラウザに組み込まれている厳格なプライバシー設定は、ユーザーの機密性を保護するために発生元の詳細を意図的に抑制します。暗号化された安全なサイトから暗号化されていないエンドポイントにトラフィックを移動するセキュリティプロトコルは、標準的な保護策として参照データをルーチン的に削除します。

ふだんの使い方では、連絡用のアプリが、単独では最大の出どころになる。会話の中で回されたリンクをアプリの内側から開くと、出所はまったく付かずに届く。しかもそれは今日、小さなページが見つかる最も多い経路の一つである。

文書から開くものはすべて同じである。メールの道具で読む会報のリンク、紙の式次第から手で打ち込んだ一行、掲示から読み取った符号。どれも本物の到着で、向こうには本物の読み手がいて、そしてどれも空欄になる。

それでも一覧をどう読むか

その結果、空のカテゴリは、失われたシステムエラーや追跡不可能なシステムエラーを意味するものではありません。代わりに、直接ナビゲーション、プライバシーを意識したソフトウェア構成、安全なアプリケーションのハンドシェイクを反映しており、オーディエンスの動きのかなりの部分が従来のウェブリンク構造の外側で発生していることを示しています。

一覧の正しい読み方は、空欄の行をまるごと脇へ置き、残りだけを見ることである。名前のある項目は全数調査ではなく標本だが、ちょうど役に立つ種類の標本である。いまどの別のページが読み手を送り出しているかを示してくれる。

そして空欄の行にも、それ自身の使い道がある。ひと月で大きく縮んだなら、何か新しいものがリンクを張りはじめたということで、名前のある項目がそれを教えてくれる。増えたなら、そのページは人から人へ手渡しで回っている。別の種類の成功であり、ほかのどこにも現れない。