マーチャンダイジング eVar と製品検索方法

この詳細ドキュメントでは、マーチャンダイジング eVar の概念を説明します。マーチャンダイジング eVar は、標準 eVar とは異なる方法でデータを処理および配分します。また、マーチャンダイジング eVar と製品検索方法との関係についても説明します。

概要

マーチャンダイジング eVar を使用すると、訪問ごと／注文ごと ​レベルではなく​ 製品ごと ​のレベルで、eVar によって取り込まれた値に成功したアクティビティを配分できます。

ほとんどの小売 Web サイトでは、多くの方法で商品を見つけることができますが、アドビでは、すべての小売クライアントが Adobe Analytics で追跡する必要がある、基本的な製品検索方法は以下であると考えています。

このドキュメントでは、次のように、いくつかの eVar をソリューションにマッピングします。

追加の eVar を使用して、すべての製品検索方法のパフォーマンスを相互に測定できます。上記の検索方法に加えて、外部 Web サイトから製品の詳細ページへのリンクなど、比較対象となる他の検索方法も eVar に含まれます。

これらの変数を標準 eVar に設定する代わりに、マーチャンダイジング eVar に設定します。

これらの変数の設定方法を示すために、訪問者が内部キーワード検索「sandals」を使用してサイト上の製品を検索する例を以下に示します。キーワード検索結果ページでは、データを少なくとも 2 つの eVar に取り込む必要があります。

これらの 2 つの変数をこれらの値に設定すると、訪問者が製品を見つけるのに、「sandals」という内部キーワード検索語を使用していることがわかります。同時に、訪問者が商品を見つけるのに、他の製品検索方法を使用していないことがわかります（例えば、訪問者がキーワード検索を実行する際、同時に製品カテゴリを閲覧していない）。製品ごとの適切な配分を確実に実施するため、これらの使用されていない方法に対しては、内部キーワード検索で見つかった製品の検索に対するクレジットを付与しないでください。したがって、他の検索方法に関連付けられた eVar を自動的に「非検索方法」の値に設定するロジックをコード (AppMeasurement、Adobe Experience Platform Web SDK など ) に挿入する必要があります。

例えば、ユーザーが「sandals」というキーワードを使用して製品を検索する場合、Analytics コードのロジックでは、内部キーワード検索結果ページで変数を次のように設定する必要があります。

マーチャンダイジング eVar 設定

マーチャンダイジング eVar で使用できる設定は次のとおりです。レポートスイートマネージャーのスクリーンショットを次に示します。この設定にアクセスするには、Analytics／管理者／レポートスイート／設定を編集／コンバージョン／コンバージョン変数／新規追加／マーチャンダイジングを有効にするに移動します。

これらの設定について詳しくは、表の下のセクションを参照してください。

マーチャンダイジングを有効にする

「マーチャンダイジングを有効にする」設定が「有効」に設定されている場合、以下に説明するすべての設定がレポートスイートマネージャーに表示されます。「マーチャンダイジングを有効にする」設定を「無効」に設定した場合は、標準 eVar 設定のみを使用できます。

マーチャンダイジング

このオプションは、標準の eVar では使用できません。マーチャンダイジング設定を使用すると、マーチャンダイジング eVar の値の取り込み方法として、コンバージョン変数の構文または製品の構文を選択できます。

コンバージョン変数の構文 ​とは、ユーザーが独自の変数で eVar 値を設定したことを意味します。例えば、コンバージョン変数の構文を使用する場合、 eVar1 の値は、ページコード ( またはAppMeasurementコード、Adobe Experience Platform Web SDK コードなど ) 内で次のように設定されます。

s.eVar1="internal keyword search";

ただし、製品の構文 ​を使用すると、eVar は Adobe Analytics 製品変数内でのみ設定されます。Analytics の製品変数は、製品ごとに 6 つの異なる部分に分かれています。

s.products="[category];[name];[quantity];[revenue];[events];[eVars]"

製品の構文を使用するように設定されたマーチャンダイジング eVar は、products 変数の最後の部分内で設定されます。例えば、訪問者が内部キーワード検索を使用して製品 ID「12345」を見つけたとします。この例で eVar1 を設定する際、製品の構文に基づいた方法は、次のようになります。

s.products=";12345;;;;eVar1=internal keyword search";

products 変数の数量、売上高、イベント部分のセミコロン区切りのプレースホルダーが残っていることに注意してください。これらのプレースホルダーがないと、内部キーワード検索の eVar1 設定は完全に無視されます。

