[レガシー]{class="badge informative"}

オファーへの制約の追加 add-constraints

制約を使用すると、オファーを表示する条件を定義できます。

  1. オファー実施要件 ​を設定します。詳細情報

  2. ユーザーが複数のオファーの対象となる場合は、他のオファーと比較したオファーの「優先度」を定義します。オファーの優先度が高いほど、他のオファーと比較して優先順位が高くなります。

    note note
    NOTE
    オファーの優先度は、整数値(小数は含まない)にする必要があります。
  3. オファーの​ キャップ ​を指定します。キャップはオファーが表示される回数を意味します。詳細情報

  4. 次へ」をクリックし、定義したすべての制約を確定します。

例えば、次の制約を設定した場合:

  • オファーは、「ゴールドロイヤルティ顧客」決定ルールに一致するユーザーに対してのみ考慮されます。
  • オファーの優先度は「50」に設定されています。つまり、このオファーは優先度が 1~49 のオファーより先に、優先度が 51 以上のオファーより後に表示されます。
  • オファーは、すべてのプレースメントをまたいで、ユーザーごとに月に 1 回だけ提示されます。

実施要件 eligibility

オファーの実施要件」セクションでは、オーディエンスまたは決定ルールを使用して定義する特定のプロファイルにオファーを制限できます。

NOTE
オーディエンス ​と​ 決定ルール ​の使用上の違いについて詳しくは、この節を参照してください。
  • デフォルトでは、「すべての訪問者」オプションが選択されています。つまり、すべてのプロファイルがオファーを提示される資格があります。

  • また、オファーの表示を、1 つまたは複数の Adobe Experience Platform オーディエンスのメンバーに限定できます。

    それには、「1 つまたは複数のオーディエンスに分類される訪問者」オプションを有効にしたあと、左パネルから 1 つまたは複数のオーディエンスを追加し、かつまたは ​論理演算子を使用してそれらを結合します。

  • 特定の決定ルールをオファーに関連付ける場合は、定義済みの決定ルール ​を選択し、目的のルールを左ペインから​ 決定ルール ​領域にドラッグします。

    note caution
    CAUTION
    イベントベースのオファーは、現在 Journey Optimizer ではサポートされていません。イベントに基づいて決定ルールを作成しても、それをオファーで活用することはできません。

オーディエンスまたは決定ルールを選択すると、推定される認定プロファイルに関する情報が表示されます。「更新」をクリックして、データを更新します。

NOTE
プロファイルの予測は、ルールパラメーターにコンテキストデータなど、プロファイルに含まれていないデータが含まれている場合は使用できません。例えば、現在の気温が 80 ℃以上であることを条件とする実施要件ルールがあります。

オーディエンスと決定ルールの使用上の違い segments-vs-decision-rules

制約を適用するには、オファーの選択を 1 つまたは複数の Adobe Experience Platform オーディエンス ​のメンバーに限定するか、決定ルール ​を使用します。どちらの手段もそれぞれ異なる使用法に対応します。

基本的に、オーディエンスの出力はプロファイルのリストです。一方、決定ルールは、決定プロセス中に単一プロファイルに対してオンデマンドで実行される関数です。この 2 つの使用法の違いを、以下に詳しく説明します。

  • オーディエンス

    オーディエンスは、プロファイル属性とエクスペリエンスイベントに基づく特定のロジックに一致する Adobe Experience Platform プロファイルのグループです。ただし、オファー管理ではオーディエンスの再計算は行われないので、オファーを提示する際にオーディエンスが最新でない可能性があります。

    オーディエンスについて詳しくは、この節を参照してください。

  • 決定ルール

    一方、決定ルールは、Adobe Experience Platform で使用可能なデータに基づいており、オファーを誰に表示できるかを決定します。特定のプレースメントのオファーまたは決定でルールが選択されると、決定が行われるたびにそのルールが実行されるので、各プロファイルが最新かつ最適なオファーを確実に取得できます。

    決定ルールについて詳しくは、この節を参照してください。

