ハッシュの競合

値が数値であっても、prop および eVar 値を文字列として扱います。これらの文字列が数百文字の長さになることもありますが、その他の場合は短くなります。スペースを節約し、パフォーマンスを向上させ、すべてを均一のサイズにするために、文字列は、処理で直接使用されません。代わりに、各値に 32 ビットまたは 64 ビットのハッシュが計算されます。すべてのレポートは、これらのハッシュ値に対して実行され、各ハッシュが元のテキストに置き換えられます。ハッシュを使用すると、Analytics レポートのパフォーマンスが大幅に向上します。

ほとんどのフィールドでは、文字列が最初にすべて小文字に変換されます（一意の値の数を削減）。値は、月ごとにハッシュ化されます（最初は毎月表示されます）。月ごとに、2 つの一意の変数値がハッシュ化されて同じ値になる可能性がわずかにあります。この概念は、ハッシュの競合​として知られています。

ハッシュの競合は、次のようにしてレポートで示されます。

• 値のトレンドを確認していてある月にスパイクがある場合、その変数の別の値がハッシュ化されて、検討している値と同じ値になっている可能性があります。
• 特定の値のセグメントについても同じことが起こります。

ハッシュの競合の例

ハッシュの競合の可能性は、ディメンションの一意の値の数と共に増加します。例えば、月の下旬に入ってきた値の 1 つは、月の初めの値と同じハッシュ値になる可能性があります。次の例で、いかにしてこれがセグメント結果を変更することにつながるかということを説明します。eVar62 が、2 月 18 日に "値 100" を受け取るとします。Analytics は、テーブルを次のように維持します。

eVar62="値 500" である訪問者を探すセグメントを作成すると、Analytics は "値 500" がハッシュを含んでいるかどうかを判断します。"値 500" は存在しないので、Analytics は訪問数 0 を返します。次に、2 月 23 日に、eVar62 が "値 500" を受け取り、そのハッシュも 123 になります。テーブルは、次のようになります。

同じセグメントが再び実行されると、"値 500" のハッシュを探し、123 を見つけて、レポートはハッシュ 123 を含むすべての訪問数を返します。ここで、2 月 18 日に発生した訪問数が、この結果に含まれます。

この状況は、Analytics を使用する際に問題を生み出す可能性があります。アドビでは、引き続き、将来のハッシュの競合の可能性を低減する方法を調査します。変数間で一意の値を分散させる方法を見つけたり、処理ルールで不要な値を削除したり、変数ごとの値の数を減らしたりすることで、この状況を避けることができます。