配分

特に、コンバージョン変数の構文を使用するマーチャンダイジング eVar では、マーチャンダイジング eVar に「配分」という用語を使用すると誤解を招きます。すべての標準 eVar に、独自の配分を設定できます。ただし、コンバージョン変数の構文を使用するマーチャンダイジング eVar では、レポートスイートマネージャーの配分設定に関係なく、「最新（最後）」の配分設定のみが使用されます。

この設定の意味を理解すると、eVar 配分とマーチャンダイジング eVar バインディングの違いを理解できます。マーチャンダイジング eVar の場合、この「配分」設定に適した名前は「マーチャンダイジング eVar バインディング」です。

標準 eVar 配分設定

標準構文の eVar がイメージリクエストから収集されるたびに、Adobe Analytics 処理サーバーは post_evar 列と呼ばれる別のデータベース列にデータを挿入します。eVar は永続的にする必要があるため、ほとんどの場合、現在のヒット以降のある時点で期限切れになります。その後、イメージリクエストのたびに、サーバーによってこの post_evar 列が設定されます。対応する eVar に渡された最後の値と同じになるよう設定されます。標準 eVar の場合、成功イベントが発生すると、Adobe Analytics では通常の eVar 列ではなく post_evar 列を使用して、イベントのクレジット付与対象となる eVar 値を決定します。

標準 eVar の場合、特定の期間に収集された最初の eVar 値と最後の eVar 値のどちらを post_evar 列に挿入するかは、配分設定によって決まります。標準 eVar の配分設定が「元の値（最初）」に設定されている場合、訪問者から収集された最初の eVar 値が、以降のすべてのイメージリクエストの post_evar 列に挿入されます。「有効期限」設定に従って eVar が期限切れになるまで、この訪問者のブラウザーから送信される今後のすべてのリクエストに対してこの処理が続行されます。

標準 eVar の配分設定が「最新（最後）」に設定されている場合、訪問者から収集された最新の eVar 値は、以降のすべてのイメージリクエストの post_evar 列に入力されます。「最新（最後）」の配分は、イメージリクエストで、対応する eVar が新しい値に設定されるたびに post_evar の値が変更されることを意味します。「元の値（最初）」の配分は、将来のイメージリクエストにおいて、対応する eVar が異なる値に設定されたとしても、ヒットをまたいで post_evar 列が変化しないことを意味します。

マーチャンダイジング eVar 配分（バインディング）設定

前述のように、コンバージョン変数構文を使用するすべてのマーチャンダイジング eVar には、「最新（最後）」のみが割り当てられています。したがって、訪問者が引き続きサイトを使用するので、マーチャンダイジング eVar の配分設定によって post_evar 列に挿入される値が決まるわけではありません。この設定は、製品にバインドされた eVar 値と、その成功イベントをバインドされた eVar 値に配分する方法を決定します。

マーチャンダイジング eVar の「配分」（つまり、バインディング）設定が「元の値（最初）」に設定されている場合、次のことが発生します。post_evar 列と共に設定され、以前に post_evar 列の対応する「前処理済み」eVar にバインドされていない製品は、post_evar 列に含まれる値にバインドされます。eVar 値と製品の間のこのバインディングは、eVar がレポートスイート設定の「有効期限」設定に従って期限切れになるまで変更されません。

イメージリクエストが、既にバインドされている製品を最新の設定 eVar 値にバインドする条件を満たす場合、「元の値（最初）」設定により、Adobe Analytics データ収集サーバーは、その後の試みを無視します。「配分（バインディング） 」設定が「最新（最後）」のマーチャンダイジング eVar では、逆のことが発生します。イメージリクエストが製品をマーチャンダイジング eVar にバインドする条件を満たすたびに、製品自体が、eVar に渡された最新の値、または post_evar 列に含まれる（常に）値にバインド（および再バインド）されます。

前述のように、マーチャンダイジング eVar では、成功イベントを、訪問ごと／注文ごとではなく、製品ごとの eVar 値に配分できます。したがって、バインドされた製品に成功イベント（買い物かごの追加や購入など）が関連付けられている場合、成功イベントは製品とその製品がバインドされているマーチャンダイジング eVar 値の両方にクレジットを与えます。

有効期限

マーチャンダイジング eVar の有効期限設定では、次の時期を選択できます。

