PREMIUM Recommendations FAQ

Adobe Target Recommendations アクティビティに関するよくある質問(FAQ)のリストです。

数値を持つカスタム属性で検索すると、カタログ検索で正しい結果が表示されないのはなぜですか。

数値を持つカスタム属性に対してカタログ検索を実行すると、結果では、カスタム属性が数値ではなく文字列タイプとして処理されます。

現在、顧客によって属性のタイプを変更できる機能はありません。変更をおこなうには、顧客のイシューを開く、タイプを文字列から数値に変更する必要がある属性を参照します。

カタログの項目を更新してサイトに反映されるまで、どれくらいかかりますか?

期間と結果は、項目の更新方法によって異なります。

ソース 詳細
mboxまたはAPIで更新された項目属性
  • Recommendationsは15分以内に更新されます。
  • 既存のレコメンデーションと品目の属性は、更新が利用可能になるまで表示されます。
  • カタログ検索は、カタログインデックス(3 ~ 8時間)の後に更新されます。
フィードを介して更新された項目属性
  • フィードの取り込み後(2 ~ 8時間)、Recommendationsが更新されます。
  • 既存のレコメンデーションと品目の属性は、更新が利用可能になるまで表示されます。
  • フィードの取り込み(2 ~ 8時間)後、および後続のカタログインデックス(3 ~ 8時間)後に、カタログ検索が更新されます。 カタログ検索は、合計5 ~ 16時間以内に更新されます。
Target UIまたはAPIを介して項目がカタログから削除されました
  • Recommendationsは15分以内に更新されます。
  • 既存のレコメンデーションと品目の属性は、更新が利用可能になるまで表示されます。
  • カタログ検索は、カタログインデックス(3 ~ 8時間)の後に更新されます。
mboxまたはAPIを介してカタログに追加された項目
  • Recommendationsは、アルゴリズムの実行後に更新されます。 アルゴリズムの実行は、1 ~ 2日のアルゴリズムでは12時間ごとにスケジュールされ、7日以上のアルゴリズムでは24時間ごとにスケジュールされます。
  • 既存のレコメンデーションは、追加された品目がリクエストされたキーでない場合に更新が利用可能になるまで表示されます。
  • 代替レコメンデーションは、追加された品目がリクエストされたキーの場合に更新が利用可能になるまで表示されます。
  • カタログ検索は、カタログインデックス(3 ~ 8時間)の後に更新されます。
フィードを介してカタログに追加された項目
  • Recommendationsは、飼料が摂取された後(2 ~ 8時間)に更新されます。 以降のアルゴリズムの実行は、1 ~ 2日のアルゴリズムでは12時間ごとにスケジュールされ、7日以上のアルゴリズムでは24時間ごとにスケジュールされます。 Recommendationsは合計2 ~ 32時間以内に更新されます。
  • 既存のレコメンデーションは、追加された品目がリクエストされたキーでない場合に更新が利用可能になるまで表示されます。
  • 代替レコメンデーションは、追加された品目がリクエストされたキーの場合に更新が利用可能になるまで表示されます。
  • フィードの取り込み(2 ~ 8時間)後、およびカタログインデックス(3 ~ 8時間)後に、カタログ検索が更新されます。 カタログ検索は、合計5 ~ 16時間以内に更新されます。

フィードファイルの読み込み後、またはAPIまたはmboxを介してエンティティの更新を受け取った後、60分以内に次の変更が反映されます。

  • 以前に除外された品目が、現在は含まれる必要がある場合、品目は次のアルゴリズム実行時に含まれます(12 ~ 24時間)。

    この状況が発生するのは、Targetがオンラインとオフラインの両方で除外を適用するためです。 項目を新たに除外すると、オンラインでの除外はすばやく適用されます。 項目を新しく含めると、オンラインでの除外はすぐに消えますが、オフラインでの除外は次のアルゴリズムが実行されるまで消えません。

  • 以前に品目が含まれていたが、現在は除外する必要がある場合、「品目属性の更新」に従って品目が除外されます。 フィードソースに応じて上述のタイムライン(mbox/APIを使用した場合は15分、フィードを使用した場合は12 ~ 24時間)。