キャップ capping

キャップは、オファーを提示できる最大回数を定義する制約として使用されます。ユーザーが特定のオファーを受け取る回数を制限することで、顧客への過度の勧誘を防ぎ、最適なオファーを用いて各タッチポイントを最適化できます。

特定のオファーに対して最大 10 個のキャップルールを追加できます。キャップルールを設定するには、「キャップを作成」ボタンをクリックし、次の手順に従います。

CAUTION
以前に作成したオファーのフリークエンシーキャップを有効または無効にすることはできません。これを行うには、新しいオファーを作成する必要があります。
  1. カウンターを増やすために、どの​ キャップイベント ​を考慮するかを定義します。詳細情報

  2. キャップをすべてのユーザーに適用するか、1 つのプロファイルのみに適用するかを選択します。詳細情報

  3. オファーを提示できる回数を設定します。詳細情報

  4. 頻度」を設定して、キャップカウントをリセットする頻度を定義します。 詳細情報

  5. オファーの複数の表示域を定義した場合、キャップを「すべてのプレースメントで」または「プレースメントごとに」適用するかどうかを指定します。詳細情報

  6. 保存および承認されると、定義した条件および期間に従って、このフィールドに指定した回数のオファーが提示された場合、配信は停止されます。

メモ:オファーの提案回数はメールの準備時に計算されます。例えば、ある数のオファーを含むメールを準備すると、メールが送信されたかどうかに関係なく、オファーの数は最大キャップにカウントされます。

NOTE
キャップカウンターは、オファーの有効期限切れ、またはオファーの開始日から 2 年後の、いずれか早い方でリセットされます。オファーの日付を定義する方法については、この節を参照してください。

キャップイベント capping-event

キャップイベントを選択」フィールドでは、カウンターを増やすためにどのイベントを考慮するかを定義できます。

  • 決定イベント(デフォルト値):1 つのオファーを提示できる最大回数。

  • クリック数:ユーザーがオファーをクリックできる最大回数。

  • インプレッション:1 人のユーザーに対してオファーを表示できる最大回数。

    note note
    NOTE
    インプレッションをキャップイベントとして使用できるのは、インバウンドチャネル ​のみです。
  • カスタムイベント:送信されるオファーの数のキャップに使用するカスタムイベントを定義できます。例えば、引き換え回数が 10,000 になるまで、または特定のプロファイルが 1 回引き換えられるまでに引き換え回数をキャップできます。これを行うには、Adobe Experience Platform XDM スキーマを使用してカスタムイベントルールを作成します。

    次の例では、チェックアウト数をキャップします。

    1. リストから​ カスタムイベント ​を選択し、「カスタムイベントを追加」ボタンを使用します。

    2. カスタムイベントルールを作成 ​ビルダーを使用して、関連イベントを選択します。 オファーをキャップするユーザーアクションを選択できます。

      Commerceチェックアウト ​を選択し、ドロップダウンリストから「存在する」を選択します。

    3. ルールが作成されると、カスタムイベントクエリ ​フィールドに表示されます。

CAUTION
決定イベントを除くすべてのキャップイベントでは、意思決定管理のフィードバックが自動的に収集されず、結果としてキャップカウンターの値が正しくカウントされない可能性があります。詳細情報
キャップカウンターで各キャップイベントを確実に追跡して反映させるには、エクスペリエンスイベントの収集に使用するスキーマに、そのイベントの正しいフィールドグループが含まれていることを確認します。詳細情報

キャップのタイプ capping-type