eVar の有効期限は、成功イベントが記録された場合、または一定期間が経過した場合に発生する可能性があります。Adobe Analytics では、eVar ごとに 1 つの有効期限設定のみを使用できます。

製品の検索方法では、マーチャンダイジング eVar の有効期限を設定するベストプラクティスは次のとおりです。

どちらの設定でも、訪問者が購入する製品には、その製品がその時点でバインドされていたマーチャンダイジング eVar 値に割り当てられた注文／単位／売上高のクレジットが配分されます。

タイプ

eVar 型の設定は、データに挿入する eVar の種類を決定します。ほとんどの場合、この値は「テキスト」に等しい必要があります。マーチャンダイジング eVar に「カウンター」を使用することはまれです。ただし、「カウンター」は、製品ごとのカウンター eVar 値に成功を割り当てるために使用できます。「カウンター」タイプのソリューションに関する説明は、このドキュメントの範囲外です。

マーチャンダイジングバインディングイベント

「マーチャンダイジングバインディングイベント」設定を使用すると、製品をマーチャンダイジング eVar の値にバインドする条件を指定できます。これらの条件は、特定の成功イベントまたは eVar のみの実行に制限されます。実行するトラフィック変数（prop など）は、マーチャンダイジングバインディングには影響しません。

「マーチャンダイジングバインディングイベント」設定では、複数のイベントを使用して 1 つの製品を eVar 値にバインドできます。例：

デフォルトでは、この設定は、他のイベント／eVar（マーチャンダイジングまたは標準）が製品と同じイメージリクエストに含まれる場合は常に、製品をマーチャンダイジング eVar 値にバインドします。

リセット

「リセット」設定を使用すると、現在 Adobe Analytics のバックエンドのデータベースに post_evar 値がある、すべての訪問者のすべての eVar 値を直ちに「期限切れ」にできます。また、現在の製品と eVar のバインディングもすべて削除されます。

どの設定を使用する必要がありますか？

使用可能な設定の組み合わせの中から、どの設定が「ベストプラクティス」かわからない場合があります。

「internal keyword search」を製品 ID 12345 にバインドする場合、products 変数は次のように設定されます。

s.products=";12345;;;;eVar1=internal keyword search";

productID 12345 と同時に取り込まれた成功イベント（買い物かごへの追加、購入）に対するクレジットは、製品 ID 12345 と eVar1 値「内部キーワード検索」の両方に付与されます。製品 ID 12345 に関連付けられた成功イベントに対して、別の eVar1 値がクレジットを受け取る唯一の方法は、eVar1 が後で製品変数内の別の値（製品 ID 12345 と共に）に設定された場合です。

次に例を示します。

s.products=";12345;;;;eVar1=internal campaign";

この変数設定により、製品 ID 12345 のバインディングが eVar1 値「内部キーワード検索」から eVar1 値「内部キャンペーン」に変更されます。また、この再バインドの変更は、eVar が製品構文と「最新（最後）」の「配分（バインディング）」設定を使用するように設定されている場合にも発生します。「配分（バインディング）」設定が代わりに「元の値（最初）」に設定された場合、eVar1 を製品 ID 12345 と「内部キャンペーン」に設定しても、製品 ID 12345 を「内部キャンペーン」の eVar1 値に再バインドできません。その代わりに、元のバインド値（「内部キーワード検索」）でバインディングが維持されます。

製品の構文を使用する際の課題

慎重な計画を立てない場合、製品の構文を使用することで複数の問題が生じることがあります。複数の eVar を使用して Web サイト上の製品検索方法を追跡する場合を考えてみましょう。ここでは、特定の検索方法の eVar クレジット（および他の検索方法の eVar にクレジットがない）を付与するために、個々の製品検索方法 eVar を同時に設定する必要があります。製品の構文はこのようなシナリオで使用できますが、結果としてデプロイするコードはより複雑です。

元の「sandals」の例を使用し、製品の構文を使用するように適応する場合（訪問者が「sandals」というキーワード用語を使用して「sandal123」の ID を持つ製品を見つけた場合）、結果の products 変数を次のように設定する必要があります。

s.products=";sandal123;;;;eVar2=sandals|eVar1=internal search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";

この例では products 変数の構文は長くなりますが、表示された各 eVar 値が「sandal123」の製品 ID にバインドされます。それ以降は、「sandal123」製品と同時に取り込まれた成功イベント（買い物かごへの追加、購入など）が、最後に製品にバインドされた eVar 値にクレジットされます。このコードサンプルは、上記の eVar が「sandal123」製品にバインドされた後に、「sandal123」製品（79.95 ドル）の 1 個が購入されたかどうかを示します。

