送信前にキャンバスでプロファイルデータを更新する

ジャーニーが数日から数週間続く場合、ユーザーがキャンバスにエントリした後にプロファイルデータが変更される可能性があります。コンテキストステップを使用してプロファイル上の一致するオブジェクトを検索し、オーディエンスパスまたは条件分岐でメッセージングを分岐させます。

この例について

架空の保険ブランドである ClaimsJumpr は、保険契約の更新日の28日前になると、アクションベースのキャンバスを開始します。この28日間に、ClaimsJumpr は複数のリマインダーを送信します。保険契約者はエントリー後にその契約の自動更新設定を変更できるため、キャンバスエントリープロパティだけを使用するメッセージでは、誤ったステータスが記載される可能性があります。

各ユーザープロファイルは、保険契約をオブジェクト配列のカスタム属性 (policies) として保存します。各オブジェクトには、トリガーイベントに含まれる一意の policy_id と、auto_renewal の値 (opted_in または opted_out) が含まれます。この例では、後続のメッセージステップの前にコンテキストステップを追加します。これにより、Liquid がキャンバスコンテキスト (エントリーイベント) の policy_id と照合して、policies から現在のオブジェクトを読み取ります。

このシナリオでは、次のことを行います。

1. エントリー時の policy_id をキャンバスコンテキストに保持します。
2. コンテキストステップと Liquid の where フィルターを使用して、policies から一致するオブジェクトを選択します。
3. auto_renewal を、タイプ String のコンテキスト変数 (auto_renewal) として保存します。
4. この記事で中止用の Liquid を重複して記述するのではなく、オーディエンスパスまたは条件分岐のコンテキスト変数フィルターを使用して、文面を振り分けます。

考慮事項

• 本番環境以外のワークスペースでキャンバスをテストしてください。オブジェクトに auto_renewal が存在しないプロファイルも含めてテストします。
• where が1つのオブジェクトを返すように、policies 内の policy_id の値は一意にしてください。
• 別のキャンバスが同じトリガーイベントからユーザー更新ステップを使用して policies を書き込む場合、最初のメッセージの前にプロファイルが更新されていない可能性があります。エントリ後の最初のメッセージステップでは、エントリコンテキストのプロパティを使用してください。このコンテキストステップは、プロファイルの更新が反映されるまでの時間が経過した後のステップで使用します。
• コンテキスト変数名には、英字、数字、アンダースコアのみを使用できます (最大100文字)。1つのコンテキストステップにつき、最大10個の変数を定義できます。
• この記事の Liquid は一例です。ご自身の属性名と値について、ユーザーパスのプレビューとテスト送信を行ってください。

設定

この例では、次のことを前提としています。

ステップ1: 後続のメッセージの前にコンテキストステップを配置する

キャンバスで、現在の自動更新ステータスを反映する必要があるメッセージステップの直前にコンテキストステップを追加します。後続の送信では、エントリプロパティだけに頼らないでください。

ステップ2: コンテキスト変数を定義する

コンテキストステップで、次の操作を行います。

1. コンテキスト変数名を auto_renewal に設定します。
2. データ型を文字列に設定します。
3. 一致するポリシーを選択して auto_renewal を出力する Liquid を入力します。assign のソースを余分な {{ }} タグで囲まないでください。

1
2

{% assign matched_policies = custom_attribute.${policies} | where: "policy_id", context.${policy_id} %}
{{ matched_policies[0].auto_renewal }}

context.${policy_id} はエントリイベントのプロパティで、コンテキスト変数として使用できます。where は、policy_id がその値と一致するオブジェクトを保持します。コンテキストステップには、最初に一致したオブジェクトの auto_renewal フィールドが保存されます。

4. プレビューを選択し、policies にその policy_id を持つテストユーザーの値を確認します。

名前、型、Liquid の制限については、コンテキストとコンテキスト変数を参照してください。

ステップ3: コンテキスト変数で分岐する

コンテキストステップの後に、auto_renewal に対するオーディエンスパスまたは条件分岐のフィルター (たとえば、opted_in と等しいか opted_out と等しいか) でユーザーを分割します。各パスに、それぞれに対応するリマインダーを配置します。

ヒント

フィルターの設定とデータ型の一致については、コンテキスト変数フィルターを参照してください。グループの評価方法については、オーディエンスパスと条件分岐を参照してください。

分岐させる代わりにメッセージステップで送信を中止した場合でも、ユーザーは次のキャンバスステップに進みます。詳細については、メッセージの中止とユーザーが進む仕組みを参照してください。

ステップ4: プレビューとテスト

ユーザーパスのプレビューとテスト送信を使用して、次のケースを確認します。

• 一致するオブジェクトの auto_renewal が opted_in および opted_out の場合
• policies に存在しない policy_id (コンテキスト値が空または空白)
• auto_renewal を含まないオブジェクト

後続のリマインダーが、キャンバスへのエントリ時のステータスだけでなく、プロファイルの内容と一致していることを確認してください。

関連記事

• コンテキスト
• コンテキスト変数
• キャンバスエントリプロパティ
• オーディエンスパス
• 条件分岐
• メッセージステップ
• メッセージの中止
• オブジェクトの配列
• ユーザー更新