キャップを適用する対象を、すべてのユーザー、または 1 つの特定のプロファイルに指定することもできます。

  • 合計 ​を選択し、組み合わせたターゲットオーディエンス(つまり、すべてのユーザー)に対してオファーを提案できる回数を定義します。

    例えば、「超特価品 TV」を販売する電子機器小売業者の場合、オファーが返される回数は、すべてのプロファイルで 200 回に制限されます。

  • プロファイルごと ​を選択して、1 つのオファーを同じユーザーに対して提案できる回数を定義できます。

    例えば、「プラチナクレジットカード」のオファーを持つ銀行の場合、このオファーを 1 つのプロファイルにつき 5 回以上表示したくないとします。実際、ユーザーがオファーを 5 回見て、それに対して何らかのアクションを起こしていない場合、その次に最適なオファーに対して行動する可能性が高いと考えられます。

キャップカウント capping-count

キャップカウントキャップ」フィールドでは、オファーを提示できる回数を指定できます。

NOTE
数値は 0 より大きい整数にする必要があります。

例えば、チェックアウト数が考慮されるなどのカスタムキャップイベントを定義したとします。 「キャップカウントキャップ」フィールドに「10」と入力すると、10 件を超えたチェックアウトは送信されなくなります。

フリークエンシーキャップ frequency-capping

キャップ頻度をリセット」セクションでは、キャップカウントをリセットする頻度を定義できます。これを行うには、カウントの期間(毎日、毎週、毎月)を定義し、選択した日/週/月の数を入力します。例えば、キャップカウントを 2 週間ごとにリセットする場合は、対応するドロップダウンリストから「毎週」を選択し、他のフィールドに「2」と入力します。

  • フリークエンシーキャップカウンターのリセットは、定義した日(UTC で午前 12 時)、または該当する場合は週や月の最初の日に発生します。週の開始日は​ 日曜日 ​です。選択する期間は、2 年(つまり、それに相当する月数、週数、日数)を超えることはできません。

  • オファーを公開した後は、頻度に選択した期間(毎月、毎週、毎日)を変更できなくなります。オファーのステータスが​ ドラフト ​で、これまでにフリークエンシーキャップを有効にして公開したことがない場合であれば、フリークエンシーキャップを編集できます。

  • オファーが承認された際や、キャッピングが作成された際(いずれかが最後に発生した際)に、イベントがフリークエンシーキャップ制約にカウントされるまでに最大 15 分のバッファー時間が発生する場合があります。

必読:Frequency capping API と Decision management API

フリークエンシーキャップカウンターは 3 秒以内に更新され、Edge Decisioning API の決定で使用できます。

各ハブ地域は、1 つ以上のエッジリージョンに関連付けられています。フリークエンシーキャップルールが生成され、各ハブリージョンから関連するエッジリージョンにエクスポートされます。Edge Decisioning API を使用して決定が行われるたびに、システムは同じエッジリージョンで使用可能なルールを適用します。

  • 一致ルールがある場合、プロファイルのフリークエンシーキャップカウンターが増分されます。
  • そうしない場合、プロファイルにカウンターが作成されず、フリークエンシーキャップルールが適用されません。その結果、キャップしきい値を超えた場合でも、プロファイルは引き続きパーソナライズされたオファーを受け取ります。

例えば、組織のハブリージョンが NLD2 で、ヨーロッパ(IRL1 エッジリージョン)から決定リクエストを送信しているとします。このシナリオでは、ルールが(アイルランド)IRL1 リージョンで使用可能なので、決定リクエストによってプロファイルのカウンターが増分されます。ただし、決定リクエストが(オランダ)NLD2 ハブリージョンに関連付けられたエッジリージョンではなく、日本(JPN3)などのリージョンから発信された場合、カウンターは作成されず、フリークエンシーキャップルールは適用されません。

note note
NOTE
カウンターがエッジからハブに、またはハブからエッジ領域に伝播される場合、最大 30 分の遅延が適用される場合があります。

組織に関連付けられているハブとエッジのリージョンについて詳しくは、アドビ担当者にお問い合わせください。