s.products=";sandal123;1;79.95";
s.events="purchase";

次の値には、すべて 1 個の注文 1 件、およびそれらに起因する売上高の 79.95 ドルが含まれます。

これは正しいアトリビューションで、問題ではありません。むしろ、このアプローチの主なジレンマは、製品検索方法 eVar の設定方法と設定タイミングを決定することです。

ほとんどの場合、製品検索方法 eVar は、その検索方法が実際に使用されたページ（キーワード検索結果ページ、参照ページ、内部キャンペーンランディングページなど）ではなく、製品の詳細ページで設定する必要があります。訪問者がある程度製品を操作するまで、製品が真に「見つからなかった」と想定するのは妥当です。したがって、複数の製品が（通常は）ページに表示されるので、これらの eVar（製品の構文を使用した）を検索方法ページに設定しないでください。検索方法の値を、訪問者がやり取りした製品のみにバインドします。

さらに、検索方法のページを表示している間、訪問者は、個々の製品の詳細ページに移動するリンクをクリックしたり、検索方法のページから直接買い物かごに個々の製品を追加した可能性があります。「sandals」検索キーワードの例を使用して、訪問者がキーワード検索結果ページから買い物かごに「sandal123」製品を直接追加した場合、買い物かごへの追加をキャプチャするコード（「買い物かごに追加」ボタンの onClick イベントなどを使用）は、買い物かごへの追加が発生した際に動的に生成されるか、ページコードまたはタグ管理システムを介して直接「ハードコード」される必要があります。そのような場合に実行するコードは、次のようになります。

s.linkTrackVars="products,events";
s.linkTrackEvents=s.events="scAdd";
s.products=";sandal123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";
s.tl(true,"o","Cart Add")

このコードは、上記の eVar 値を「sandal123」製品に適切にバインドします。ただし、クリックイベントの発生時にこれらの値を適切に設定するには、開発者は次の操作を行う必要があります。

また、訪問者が製品の詳細ページへのリンクをクリックして「検索」を決定した場合は、開発者は次の操作を行う必要があります。

製品の構文が役立つ場面

製品の構文は、次の場合でも役立ちます

例えば、多くの衣料品には「子 SKU」があり、サイズ、色、スタイルおよびその他の属性を示します。これらの属性は、同じ親製品に属する他の製品から 1 つの子製品を分離します。例えば、ミディアムサイズ、青色の T シャツにラージサイズ、赤色の T シャツを加えて購入するとします。両方のシャツの親 ID が「tshirt123」で、eVar10 が子 SKU を取り込むように設定されているとします。購入確認ページで設定される変数は次のように設定されます。

s.events="purchase";
s.products=";tshirt123;1;20;;eVar10=tshirt123-m-blue,;tshirt123;1;20;;eVar10=tshirt123-l-red";

この場合、「tshirt123-m-blue」と「tshirt123-l-red」の eVar10（childSKU）値の両方が、製品 ID「tshirt123」のそれぞれのインスタンスの購入に対して、クレジットを受け取ります。

「最新」の配分に関する課題

「最新（最後）」の「配分（バインディング）」設定を使用すると、追加の問題が発生する場合があります。多くの Web ブラウジングエクスペリエンスでは、訪問者は、既に閲覧した製品や買い物かごに追加した製品を「再検索」します。これは通常、その後の訪問の際か、購入を完了する直前に発生します。サイトを初めて訪問した際に、訪問者が「sandals」のキーワード検索で「sandal123」という製品を見つけたとします。訪問者はキーワード検索結果ページからすぐ、その製品を買い物かごに追加します。買い物かごへの追加をキャプチャするコードは、次のように設定されます。

s.linkTrackVars="products,events";
s.linkTrackEvents=s.events="scAdd";
s.products=";sandal123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross";

その結果、このイメージリクエストで表示される各 eVar 値が「sandal123」という製品にバインドされます。

次に、訪問者がこの訪問中に製品を購入せず、買い物かごに「sandals123」製品を入れたまま、3 日後にサイトに戻ったと仮定します。訪問者は、購入前に製品に関する詳細情報を入手したいと考えています。ただし、訪問者は、キーワード検索で製品を見つける代わりに、サイトを閲覧します。製品を「再検索」する直前に、「womens／shoes／sandals」マーチャンダイジング閲覧セクションに辿り着きます。「sandal123」製品の製品詳細ページを「再検索」すると、変数は次のように設定されます（ページ読み込み時）。

