【第242回】 比較する属性の追加機能を活用した高度な判断分岐を実現する方法
Salesforce Marketing Cloud の Journey Builder の「判断分岐」には、属性と属性を比較する機能で「比較する属性の追加」という機能があります。この機能に関しては、まったく使用したことがないという方もいるかもしれませんが、とても便利な機能ですので、今回は、活用事例ベースで紹介してみたいと思います。
事例 ① : 同じ属性値に対応した値の正確な取得
架空のシナリオ
あるゲーム会社では、ゲームアプリが販売された後に顧客育成のシナリオを実行しています。ゲームソフトが顧客へ販売されると、そのアプリ名をエントリーソースに保存し、以下の流れでジャーニーが開始します。
ウェルカムメールを送信する
似たようなゲームアプリの紹介メールを送信する
ゲームアプリ購入から 30 日経過後、購入したゲームアプリを 3 回未満しか開いていない人に特定コンテンツをメール送信する
これらをジャーニーで表現するのであれば、以下のような形でしょうか。
今回は、3 つ目のメール送信である「購入から 30 日経過後、購入したアプリを 3 回未満しか開いていない人に特定コンテンツをメール送信する」の箇所の「判断分岐」を取り上げます。
まず、エントリーソースのデータエクステンションには、以下のフィールドがあります。
Id（プライマリキー）
GameAppName（プライマリキー）
Email
こちらに格納されるレコードは、以下のように一人の顧客が複数のゲームアプリを購入する可能性があるため、複数行存在できるようにしてあります。
ゲームアプリの開封数を管理するデータエクステンションには、以下のフィールドがあります。こちらは、現時点でのゲームアプリの開封数を格納したいので、Contact Builder のデータデザイナーでリンクを作成して、「連絡先データ」として活用します。
Id（プライマリキー）
GameAppName（プライマリキー）
Open
こちらに格納されるレコードには、同じデータエクステンション内で複数のゲームアプリの開封数が管理されており、Open 数は、顧客がアプリを開くことで、常に変動します。
問題点
ここで Id や GameAppName をキーにして、Contact Builder のデータデザイナーのリンク設定をすると思うのですが、ここで特に何も気にせず、以下のような条件で判断分岐の設定を行うと、問題が発生します。
GAME A としてエントリー → Open 数 2 と判定され、メール送信される
GAME B としてエントリー → Open 数 2 と判定され、メール送信される
これは判断分岐における評価方法が、最初に見つかったレコード（データエクステンションの上側にあるレコード）を参照 してしまい、結果として GAME A/B 両方にメールが送信される 誤判定が発生しているからです。
つまり、連絡先が GAME A の購入分としてエントリーしていようが、GAME B の購入分としてエントリーしていようが、ゲームアプリの開封数を管理するデータエクステンションの上側にある Open 数 2 を、採用してしまうわけですね。
Salesforce に言わせれば、誤判定ではなく「これは仕様です」となります。
解決策：「比較する属性の追加」機能を活用
この問題を解決するには、「比較する属性の追加」機能を使用して、以下のように設定します。
手順
左側に「連絡先データ」の GameAppをドラッグアンドドロップする
「比較する属性の追加」にチェックを入れる
右側に「ジャーニーデータ」の GameApp をドラッグアンドドロップする
演算子は、デフォルトの「次の値と等しい」のままで問題ありません
この比較の条件を Open 側の条件と、「および」の条件にしてください
結果
この設定により、エントリーされたゲームアプリごとに Open 数の値を正しく取得することが可能となり、以下のように動作します。
GAME A としてエントリー → Open 数 2 と判定され、メール送信される
GAME B としてエントリー → Open 数 15 と判定され、メール送信されない
いかがでしたでしょうか。
設定する際のイメージとしては、通常は購読者キーだけで、連絡先データの評価が実行されますが、この購読者キーに加えて、「サブキー」のようなものを追加して評価させることができるというイメージです。
またこの機能には、いくつか「前提条件」があるので確認しておきます。
暗号化されたフィールドはサポートされていません。
同じデータ型の属性のみを比較します。ちなみに、属性のデータ型が違う場合は、ドラッグしてもドロップすることができません。
※ ヘルプドキュメントには、null 値を許可する属性は、属性間の比較には使用できませんと記載されており、実際に null 値を許可する属性をドラッグアンドドロップすると、以下のようなアラートが出ますが、実際は問題なく使用できるようです。ただし、将来的にトラブルが発生する可能性がありますので、「必須」項目として構成すべきでしょう。
それでは、今回、もう一つのシナリオ例でも確認してみましょう。
事例 ② : 顧客スコアが下がった人にメール送信
架空のシナリオ
ジャーニーのエントリーソースには、そのシナリオ開始時の「顧客スコア」が入力されています。この「顧客スコア」は、固定値のジャーニーデータとして活用されます。
Id（プライマリキー）
Email
Score（必須項目推奨）
一方、現在の「顧客スコア」をリアルタイムで管理・計算している連絡先データがあります。
Id（プライマリキー）
Latest_Score（必須項目推奨）
ここでまた、シナリオ開始 30 日後にシナリオ開始時の「顧客スコア」と比べて、連絡先データ内の最新の「顧客スコア」が低い場合に、メールを送信するシナリオがあった場合に「比較する属性の追加」が使用できます。
手順
左側に「ジャーニーデータ」の Score（数字型）をドラッグアンドドロップする
「比較する属性の追加」にチェックを入れる
右側に「連絡先データ」の Latest_Score（数字型）をドラッグアンドドロップする
演算子を、「次の値より大きい」に変更します。これによりジャーニーデータのスコアが、最新のスコアより大きい場合に、右のパスに進みます
※ 演算子は「完了」を押さないと確定しませんので、注意して下さい。先に「サマリー」ボタンを押すと、デフォルトの「一致」のままになります。
結果としては、以下の通りになります。
連絡先 BOR501 → 顧客スコアが 5 上回るので、メール送信されない
連絡先 BOR502 → 顧客スコアが 3 下回るので、メール送信される
既知の問題と推奨事項
さて、この「比較する属性の追加」機能には、さまざまな既知の問題が存在します。この機能を使用する際には、エラーが発生する可能性があるため、ジャーニーを必ずテストして、正しく分岐することを確認してください。
複合条件を使用する場合
事例 ① のように「属性の比較」と「他の条件」を組み合わせた複合条件を設定する際には、以下の配置が推奨されます。
左側：「連絡先データ」をドラッグアンドドロップ
右側：「ジャーニーデータ」をドラッグアンドドロップ
この設定は、2023 年に改修が行われたものの、依然として一部の不具合が報告されています。複合条件を利用する場合には、注意してください。
事例 ②：数字型の大小比較を使用する場合
数字型の属性で大小を比較する際に、以下のような配置をすると、ジャーニーの検証時にエラーが発生することがあります。
左側：「連絡先データ」をドラッグアンドドロップ
右側：「ジャーニーデータ」をドラッグアンドドロップ
この場合、配置を以下のように入れ替えることでエラーが解消されます。
左側：「ジャーニーデータ」をドラッグアンドドロップ
右側：「連絡先データ」をドラッグアンドドロップ
今回、紹介した事例 ② の数字型の大小比較は、複合条件を使用していないため、左側に「ジャーニーデータ」を配置しても動作します。このように条件や属性のタイプに応じて、ドラッグアンドドロップでの配置を調整してみることが重要です。
いかがでしたでしょうか。
この「比較する属性の追加」機能を使うには、ある種の「閃き」💡 のようなものが必要ですが、意外と「判断分岐」であっても柔軟に分岐ができるな、と少しでも感じて頂けたら幸いです。
一方で、既知の問題も多く存在しますので、必ずジャーニーのテストを行って、正しく分岐するかを試すのをお忘れなくお願いします。
今回は以上です。
