送信前にキャンバスでプロファイルデータを更新する
ジャーニーが数日から数週間続く場合、ユーザーがキャンバスにエントリした後にプロファイルデータが変更される可能性があります。コンテキストステップを使用してプロファイル上の一致するオブジェクトを検索し、オーディエンスパスまたは条件分岐でメッセージングを分岐させます。
この例について
架空の保険ブランド ClaimsJumpr は、ポリシーの更新期限が28日前になるとアクションベースのキャンバスを開始します。この28日間に、ClaimsJumpr は数回のリマインダーを送信します。ポリシー保有者はエントリ後にそのポリシーの自動更新を変更できるため、キャンバスエントリプロパティだけを使用するメッセージでは、誤ったステータスが表示される可能性があります。
各ユーザープロファイルには、ポリシーがオブジェクト配列のカスタム属性（policies）として保存されています。各オブジェクトには、トリガーイベントに含まれる一意の policy_id と、auto_renewal の値（opted_in または opted_out）が含まれます。この例では、後続のメッセージステップの前にコンテキストステップを追加して、Liquidがキャンバスコンテキスト（エントリイベント）の policy_id と一致するオブジェクトを policies から読み取るようにします。
このパターンでは以下のことを行います。
- エントリの
policy_idをキャンバスコンテキストに保持します。 - コンテキストステップとLiquidの
whereフィルターを使用して、policiesから一致するオブジェクトを選択します。 auto_renewalをコンテキスト変数（auto_renewal）としてデータ型 String で保存します。- この記事では重複する中止Liquidではなく、オーディエンスパスまたは条件分岐のコンテキスト変数フィルターでコピーをルーティングします。
考慮事項
- 本番以外のワークスペースでキャンバスをテストしてください。オブジェクトに
auto_renewalが欠落しているプロファイルも含めてテストしてください。 policies内のpolicy_idの値は一意にして、whereが1つのオブジェクトだけを返すようにしてください。- 別のキャンバスが同じトリガーイベントから User Update ステップを使用して
policiesを書き込む場合、最初のメッセージの前にプロファイルが更新されない可能性があります。エントリ後の最初のメッセージステップには、エントリコンテキストプロパティを使用してください。プロファイルの更新が適用される時間を確保した後のステップに、このコンテキストステップを使用してください。 - コンテキスト変数名には、文字、数字、アンダースコアのみ使用できます（最大100文字）。1つのコンテキストステップにつき最大10個の変数を定義できます。
- この記事のLiquidは例です。属性名と値に合わせて、ユーザーパスのプレビューとテスト送信を行ってください。
設定
この例では以下を前提としています。
| アセット | 詳細 |
|---|---|
| エントリ | policy_renewal_window_started などのカスタムイベントに基づくアクションベースのキャンバス（イベントプロパティ policy_id あり） |
| カスタム属性 | policies — オブジェクトの配列。各オブジェクトに policy_id と auto_renewal を含む |
| コンテキスト変数 | auto_renewal — 文字列（opted_in または opted_out） |
ステップ1: 後続メッセージの前にコンテキストステップを配置する
キャンバスで、現在の自動更新ステータスを反映する必要があるメッセージステップの直前にコンテキストステップを追加します。後続の送信ではエントリプロパティだけに頼らないでください。
ステップ2: コンテキスト変数を定義する
コンテキストステップで以下を行います。
- コンテキスト変数名を
auto_renewalに設定します。 - データ型を String に設定します。
- 一致するポリシーを選択して
auto_renewalを出力するLiquidを入力します。assignのソースを追加の{{ }}タグで囲まないでください。
{% 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 フィールドを保存します。
- プレビューを選択し、
policiesにそのpolicy_idを持つテストユーザーの値を確認します。
名前、データ型、Liquidの制限については、コンテキストとコンテキスト変数を参照してください。
ステップ3: コンテキスト変数で分岐する
コンテキストステップの後、auto_renewal のオーディエンスパスまたは条件分岐フィルターでユーザーを分割します（例: opted_in と opted_out の比較）。各パスに対応するリマインダーを配置します。
メッセージステップで分岐する代わりに送信を中止した場合、ユーザーは次のキャンバスステップに進みます。詳細については、メッセージの中止とユーザーの進行方法を参照してください。
ステップ4: プレビューとテスト
ユーザーパスのプレビューとテスト送信で以下を確認します。
- 一致するオブジェクトの
auto_renewalがopted_inおよびopted_outの場合 policiesに存在しないpolicy_idの場合（空またはブランクのコンテキスト値）auto_renewalが省略されているオブジェクトの場合
後続のリマインダーが、キャンバスエントリ時のステータスだけでなく、プロファイルと一致していることを確認してください。