他の API では、フリークエンシーキャップカウンターは次のように更新されます。

  • Decisioning API の決定では、トラフィックに応じて、フリークエンシーキャップカウンターが数分遅れて更新される場合があります。

  • Batch Decisioning API の決定では、フリークエンシーキャップカウンターが固定されたままのスナップショットが使用されます。同じスナップショットを使用する限り、カウンターは変更されません。

キャップと配置 placements

オファーの複数の表示域を定義した場合、キャップを「すべてのプレースメントで」または「プレースメントごとに」適用するかどうかを指定します。

  • すべてのプレースメントでキャップを適用:キャップ数は、オファーに関連付けられたプレースメント全体のすべての決定の合計となります。

    例えば、オファーに​ 電子メール ​プレースメントと web プレースメントがあり、すべてのプレースメントのプロファイルあたりキャップを 2 に設定した場合、各プロファイルは、プレースメントミックスに関係なく、合計で最大 2 回オファーを受け取ることができます。

  • プレースメントごとにキャップを適用:キャップ数は、各プレースメントに対して個別に決定回数が適用されます。

    例えば、オファーに​ メール ​プレースメントと web プレースメントがあり、各プレースメントに対するプロファイルあたりのキャップを 2 に設定した場合、各プロファイルは、メールプレースメントに対して最大 2 回、web プレースメントに対してさらに 2 回、オファーを受け取ることができます。

キャップに対する日付変更の影響 capping-change-date

オファーの日付を変更する場合は、次の条件を満たすとキャップに影響を与える可能性があるので、慎重に行う必要があります。

  • オファーが承認済み
  • キャップが既にオファーに適用済み。
  • キャップがプロファイルごとに定義されている。
NOTE
オファーの日付を定義する方法については、この節を参照してください。

プロファイルごとのキャップでは、各プロファイルにキャップ回数が保存されます。承認されたオファーの開始日と終了日を変更すると、以下に説明する様々なシナリオに従って、一部のプロファイルのキャップカウントが影響を受ける可能性があります。

以下は、オファー開始日を変更 ​した場合に考えられるシナリオです。

シナリオ:
次の場合…
結果:
次に…
キャップカウントに対する影響の可能性
…オファーの開始日が、元のオファーの開始日が開始する前に更新される
…キャップカウントは新しい開始日に開始される。
×
…新しい開始日が現在の終了日より前
…キャップは新しい開始日から続行し、各プロファイルの以前のキャップ数が繰り越される。
×
…新しい開始日が現在の終了日より後
…現在のキャップは期限切れになり、新しい開始日にすべてのプロファイルに対して新しいキャップ数が 0 から再び開始される。

以下は、オファー終了日を延長 ​した場合に考えられるシナリオです。

シナリオ:
次の場合…
結果:
次に…
キャップカウントに対する影響の可能性
…元のオファーの終了日より前に決定リクエストが発生
…キャップ数が更新され、各プロファイルの以前のキャップ数が繰り越される。
×
…元の終了日より前に決定リクエストが発生していない
…キャップ回数は、各プロファイルの元の終了日にリセットされる。元の終了日の後に発生する新しい決定リクエストに対しては、新しいキャップ数が 0 から再び開始されます。

元の開始日が 1月1日、有効期限が 1月31日 ​に設定されたオファーがあるとします。

  1. プロファイル X、Y、Z がオファーに表示されます。

  2. 1月10日 ​に、オファーの終了日が 2月15日 ​に変更されました。

  3. 1月11日から 1月31日 ​の間、プロファイル Z のみがオファーに表示されます。

    • 決定リクエストが​ プロファイル Z の ​元の終了日より前に発生したため、オファーの終了日は 2月15日 ​に延長されます。
    • ただし、プロファイル X と Y では、元の終了日より前のアクティビティが発生していないため、カウンターは期限切れになり、キャップカウントは 1月31日 ​に 0 にリセットされます。

recommendation-more-help
b22c9c5d-9208-48f4-b874-1cefb8df4d76