s.events="prodView";
s.products=";sandal123;;;;eVar4=womens > shoes > sandals|eVar1=browse|eVar3=non-internal campaign|eVar2=non-search|eVar5=non-cross-sell";

「配分（バインディング） 」設定が「最新（最後）」の場合、「sandal123」という製品は、元の eVar 値とはまったく異なるデータ値に再バインドされます。さらに、訪問者が「sandal123」の購入を完了すると、元々バインドされていた値ではなく、新しくバインドされた eVar 値に対してすべての購入クレジットが付与されます。

ここで問題になるのは、「購入に対するクレジットはどの eVar 値に割り当てられるべきか」です。訪問者が最初に、内部キーワード検索を使用して「sandal123」製品を見つけたことに注意してください。その後、検索結果ページから直接買い物かごに追加しました。したがって、eVar1 値「internal keyword search」（および eVar2 値「sandals」）に購入のクレジットを付与する必要があります。ただし、「配分（バインディング）」設定は「最新（最後）」になっています。したがって、eVar1 値「browse」（および eVar4 値「womens／shoes／sandals」の ）が代わりに購入クレジットを受け取ります。これらの値が、訪問者が購入を完了する前に「sandal123」にバインドされた最後の値であったためです。

この問題に対する解決策は、マーチャンダイジング eVar の「配分（バインディング）」設定を「最新（最後）」から「元の値（最初）」に変更することです。これにより、訪問者が製品を「再検索」した回数に関係なく、購入が発生すると、「sandal123」製品にバインドされた元の eVar 値に対してクレジットが付与されます。

訪問者が買い物かごに商品を追加しても購入しなかった場合、eVar の有効期限を使用すると、新しい検索方法の値を製品にバインドできます。eVar の有効期限は、製品が買い物かごに追加されてから、Web サイトによって製品が自動的に削除されるまでの期間と同じにする必要があります。

コンバージョン変数の構文の使用

「製品の構文」と「コンバージョン変数の構文」の質問に戻りましょう。アドビは、製品検索方法マーチャンダイジング eVar を収集し、訪問者が見つけた製品にその値をバインドする、より簡単な方法を発見しました。コンバージョン変数の構文を使用すれば、クライアントの開発者が担当する実装作業を減らすことができます。製品の構文と同じ、またはより優れた情報を提供します。開発者は、提供されたデプロイメント手順に従うだけで済み、残りのコードはAdobe AppMeasurement/Adobe Experience Platform Web SDK ファイルに配置できます。

例えば、内部キーワード検索のパフォーマンスを追跡するために推奨される解決策を見てみましょう。これは、キーワード検索結果ページで、コードが prop（prop4 など）と別の prop（prop5 など）を介して検索されたキーワードを取り込むことを意味します。これらの prop は、検索で表示された結果の数を追跡します。検索結果ページで Adobe Analytics イメージリクエストが生成されるたびに、開発者がデプロイしたデータレイヤーオブジェクト（またはページコード）を使用して、上記の変数（prop）が入力されました。

AppMeasurement/Adobe Experience Platform Web SDK ファイル内に含まれる追加のロジックによって、同時に設定する必要のある残りの変数（マーチャンダイジング eVar/ディメンション）を入力できます。
例えば、新しい訪問者が「sandals」というキーワード検索を行った場合、検索結果ページで 25 件の結果が返され、（ページコードまたはデータレイヤーキャプチャを介して）呼び出されるコードは次のようになります。

s.prop4="sandals";
s.prop5="25";

AppMeasurement／Analytics SDK ファイル内のロジックは、コードのこのスニペットを次のコードに自動変換できます。

s.prop4="sandals";
s.prop5="25";
s.eVar2="sandals";
s.eVar1="internal keyword search";
s.eVar3="non-internal campaign";
s.eVar4="non-browse";
s.eVar5="non-cross sell";

ページ間でデータを渡したり、products 変数に挿入する大きくて扱いにくい文字列を作成しようとする必要はありません。代わりに、開発者は、トラッキングソリューションの一部（prop に挿入されたもの）を実装し、残りの実装は Adobe コンサルティングから提供されたカスタムコードをそのまま使用できます。

