開発者ツール · URL エンコーダーとデコーダー
一貫性のない URL エンコードにより、分析で 1 ページが多数の行に分割される理由
· なぜそれが重要なのか
分析 URLエンコーディング 正規化
%20 と +、%2F と /, %c3 と %C3 はすべて同じ URL を記述することができますが、レポートではこれらが別のページとして扱われます。この投稿では、バリアントの出所と、カウントする前にバリアントを正規化する方法について説明します。
レポート内の 6 つの URL を含むランディング ページ - 並べて表示されるバリアントと分割されたトラフィック
データ アナリストは、分析ダッシュボードで 1 つのランディング ページが 6 つの異なる URL として表示されることに気づきました。同じページは次のとおりです。 /landing?utm_source=email, /landing?utm_source=%65mail, /landing?utm_source=email%20campaign, /landing?utm_source=email+campaign, /landing?utm_source=email%20Campaign, /landing?utm_source=email%2bcampaign. 各バリアントは個別のページ ビューとしてカウントされ、トラフィックが断片化されます。スプレッドシート、電子メール、フォームからのデータには、エンコーディングのバリエーションが導入されます。
一貫性のないエンコードは、複数のデータ ソースと変換に起因します。手書きのリンクでは、生のスペースが使用されるか、エンコーディングが使用されません。スプレッドシートのエクスポートでは、パーセントでエンコードされた URL が生成されます。電子メール クライアントは URL をマングルまたは再エンコードします。リダイレクト チェーンの正規化に一貫性がありません。 API 統合、JavaScript フレームワーク、および分析コードには、異なるルールが適用されます。同じ URL の概念がレイヤーを通過し、異なる方法でエンコードおよび再エンコードされます。
変動の原因 — 手書きのリンク、スプレッドシートのエクスポート、メール クライアント、リダイレクト チェーン
16 進数の大文字と小文字は、最初の正規化の問題を引き起こします。 RFC 3986 では、16 進数を大文字にする必要があると指定しています (%2f ではなく %2F)。大文字と小文字の 16 進数は同一のバイトをエンコードします。厳密な比較では、%2F と %2f が別々に扱われます。 RFC 3986 では文字が予約されていないものとして分類されるため、%65 としての文字「e」はエンコードされていない「e」に正規化される必要があります。 URL 全体をオーバーエンコードすると、異なる分析レコードが生成されます。
RFC 3986 の予約されていないセットには、A ～ Z、a ～ z、0-9、ハイフン、ピリオド、アンダースコア、チルダが含まれます。正規化された URL では、これらをパーセントでエンコードしないでください。 RFC 正規化では、%41 を「A」にデコードすると、エンコードされていない「A」に正規化される必要があると指定されています。これを URL 全体に適用すると、冗長なエンコーディングが削除されます。 %2f%6c%61%6e%64%69%6e%67 のような URL は、デコード後に /landing になります。
16 進数の大文字小文字と予約されていないセット — RFC 3986 が同等としているものとそうでないもの
予約文字は交換可能ではないため、正規化中は区別しておく必要があります。 RFC 3986 は、gen-delims (:, /, ?, #, [, ], @) と sub-delims (!, $, &, ', (, ), *, +, ,, ;, =) を予約しています。これらには構造的な意味があります。パス内のスラッシュは区切り文字として機能するため、エンコードしないでください。同じ文字がクエリ値のデータとして出現する場合、%2F としてエンコードする必要があります。やみくもにデコードすると URL 構造が壊れます。
正規化の微妙な違いにより、文脈上の理解を必要とする課題が生じます。予約されていない文字のみをデコードし、予約された文字はエンコードしたままにします。 /landing?data=%2F%20%2f のような URL はあいまいなままです。クエリ文字列は ? で始まります。 (予約済み、構造的)。クエリ値の内部には何でも表示できます。疑問符には %3F エンコードが必要です。 %2f%6c%61%6e%64%69%6e%67%3fkey%3dvalue としてエンコードされた URL は、/landing?key=value. に正規化されます。
予約文字は互換性がありません — %2F と / が正当に異なる意味を持ち得る理由
作業例: 6 つの URL バリアントを正規化することで、完全な正規化を示します。ベース URL は /page?utm_source=email&campaign=test. を表します。 6 つのバリアント: 1) /page?utm_source=email&campaign=test (正規)、2) /page?utm_source=%65%6d%61%69%6c&campaign=test (小文字の 16 進数)、3) /page?utm_source=email%20&campaign=test (値内のスペース)、4) /page?utm_source=email+&campaign=test (スペースとしてプラス)、5) /page?utm_source=EMAIL&campaign=test (大文字と小文字が異なる)、6) /page?utm_source=email&%63ampaign=test (名前は 16 進数)。
バリアント 2 を正規化するには、16 進数のケースを修正し、予約されていない文字をデコードする必要があります。%65%6d%61%69%6c は電子メールになります。プラス記号が付いたバリアント 4 にはコンテキスト認識が必要です。ソースが HTML フォームの場合、プラスはスペースを意味します。それ以外の場合、plus はリテラルです。バリアント 5 には大文字の「EMAIL」が含まれています。電子メールでは大文字と小文字が区別されないため、小文字の「email」が正規です。バリアント 6 には %63 (「c」は 16 進数) があります。予約されていないデコードでは、正規に一致する「キャンペーン」が生成されます。
作業例: 1 つの URL の 6 つのバリアントを正規化 - 安全な文字をデコードし、16 進数の大文字と小文字を修正し、区別できるものを修正する
パイプラインに正規化を実装する (取り込み時に正規化し、生の値を保持する) ことは、分析に推奨されるアーキテクチャです。 URL がデータベースに入る取り込みポイント (ログ エンドポイント) では、ページビュー キーを保存または導出する前に正規化を適用します。正規化: 1) URL をコンポーネントに解析します、2) 予約されていないシーケンスをデコードします (16 進数の場合を修正します)、3) パラメーターの順序を正規化します、4) グループ化のための標準形式を生成します、5) 正規化された形式と生の値を保存します。これにより、6 つのバリアントすべてが同じグループ キーにハッシュされることが保証されます。
正規化された URL に基づくハッシュ関数により、すべてのバリアントがレポート内の同一のページにマッピングされることが保証されます。分析システムに正規化が組み込まれていない場合は、データベースへの書き込み前にデータ エンジニアリング レイヤー (ETL パイプライン) が正規化されます。 Google Analytics などのツールの場合、構成可能なフィルターを使用すると、正規表現でグループ化したり、URL とは別にタイトルを送信したりできます。最も堅牢なアプローチはソースで正規化します。トラッキング コードが分析に URL を送信するときは、正規化された形式を保証します。
パイプラインで実行 — 取り込み時に正規化し、パターンとして記述された生の値を保持します
これでカバーされないものには、トラッキング パラメーターのストリッピングと SEO の正規タグが含まれます。これらは関連していますが、異なります。 utm_source や utm_campaign などの追跡パラメーターは、オーガニック コンテンツごとにグループ化するために分析から削除される可能性があります。これは別のビジネス ロジックです。 HTML 正規タグは、SEO のためにバリアント間のページビューを統合しますが、内部分析には影響しません。包括的な戦略では、両方のアプローチを組み合わせた複数の重複排除レイヤーを使用します。
分析空間の正規化サポートは多岐にわたります。 Google Analytics は一部の正規化を自動的に処理しますが、バリアントを見逃す可能性があります。他のツールでは手動構成が必要です。有料検索プラットフォームは、キャンペーン URL にさまざまな正規化を適用します。サーバー ログには、正規化せずに受信した URL が記録されます。包括的な戦略は、各レイヤーで適用される正規化と監査用に保存される生データを文書化します。 URL エンコーダとデコーダは、バリアントの検査に役立ちます。
これでカバーされないもの — トラッキングパラメータストリッピングポリシーとSEOの正規タグ
要点: カウントする前に正規化する — URL エンコーダーとデコーダーは、エンコード内容と正規形式と一致するかどうかを示すバリアントの検査に役立ちます。疑わしい分析の亜種については、デコードされた出力を検査するデコーダーに貼り付けます。 2 つの URL が同一の形式にデコードされる場合、それらは同一のページを表すため、統合する必要があります。このツールは、どの文字がエンコードされているか、その 16 進値、および結果を正確に表示します。この検査はトラブルシューティングの最初のステップです。
分析の不一致のトラブルシューティングを行う場合は、観察されたすべての URL バリアントのリストを作成し、URL エンコーダーとデコーダーを使用してそれぞれをデコードします。デコードされた形式を比較します。フォームのデータ内容が異なる場合 (utm_source 値が異なる場合など)、それらは正当に異なるページです。エンコードのみが異なる場合 (%65mail と電子メールなど)、正規化が必要な重複です。正規形式を文書化し、正規化を実装します。 URL エンコーダとデコーダが診断を提供します。分析パイプラインがソリューションを提供します。
要点: カウントする前に正規化する — URL エンコーダーとデコーダーがバリアントを検査して実際に何がエンコードされているかを確認するのにどのように役立つか
要点: カウントする前に正規化する — URL エンコーダーとデコーダーは、エンコード内容と正規形式と一致するかどうかを示すバリアントの検査に役立ちます。疑わしい分析の亜種については、デコードされた出力を検査するデコーダーに貼り付けます。 2 つの URL が同一の形式にデコードされる場合、それらは同一のページを表すため、統合する必要があります。このツールは、どの文字がエンコードされているか、その 16 進値、および結果を正確に表示します。
分析の不一致のトラブルシューティングを行う場合は、観察されたすべての URL バリアントのリストを作成し、URL エンコーダーとデコーダーを使用してそれぞれをデコードします。デコードされた形式を比較します。フォームのデータ内容が異なる場合 (utm_source 値が異なる場合など)、それらは正当に異なるページです。エンコードのみが異なる場合 (%65mail と電子メールなど)、正規化が必要な重複です。正規形式を文書化し、正規化を実装します。