以下の変更は、次のアルゴリズムの実行が発生するまで反映されません(12 ~ 24 時間以内)。

  • アクティビティに使用される収集ルールで使用される項目属性。
  • アクティビティに関連付けられた属性またはコレクションに基づいたプロモーションで使用される項目属性。
  • トップセラーまたは最も多く閲覧されたアルゴリズムの「現在のカテゴリ」または「お気に入りのカテゴリ」に項目が表示される項目カテゴリ。
  • 変更された属性がアルゴリズムのカスタムキーとして使用されるカスタム属性である場合の、推奨項目のランキング。
  • レコメンデーションロジックが「類似属性のアイテム」で、「コンテンツの類似性」重み付け係数が使用されている場合、または「属性の重み付け」係数が使用されている場合の、変更された属性に基づいた推奨項目のランキング。
メモ

フィードファイルは、そのステータスが「項目の読み込み」から「検索インデックスの更新を準備中」に変更される際に読み込まれるとみなされます。更新がカタログ検索ユーザーインターフェイスに反映されるまで、60 分以上かかることがあります。フィードステータスが「更新完了」に変更されると、カタログ検索は最新の状態になります。カタログ検索が最新でなくても、サイトには上記の時間枠の更新が反映されます。 最新のカタログ検索インデックスの更新時間は、カタログ検索ページに表示されます。

Recommendationsのアクティビティ、オファー、プロモーション、条件の設定を変更してサイトに反映させるには、どのくらい時間がかかりますか。

  • プロモーション設定の変更がオンサイトに反映されるまでに最大5時間かかる場合があります。

  • 他の条件の設定に対する変更は、次のアルゴリズムが実行されるまで反映されない場合があります。

    • 一部の条件の設定(「動的なインクルージョンルールの追加」など)は、即座に反映されます。
    • その他の条件の設定(「動的な含めるルールの削除」、ルックバックウィンドウの変更など)は、次のアルゴリズムが実行されるまで組み込むことができません。
    • アルゴリズムの実行は、これらの変更によってトリガーされますが、完了するまでに最大24時間かかる場合があります。 アルゴリズムは、12 ~ 24時間ごとにスケジュール設定された状態で実行されます。

ユーザーの行動(製品Aをクリックし、製品Bを購入するなど)が​そのユーザーが受け取るレコメンデーションに反映されるまでに、どのくらい時間がかかりますか。

  • 現在閲覧、購入されている製品/コンテンツは、ユーザーが受け取るレコメンデーションに影響を与え、同じページビュー/Targetコンテンツリクエストに影響を与えます。
  • 「最後に閲覧された製品」、「最も多く閲覧された製品」、全体的な視聴/購入履歴などの過去のユーザー行動はこのリクエストで更新され、ユーザーが次のページビュー/Targetコンテンツリクエストで受け取るレコメンデーションに影響します。 例えば、「最近表示した品目」や「お勧めの品目」アルゴリズムは、商品の表示や購入ごとに更新され、以降のコンテンツリクエストに反映されます。

ユーザーの行動(製品Aのクリックや製品Bの購入など)がレコメンデーション​他の​ユーザーの受け取るレコメンデーションに反映されるまでに、どのくらい時間がかかりますか。

集計中のユーザの行動は、12 ~ 24時間ごとに実行されるアルゴリズムごとに、オフラインアルゴリズム処理に組み込まれる。

特殊文字によって配列が壊れてしまう場合はどうすればよいですか?

