【第366回】Personalization：Personalization の基本的な仕組み
Salesforce Personalization は、Data 360 の顧客情報・行動データ・商品情報を使い、顧客に応じたコンテンツやおすすめ商品を選ぶ仕組みです。
Marketing Cloud Next と連携したメールのパーソナライズに加え、Web サイトやモバイルアプリなど、複数のチャネルで活用できます。
すべての出し分けに AI の学習が必要なわけではありません。条件に応じてバナーを選ぶ方法、価格や売上などの基準で商品を並べる方法、機械学習でビジネス目標に合う商品を選ぶ方法があります。
この記事では、Data 360 を基盤とする Salesforce Personalization を説明します。Marketing Cloud Personalization とは異なります。
Personalization 基礎シリーズ
Sitemap Builder シリーズ
Data 360 設定シリーズ
Personalization 設定シリーズ
データ・選択・表示の役割を分ける
Salesforce Personalization を理解するには、次の 3 つに分けて考えると分かりやすくなります。
データを用意する：Data 360 に顧客情報、行動、商品情報を取り込み、Data Graph から参照できるようにする
返す内容を選ぶ：Personalization Point と Decision を使い、対象顧客と返すコンテンツを決める。商品選択には Recommender を使う
画面に表示する：Web では Experience Template と Web Personalization Manager（WPM）、または独自の API 実装などを使う
例えば、商品閲覧・カート追加・購入からカテゴリへの興味を数値化し、その顧客が最も興味を持つカテゴリのバナーや商品を表示できます。
Profile Data Graph と Item Data Graph
Profile Data Graph：顧客の属性、関連する行動、Calculated Insight など、顧客側の情報を参照する
Item Data Graph：商品や記事など、おすすめ対象の情報を参照する
「誰におすすめするか」と「何をおすすめするか」で、参照するデータの役割が異なります。
Recommender の仕組み
Recommender は、商品や記事などの候補から、おすすめとして返すアイテムを選ぶ設定です。
基本となる選択方法には、目的ベースとルールベースがあります。
① 目的ベースの Recommender
Objective-Based Recommendations は、ディープラーニングのモデルを使い、指定したビジネス目標に沿うように、顧客ごとのおすすめを生成します。
現在の公式ヘルプでは、次の 3 種類の定義済み目的が案内されています。
Maximize Revenue：購入頻度や購入金額の増加を目指す
Maximize Revenue with Promotions：購入や収益の増加につながるプロモーションをおすすめする
Maximize Clicks：記事へのクリック増加を目指す
目的に応じて、Profile Data Graph と Item Data Graph に必要な DMO・項目を含めます。名前を選択するだけで、学習に必要なデータが自動的にそろうわけではありません。
カスタム目的を作成する
定義済みの目的に加え、自社の目標に合わせたカスタム目的を作成できます。
例えば、商品をカートに追加する行動を増やしたい場合は、その行動を表す Engagement Signal と、行動を数える Metric を用意します。
基本的な設定の流れは、次のとおりです。
対象の行動を表す Engagement Signal を用意する
行動を測定する Engagement Signal Metric を用意する
カスタム目的で Maximize／Minimize を選ぶ
目的の評価に使う Metric を指定する
必要に応じて、学習に使う追加の Engagement Signal を指定する
選択できるシグナルやメトリクスは、Data Graph に含まれるデータと設定に依存します。単に「購入を増やす」と入力するだけではなく、何をもって成果とするかをデータで定義します。
Recommender の処理状況を確認する
Recommender を保存したら、Latest Refresh Status と Last Successful Refresh を確認します。
公式ヘルプでは、ルールベースと、有効な目的ベースの Recommender の更新が 24 時間ごとに行われると説明されています。少なくとも 1 回、更新が正常に完了していることを確認してから利用します。
顧客の行動や Affinity の更新と、Recommender の学習・更新は別の処理です。 リアルタイムの顧客情報を利用できることと、機械学習モデルが行動のたびに学習し直すことは、同じ意味ではありません。
② ルールベースの Recommender
Rule-Based Recommendations は、指定したデータ項目や Calculated Insight を使い、決めた基準でおすすめを選びます。
商品の価格が安い順
売上や販売数量が多い順
閲覧数が多い順
顧客が最近閲覧した商品
価格などの Item Data Graph の直接属性 も使用できます。「数学的計算」や「Calculated Insight」だけに限定されるものではありません。
また、ルールベースでも、顧客ごとに違うおすすめを返せます。
例えば、顧客の最も興味が強いカテゴリを取得し、そのカテゴリの商品だけに絞り込んだうえで、価格の昇順に並べる構成です。
この場合、顧客ごとに変わるのは対象カテゴリで、カテゴリ内の商品の順番は価格によって決まります。AI が購入確率を予測して並べているわけではありません。
おすすめ候補を Filter で絞り込む
Filter は、候補に含めるアイテムや、除外するアイテムを指定する設定です。並び順とは別に、「どの商品を候補にするか」を制御します。
基本となる Filter Type は、次の 3 種類です。
① Static
価格、カテゴリ、公開日などを指定して絞り込みます。
特定カテゴリの商品だけを含める
一定価格以下の商品だけを含める
Static でも、固定値の代わりに Dynamic Context Variable を指定できます。
例えば Value に {!Top_Category} を設定すると、リクエストで渡された Top_Category を条件の値として使用します。
変数名を設定するだけで、顧客の Affinity が自動取得されるわけではありません。今回の TrailNest の構成では、最高カテゴリを取得する処理と、その値をリクエストへ渡す処理を別途用意しました。
動的変数をリクエストに渡さない場合、その変数を使う Filter は破棄されるため、意図した絞り込みになっているか確認します。
② Decision Context
現在閲覧しているアイテムを基準に絞り込みます。
閲覧中の商品と同じカテゴリの商品を選ぶ
閲覧中の記事と同じ著者の記事を選ぶ
この方法では、比較の基準になるアイテムや属性を設定します。
③ Profile Data Graph
顧客側の情報や履歴を使い、候補を絞り込みます。
購入済みの商品を除外する
顧客の条件に合う商品だけを含める
必要な属性、関連データ、Calculated Insight を Profile Data Graph から参照できるようにします。「過去 30 日以内」などの期間条件も、参照データやインサイトの設定に合わせて定義します。
Fallback Recommender
メインの Recommender が十分な件数を返せない場合、不足分を補うための予備の Recommender を指定できます。
例えば、4 商品を表示したいのに、対象カテゴリの商品が2件しか返らない場合、残りを予備の Recommender で補う構成です。
候補の絞り込みを検証する段階では、Fallback を無効にして、メインの結果だけを確認する方法もあります。
Personalization Point と Decision の役割
Personalization Point
Personalization Point は、アプリや Web サイトがパーソナライズ結果を要求するための設定単位です。
Data Space
Profile Data Graph
Personalization Type
Content Schema
Decision
例えば、「トップページの Hero 用」「おすすめ商品用」のように作成します。
Point は、Web ページの表示場所そのものではありません。どの要素へ表示するかは、WPM や実装側で指定します。
Recommendations 用の Decision に設定する Recommender は、Point と同じ Profile Data Graph を使用している必要があります。
Personalization Type と Content Schema
Personalization Type の基本的な種類は、次のとおりです。
Recommendations：Recommender が選んだ商品や記事などを返す
Dynamic Content：Decision に設定したコンテンツや、差し込み項目で取得した値を返す
Content Schema（旧名称：Response Template）は、返すデータの構造や、Decision で設定できる項目を定義します。
商品名、画像 URL、価格などを返す
見出し、CTA、カテゴリコードなどの追加属性を用意する
Recommendations では、おすすめ対象のルート DMO と返却項目を設定します。
Content Schema は、Web Connector のイベント用 Schema.json とも、画面表示用の Experience Template とも別の設定です。
Decision と Targeting Rules
Decision は、誰を対象に、何を返すかを設定するものです。 Targeting Rules に付ける名前だけではありません。
Targeting Rules：その顧客が対象になる条件を指定する
Decision のコンテンツ設定：返す値や、使用する Recommender などを指定する
Decision State：通常の判定に使用する状態かを指定する
例えば、Targeting Rules を Always にして、全員を対象にしたまま、差し込み項目から顧客ごとのカテゴリを返すこともできます。
対象条件が同じでも、返す内容が全員同じになるとは限りません。
複数の Decision と優先度
1つの Point に複数の Decision を追加できます。複数の Decision に該当する場合は、優先度に基づいて返す Decision が決まります。
初期の優先度は作成順で決まり、後から変更できます。
一方、Affinity のスコア順にカテゴリを返す設定は、Decision 同士の優先度とは別です。TrailNest では、1 つの Decision の差し込み項目でカテゴリをスコアの降順に並べました。
Dynamic Content でバナーを切り替える
商品レコメンドだけでなく、見出し、画像 URL、CTA、カテゴリコードなどを返して、バナーを切り替えることもできます。
例えば、次の構成です。
顧客のカテゴリへの Affinity を参照する
Decision が最高スコアのカテゴリを返す
Web 側で、そのカテゴリに対応するバナーを表示する
画像や文言を Decision から返す構成も、カテゴリコードだけを返し、表示側に用意した画像や文言を選ぶ構成もあります。
Dynamic Content は、必ずしも全員に同じ固定コンテンツを返す機能ではありません。 顧客データを差し込むことで、返す値を変えることもできます。
Experience Template と WPM
API がデータを返しただけでは、Web ページの表示は変わりません。
Experience Template：返されたデータを、バナーや商品カードなどの HTML として表示する
Web Personalization Manager（WPM）：使用する Point と Template、対象ページ、表示場所などを設定する
WPM は、バナーだけでなく、商品レコメンドの表示にも使用できます。
別の方法として、Decisioning API を JavaScript から呼び出し、独自の処理で商品カードを表示することもできます。
但し、独自の API 実装で表示する場合、表示・クリックの計測も実装に合わせて用意します。WPM の自動計測が、そのまま付くわけではありません。
消費クレジットを確認する
Salesforce Personalization の利用状況は、Digital Wallet で確認できます。
現在の公式ヘルプでは、契約に応じて、Decision の利用に Personalization Credits または Flex Credits が適用されると説明されています。
いかがでしたでしょうか。
Salesforce Personalization は、おすすめ商品を選ぶ機能だけではありません。顧客データを使って返す内容を決め、メールや Web などの表示につなげる仕組みです。
Data Graph で参照するデータを用意し、Decision で対象と返す内容を決め、商品選択には Recommender を使います。
Web への表示には、Experience Template と WPM、または API を使った独自実装を組み合わせます。
「データ」「選択」「表示」の役割を分けて理解すると、バナーの出し分けと商品レコメンドの共通点や違いが分かりやすくなります。
今回は以上です。
