見出し画像

【第500回】 Marketing Cloud Next : フローで計算済みインサイトを使う方法

今回の記事は Marketing Cloud Next Growth & Advanced Edition の「セグメントトリガーフロー」で、計算済みインサイトを利用する際の注意点 について整理してみたいと思います。

一見シンプルに見えますが、いくつかハマりやすいポイントがあるため、実装前に押さえておくことをおすすめします。

主なポイントは以下の 3 つです。

  • ディメンション設定が必須

  • Get Records ではなくリソースを使用する

  • 計算できなかったレコードも用意する

それぞれ解説します。


ディメンション設定が必須

まず基本となる設定です。

フロー内で計算済みインサイトを利用する場合、WHERE 条件として「ディメンション」を指定する必要があります。

Marketing Cloud Next では、通常 Unified Individual ベースのデータグラフが前提となっており、計算済みインサイトも Unified Individual ID を基準に作成されています。(標準のスコアリングなども同様です)

そのため、ディメンションには Unified Individual ID を設定することになります。

なお、この設定を行わない場合は、以下のようなフロー保存時にエラーが発生するため、比較的気づきやすいポイントです。


Get Records ではなくリソースを使用する

次に重要なのが、Unified Individual ID の扱いです。
稀に、演算子が選択できず、Equalsしか利用できない場合があります

この時、一見すると、Get Records 要素を使って Unified Individual ID を取得したくなりますが、この方法では値が NULL になります

これはデバッグ・本番ともに同様で、結果としてすべてのレコードがデフォルトパスに流れてしまいます。

この問題を回避するためには、

  • 新規リソースで「変数」を作成

  • トリガーされた Unified Individual ID をその変数に割り当てる

という方法を取ります。

この変数をディメンションに使用することで、デバッグ・本番ともに正常に動作します。

Tips:演算子が選択可能である場合は、リソース変数を作らずに「Is Null = False」とすることも可能です。


計算できなかったレコードも用意する

ここが最も見落とされがちなポイントです。

標準のスコアリングの計算済みインサイトでは、すべての Unified Individual に対して値が用意されています。スコアが存在しない場合でも「0」として保持されています。

しかし、カスタムで作成した計算済みインサイトはどうでしょうか。

例えば、売上データ(Sales Order Product Engagement など)を元に集計した場合、当然ながら「購入した人」のデータしか存在しません。例えば、購入回数をカウントしたような場合を例にすると

  • 購入した人 → 計算済みインサイトの レコードあり

  • 購入していない人 → 計算済みインサイトの レコードなし

という状態になります。

この状態で分岐条件に計算済みインサイトを使用すると、

  • 購入した人(レコードありの人) → 正常に分岐  

  • 購入していない人(レコードなしの人) → エラーでフローから強制退出

という挙動になります。本番でも以下の通りです。

そのフローが、たまたま退出しても問題ないケースであれば成立しますが、「未購入者にメールを送りたい」ようなシナリオでは致命的です。

そのため、カスタムの計算済みインサイトを作成する際は、

👉 必ず「値が存在しない人 = 0」のレコードも用意する

という設計を徹底することが重要です。

  • 値が存在しない人を用意した場合 → エラーとならず、End まで進む


いかがでしたでしょうか。

今回、紹介した内容のうち、明確にエラーとして検知されるのは「ディメンション設定」が不足しているケースのみです。それ以外のポイントについては、実行時に初めて問題として現れるため、デバッグを行わない限り見抜くことが難しい内容となっています

Marketing Cloud Next は複数の仕組みを組み合わせて構成されているため、一見正常に見えても、意図しない挙動を引き起こす “サイレントエラー” が発生しやすい特性があります。

本記事の内容も、丁寧にデバッグを行えば発見できるものではありますが、逆に言えばデバッグを怠ると見過ごしてしまう可能性が高いポイントでもあります。

そのため、「決定」要素や「終了条件」については、複数のパターンを想定しながら、必ず繰り返し検証を行うことを強くおすすめします。


なお、関連属性もWHERE でディメンションが必須 となりますが、関連属性の場合は、例えば、「購入した人」のデータが存在せずとも、エラーは発生しません。エラーが発生するのは、計算済みインサイトの場合のみ です。

それであれば、常に関連属性を使えば ・・・ と思うかもしれませんが、取得できるデータのタイムリミットに差があります。

  • 関連属性で取得できるデータのタイムリミット:デフォルト 7 日分
    ※ 最大 30 日分まで延長可能(詳細はこちら

  • 計算済みインサイトで取得できるデータのタイムリミット:制限無し

そのため、計算済みインサイトを利用する必要がある場合があり、計算済みインサイトを利用する場合は、上記の事項を考慮してください。

今回は以上です。


前回の記事はこちら

私の note のトップページはこちら