前述したように、コンバージョン変数の構文を使用するすべてのマーチャンダイジング eVar の配分設定は「最新（最後）」になります。eVar が任意の値に設定されると、その値は（post_evar 列を介して）後続のすべてのヒットで保持されます。この値は、別の値に設定されるか、eVar の有効期限が切れるまで保持されます。したがって、eVar の設定後にやり取りされた製品が、それらの eVar にまだバインドされていない場合、その製品は eVar に渡される「最新（最後）」の値にバインドされます。

上記の例では、eVar2 値「sandals」とeVar1 値「internal keyword search」などは、キーワード検索の実行後に閲覧したすべてのページでも保持されます。これらは、eVar が他の値に上書きされるまで保持されます。訪問者がキーワード検索結果ページから、「sandal123」製品 ID の製品の詳細ページへのリンクをクリックしたとします。すると、「sandal123」製品 ID（まだバインドされていない場合）は、post_evar 列に含まれる各値、または前の（検索結果）ページで収集された eVar 値にバインドされます。

コンバージョン変数の構文では、再検討すべき点がもう一つあります。バインディングイベントは、製品に eVar 値をバインドするように設定する必要があります。Adobe Analytics イメージリクエストで、製品と（products 変数で）一緒に（独自の変数に）マーチャンダイジング eVar を設定するだけで、eVar 値が製品にバインドされるわけではありません。代わりに、レポートスイートマネージャーで指定される「マーチャンダイジングバインディングイベント」設定によって、eVar 値を製品にバインドする条件が決定します。

製品が「見つかった」ことを意味する製品のやり取りが発生した場合は常に、製品検索方法の eVar 値を製品にバインドする必要があります。そのため、「製品が見つかった」場合の最も一般的なやり取りは、製品の表示（訪問者が製品詳細ページへ移動した場合）または買い物かごへの追加（訪問者が製品検索方法ページから直接買い物かごに製品を追加した場合）の際に発生すると考えるのが安全です。

したがって、これら 2 つのイベント（prodView、scAdd）を「基本」マーチャンダイジングバインディングイベントとして選択できます。
これらのバインディングイベントのいずれかがイメージリクエスト内に含まれている場合、次の処理が行われます。同じリクエスト（製品変数内）に含まれ、マーチャンダイジング eVar にバインドされていない製品 ID は、マーチャンダイジング eVar（post_evar 列）に渡された最新の値にバインドされます。「配分（バインディング） 」設定が「元の値（最初）」に設定されている場合、この元のバインディングの後にこれらの製品を再バインドしようとしても無視されます。

ベストプラクティス設定

ベストプラクティスの設定は次のとおりです。最適な結果を得るために、製品検索方法を簡単に実装できます。アドビでは、クライアントが（一般に）各製品検索方法のマーチャンダイジング eVar を次のように設定することをお勧めします。

バインディングイベントの実際の動作

products 変数と同じサーバー呼び出しにバインディングイベントが含まれている場合、post 列のマーチャンダイジング eVar（コンバージョン変数の構文を使用）値が products 変数にバインドされます。前の例に基づいて、1 つのサーバー呼び出しに次のマーチャンダイジング eVar 値が含まれているとします。

s.eVar2="sandals";
s.eVar1="internal keyword search";
s.eVar3="non-internal campaign";
s.eVar4="non-browse";
s.eVar5="non-cross sell";

前述のように、上記の eVar は、それぞれの post_evar 列を介して現在のヒットの後も保持されます。したがって、アドビのサーバーは、上記の eVar を次のように変換します。

post_eVar2="sandals";
post_eVar1="internal keyword search";
post_eVar3="non-internal campaign";
post_eVar4="non-browse";
post_eVar5="non-cross sell";

これらの post 列はアドビのデータベースに保存され、最初に設定された現在のヒット以降も保持されます。これは、有効期限や変数のリセットが行われないことを前提としています。アドビのサーバーは、バインディングイベントと products 変数の両方を含む今後のサーバー呼び出しを処理する際に、これらの post_evar 値を「使用可能」にします。

バインディングは、これらの post_evar 値と products 変数の内容の間でのみ実行されます。バインディングイベントは、必ずしも eVar 変数または products 変数に「バインド」されるわけではありません。アドビサーバーに post_evar 値を製品にバインドするように指示するのは「catalyst」です。

将来のヒットで、次の変数が設定されるとします。