JavaScript のエスケープ値を使用してください。引用符(")を使用すると、配列が壊れる恐れがあります。エスケープ値を使用したコードスニペットの例を次に示します。

#set($String='') 
#set($escaper=$String.class.forName('org.apache.commons.lang.StringEscapeUtils')) 
<script type="text/javascript"> 
console.log("$escaper.escapeJavaScript($entity1.name)") 
console.log("$escaper.escapeJavaScript($entity2.name)") 
console.log('$escaper.escapeJavaScript($entity3.name)') 
names.push("$escaper.escapeJavaScript($entity4.name)") 
</script>

Recommendations アクティビティの作成時に、カスタム条件を含むすべての条件を選択できないのはなぜですか?

選択できる条件は現在のカテゴリに基づきます。レコメンデーションオファーを作成する際、アルゴリズムピッカーにはカテゴリ ID に基づいた条件が表示されます。

この条件を適用する場所にカテゴリ ID が含まれていない場合、一部の条件がアルゴリズムピッカーに表示されません。

mbox におけるカテゴリ ID の格納場所を使用する場合は、適用可能なすべての条件が条件ピッカーに表示されます。

Target には互換性のない条件をフィルタリング設定を使用して、アルゴリズムピッカーのインテリジェントフィルタリングを管理できます。

メモ

この設定は、Visual Experience Composer(VEC)で作成されたアクティビティのみに適用されます。この設定は、フォームベースのExperience Composerで作成されたアクティビティ(Targetに場所のコンテキストがない)には適用されません。

非互換の条件をフィルター設定にアクセスするには、Recommendations/設定をクリックします。

非互換の条件をフィルター設定が有効になっていない場合、 では、アルゴリズムピッカーに表示されるアルゴリズムのフィルタリングはおこなわれず、すべてのアルゴリズムが表示されます。Target

互換性のない条件をフィルター設定が有効な場合、VECアクティビティでTargetは、選択した場所からentityIdとカテゴリIDを読み取り、currentItem|currentCategoryに基づいてアルゴリズムを表示します(それぞれの値がその場所に存在する場合)。 そのためデフォルトでは、選択した場所で互換性のあるアルゴリズムのみがアルゴリズムピッカーに表示されます。

非互換の条件をフィルター設定が有効になっている場合でも、条件の選択時に「互換性あり」チェックボックスをオフにすると、互換性のないアルゴリズムを表示できます。

次のリストには、Targetが互換性チェックボックスを表示しない特殊な場合が含まれています。

  • entityId とカテゴリ ID の両方が場所に存在しており、フィルタリング対象がない。
  • mbox.js のバージョン 55 以前を使用している。
  • ページで mbox 呼び出しが実行されていない(!config.isAutoCreateGlobalMbox && !config.isRegionalMbox)。
  • Target パラメーターが定義されていません。

Recommendations のコレクションがゼロ(0)になった場合はどうすればよいですか?

以前はゼロではなかったコレクションがゼロになった場合の対処法は次のとおりです。

  • コレクションを再保存し、数値が更新されるかどうかを確認します。再保存すると、コレクションは、そのコレクションを使用するすべてのアルゴリズムを再実行します。

  • 適切な環境にいるか確認します。確認のため、/target/products.html#recsSettings に移動してください(以下を参照)。

  • インデックスが最新か確認します。/target/products.html#productSearchに移動し、何時間前にインデックスが作成されたかを確認します(例:「3 時間前にインデックス作成」)。必要に応じてインデックスを更新できます。

  • エンティティがコレクションのルールに一致しなくなる変更をフィードまたはデータレイヤーに加えていないか確認します。大文字と小文字が一致しているかチェックしてください(大文字と小文字は区別されます)。

  • フィードが適切に実行されているか確認します。FTP ディレクトリ、パスワードなどを変更したユーザーはいますか?

  • Target は、(顧客のページやアプリに)配信の更新をできる限り早く反映します。しかし、Targetは、マーケターのUIでも何らかの表現を提供する必要があります。 Target では、UI の更新が同期されるのを待つために、配信の更新を遅延させません。mboxTrace を使用すると、リクエスト受信時のシステムの状況を確認できます。

一般的な属性の重み付けと、コンテンツの類似性用の属性の重み付けには、どのような違いがありますか?

属性の重み付けには、「標準の属性の重み付け」と「コンテンツの類似性用の属性の重み付け」の 2 種類があります。

「標準の属性の重み付け」は、コンテンツの類似性を含むほぼすべての条件タイプに適用されます。このタイプの重み付けでは、特定の属性値により多くの重みが適用されます。次の例では、出力レコメンデーションで、Nike 製品の重みが大きくなります。

「コンテンツの類似性用の属性の重み付け」は、コンテンツの類似性の条件のみに適用されます。

このタイプの重み付けはより動的で、現在の「レコメンデーションキー」(現在表示されている品目)に基づきます。次の例(ブランド x 16)では、Nike のスニーカーを閲覧していた訪問者には、Nike の競合他社のスニーカーよりも、Nike の他の製品がレコメンデーションされる可能性が高くなります。Adidas のスニーカーを閲覧していた訪問者には、Adidas の製品がレコメンデーションされる可能性が高くなります。

Targetがレコメンデーションを表示できないことがあるのはなぜですか?

Target では、利用できるレコメンデーションが少ないことが原因で、レコメンデーションを表示できないことがあります。

条件ごとに生成される値の数は、デザインで指定したエンティティ数の 3 倍になります。ランタイムフィルタリング(在庫、mbox 属性のマッチングなど)が、3 倍の値が生成された後に適用されるので、値の数が提供時に 3 倍未満になることもあります。これを軽減するためには、他のエンティティを非表示にして、デザインのエンティティ数を増やします。

次の JavaScript は、デザインの始めで利用可能で、リクエストされるエンティティの数を増やすことができます。この例では、リクエストされたエンティティの数は 30(3 x 10)になります。

#foreach($entity in $entities) 
 #if( $foreach.count > 10 ) 
  #break 
 #end 
 #set ($foo = $entity.id) 
#end 

商品を挿入/更新する API の呼び出しのサイズ制限は何ですか?フィードではなく API を 1 回呼び出すことで、5 万件の商品の更新をおこなうことは可能ですか?

Target にはアプリケーションレベルで 50 MB の投稿制限があります。ただしこれは、application/x-www-form-urlencoded コンテンツタイプヘッダーを渡す場合のみです。

1 回の呼び出しで 5 万件の商品の送信を試みることは可能です。失敗した場合には、いくつかのバッチに分けてください。システム負荷によってタイムアウトとなってしまう可能性を減らすため、アドビでは、呼び出しを 5,000 または 10,000 製品バッチに分けることをお勧めします。

Recommendations の条件、プロモーション、またはテンプレートテストルールを作成する際に、mbox 名を指定する必要はありますか?

mbox パラメーターに基づいて Recommendations の条件、プロモーション、またはテンプレートテストルールを作成する際に、mboxParametermboxName の入力が求められなくなりました。mbox 名はオプションになりました。この変更により、複数の mbox のパラメーターを使用することや、まだエッジで記録されていないパラメーターを参照することができます。

目的のパラメーターを選択するには:

  • 条件、プロモーション、またはテンプレートのテストルールを作成する際に、リストからパラメーター名を選択します。目的のパラメーター名の最初の文字の入力を開始するか、目的のパラメーター名(フルネーム)を入力します。
  • mbox 名は覚えているが、パラメーター名は覚えていないという場合は、チェックボックスを使用して、目的のパラメーターを渡す既知の mbox に関してフィルタリングをおこないます。

いずれの方法でも、mbox とパラメーターの間にリンクはありません。条件、プロモーション、またはテンプレートのテストルールは、そのパラメータを渡すすべての mbox でパラメーターに基づいて機能します。

既存の条件、プロモーション、またはテンプレートテストルールを編集する場合は、作成時に指定された mbox 名と共にフィルタリング条件が表示されます。

新しいオーディエンスを定義した後に従来の Recommendations アクティビティを保存できないのはなぜですか?

オーディエンスに一意の名前が付けられていることを確認してください。オーディエンスに既存のオーディエンスと同じ名前を付けた場合、従来の Recommendations アクティビティ(2016 年 10 月より前に作成された Recommendations アクティビティ)を保存することはできません。

フィードのアップロードに使用する CSV ファイルのサイズ上限を教えてください。

フィードのアップロードに使用する CSV ファイルの行数とサイズに上限はありません。ただし、ベストプラクティスとして、アドビでは、ファイルのアップロード中にエラーが発生しないよう、CSV ファイルのサイズは 1 GB までに制限することをお勧めします。ファイルサイズが 1 GB を超える場合は、複数のフィードファイルに分割することをお勧めします。カスタム属性列の最大数は 100 で、カスタム属性は 4,096 文字までに制限されています。必要な列の長さに関するその他の制限は、Target の制限ページで確認できます。

エンティティを動的に除外することはできますか?

クエリ文字列で、レコメンデーションから除外したいエンティティのエンティティ ID を渡すことができます。例えば、既に買い物かごにある項目は除外した方がよいでしょう。

除外機能を有効にするには、excludedIds mbox パラメーターを使用します。このパラメーターは、コンマ区切りのエンティティ ID のリストを指定します。例: mboxCreate(..., "excludedIds=1,2,3,4,5")値は、レコメンデーションのリクエスト時に送信されます。

除外は、現在のTarget呼び出しに対してのみ実行されます。excludedIds値が再び渡されない限り、以降のTarget呼び出しで項目が除外されることはありません。 すべてのページのレコメンデーションから買い物かご内の項目を除外するには、引き続き各ページで excludedIds 値を渡します。

メモ

除外されるエンティティが多すぎる場合、レコメンデーションテンプレートを満たすのに十分なエンティティがないかのような動作になります。

entityIds を除外するには、オファーコンテンツの URL に &excludes=${mbox.excludedIds}トークンを追加します。コンテンツ URL が除外されると、必要なパラメーターが、現在の mbox リクエストパラメーターを使用して代用されます。

デフォルトでは、この機能は新しく作成されたレコメンデーションで有効になります。既存のレコメンデーションで、エンティティの動的な除外をサポートするには、保存する必要があります。

レコメンデーションのコンテンツトレースで返される NO_CONTENT 応答は何を意味しますか?

リクエストされたアルゴリズムとキーの組み合わせでレコメンデーションを使用できない場合、NO_CONTENT が返されます。一般的に、この状況は、アルゴリズムでバックアップが無効になっているのに加え、次の 1 つ以上が当てはまる場合に発生します。

  • 結果の準備がまだ整っていない。

    この状況は通常、新しく作成したアクティビティを最初に保存するとき、またはアクティビティで使用するコレクション、条件、プロモーションに設定の変更が加えられた後に発生します。

  • 結果の準備は整っているが、リクエストされたアルゴリズムとキーの組み合わせに対し、最も近いエッジサーバーではまだキャッシュされていない。

    リクエストがキャッシュ処理を開始するので、この問題は、数ページをリロードした後や、数分後に解決する必要があります。

  • 結果の準備は整っているが、指定されたキー値には使用できない。

    この状況は、通常、最新のアルゴリズムの実行にカタログに追加された項目のレコメンデーションをリクエストしたときに発生し、次のアルゴリズムの実行後に解決されます。

  • テンプレートの部分レンダリングが無効になっているため、テンプレートに入力するのに十分な結果が得られない。

    この状況は通常、考えられる結果から多くの項目を積極的にフィルタリングする動的なインクルージョンルールがある場合に発生します。状況を回避するには、バックアップを有効にしてインクルージョンルールをバックアップに適用しない、または積極的でないフィルタリング条件を使用して順次条件を使用します。

最近表示した品目に基づくレコメンデーションは、1つの訪問者に対して複数のデバイス間で保持されますか。

訪問者がセッションを開始すると、セッションIDは単一のエッジマシンに結び付けられ、一時的なプロファイルキャッシュがこのエッジマシンに格納されます。 同じセッションからの以降の要求は、最近表示したプロファイルを含む、このアイテムキャッシュを読み取ります。

セッションが終了した場合(通常、アクティビティがない状態で30分後に期限切れになる場合)、最近閲覧されたアイテムを含むプロファイル状態は、同じ地理的な端のより永続的なセッションストレージに維持されます。

新しいセッションが同じMarketing CloudID(MCID)、Experience CloudID(ECID)またはCustomerID/mbox3rdPartyIdを介して顧客プロファイルにリンクされている限り、異なるデバイスからの以降のセッションは、最近表示された品目にアクセスできます。

訪問者に2つのアクティブなセッションが同時に存在する場合、1台のデバイスで最近表示したアイテムは、他のデバイスで最近表示したアイテムを更新しません。ただし、そのデバイスでセッションIDを共有する必要があります。 この問題に対する回避策がある可能性がありますが、Targetは、複数のデバイス間でのセッションIDの共有を直接サポートしていません。 このID共有は、お客様が自分で管理する必要があります。

この動作は、あるデバイスで訪問者がアクティブになってから数分後に別のデバイスでアクティブになった場合にも発生します。 最初のデバイスのセッションは30分間有効期限が切れず、プロファイル状態が永続的な状態に書き込まれて処理されるまで、最大5分の遅延が発生する可能性があります。 この動作をテストする際に、セッションの有効期限が切れ、プロファイルが保存されるまで35分間待ちます。

訪問者に2つのアクティブなセッションが同時に存在しない場合、1つのデバイス上で最近表示されたアイテムは、セッションが終了している限り、他のデバイス上で最近表示されたアイテムを更新します。 この動作をテストする際に、セッションの有効期限が切れるまで35分間待ちます。

Recommendations PremiumのAdobe Recommendations Classicで作成したアルゴリズムを使用できますか。

Recommendations Classicで作成されたアルゴリズムは、Recommendations Premiumではサポートされていません。 Target Premiumでは、従来のアルゴリズムを使用できます。ただし、Target Premium UIでアクティビティを非アクティブ化または削除すると、アルゴリズムによって同期の問題が発生する場合があります。 2つのソリューションの違いについて詳しくは、 Target Premium🔗のRecommendations Classic versus Recommendations アクティビティを参照してください。

このページ