s.products=";sandals123"
s.events="prodView";

post_evar 列では、これらのヒットが次のようにアドビの処理サーバーに表示されます。

s.products=";sandals123";
s.events="prodView";
post_eVar2="sandals";
post_eVar1="internal keyword search";
post_eVar3="non-internal campaign";
post_eVar4="non-browse";
post_eVar5="non-cross sell";

eVar1、eVar2、eVar3、eVar4、eVar5 がバインディングイベントとして prodView を使用するように設定されているとします。これらの eVar のいずれかが prodView をバインディングイベントとして使用するように設定されていない場合、その（誤った設定の）eVar と products 変数のバインドは実行されません。

バインディングは、非常に興味深い結果を生み出し、post_products 列の値に表示されます。バインディングは、上記のコードを変換し、次のように、さらにいくつかの post 列を設定します。

post_events="prodView";
post_products=";sandals123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";

post_products 列に含まれる値は、見慣れたものである可能性があります。このドキュメントを上にスクロールして、以下に示すように、この post_products 値と s.products 値を比較します。post_products 列は製品変数の構文を使用して設定されています。

つまり、バインディングでは、コンバージョン変数の構文 eVar 値を製品の構文を使用して products 変数に「コピー」します。このコピーアクションは、products 変数と（eVar 設定を介して設定された）バインディングイベントが同じリクエストに含まれている場合にのみ実行されます。その時点で、post_eVar 列に含まれる値が製品にバインドされます。このバインディングは、post_products 列に格納された製品の構文で表されます。

マーチャンダイジング eVar、インスタンス指標およびアトリビューション

標準 eVar が Analytics サーバーコールで送信されると、その post_evar 列の値には常に、その標準データに属するインスタンスが取得されます。インスタンスは、イメージリクエスト内の特定の値に等しく eVar が設定された回数を表します。

例えば、eVar10 がラストタッチアトリビューションを持つ標準 eVar であるとします。任意のページで s.eVar10="hello world" を設定した場合、アドビがヒットを処理する際に、「hello world」の値が post_evar10 列に渡されます。インスタンス指標は、hello world の個々の eVar10 設定の「1」に等しくなります。post_evar 列に値が含まれる場合、インスタンスが記録されない場合があることに注意してください。代わりに、インスタンスの記録時にインスタンスを取得する値は post_evar 列で決まります。

マーチャンダイジング eVar のインスタンスは、eVar が収集する値にアトリビューションを与えます。ただし、これは、マーチャンダイジング eVar 値に結び付けられた製品が同時に「インタラクション」された場合にのみ発生します。

例えば、s.eVar1="Internal Keyword Search" を単独で設定しても、eVar1 値「内部キーワード検索」にインスタンス指標のクレジットは与えられません。インスタンスは、その時点で記録されます。ただし、eVar1 が設定されると同時に製品がその「内部キーワード検索」値にバインドされない限り、インスタンスは「未指定」バケットに関連付けられます。つまり、eVar1 値「内部キーワード検索」はインスタンスを取得できます。ただし、これは、同じイメージリクエストの製品変数で「内部キーワード検索」の値にバインドされている製品が表示された場合にのみ発生します。

要約すると、追加の設定を行わない限り、マーチャンダイジング eVar の標準インスタンス指標はあまり役に立ちません。幸いにも、Adobeはリリース 帰属. Adobe Analytics が収集するカスタマイズされた指標に対して、複数のアトリビューションモデルを適用できます。これらのアトリビューションモデルを適用する指標では、post_evar 列に含まれる値や、特定の製品にバインドされている値は使用されません。代わりに、これらの指標は、イメージリクエスト自体（または Adobe Analytics の処理ルールで取り込まれた値）を経由して渡された値のみを使用します。アトリビューションの機能を使用すると、コンバージョン変数構文を使用するすべてのマーチャンダイジング eVar について、正確にアトリビュートされたインスタンス指標を取得できます。

マーチャンダイジングeVarのインスタンス指標をレポートに追加する場合、適切なアトリビューションモデルは「ラストタッチ」モデルになります。 この場合、モデルのルックバックウィンドウ設定は重要ではありません。理由は、「強制」ラストタッチアトリビューションモデルは、リクエストを介して渡される各個々の値にインスタンスのクレジットを常に与えるからです。これは、eVar の実際のアトリビューション／バインディング設定が「最新（最後）」から「元の値（最初）」に等しいかどうかに関係しません。