エントリイベントに一致する終了条件

この記事では、キャンバスのエントリイベントに直接関連する終了条件とアクションパスステップの設定方法について説明します。これにより、ユーザーがキャンバスに入った理由に関連する特定のアクションを実行した場合にのみ、終了または分岐するようになります。

イベントプロパティをキャンバスのエントリデータと比較することで、高度にターゲットされたフローを作成できます。例えば、カート放棄キャンバスでは、ユーザーが放棄した商品と同じ商品を購入した場合にのみ終了するように設定し、別の商品を購入した場合はリマインダーメッセージを引き続き受信するようにできます。

このアプローチでは、コンテキスト変数を使用してイベント間のプロパティを比較します。キャンバス Context が有効でないワークスペースでは、パーソナライゼーションメニューで同じエントリデータが キャンバス Entry Properties と表示されます。このパターンはeコマース以外にも、保険の更新、予約リマインダー、購読管理など、多くのシナリオに適用できます。

終了条件：一致するアクションが発生した場合にキャンバスを終了する

ユーザーがエントリイベントに一致するアクションを実行した後にキャンバスから完全に離脱させたい場合は、終了条件を使用します。

例：チケット購入の放棄

このシナリオでは、ユーザーがevent_idというプロパティを含むカスタムイベントSelected Ticketを実行した時にキャンバスにエントリします。終了条件は、ユーザーがカスタムイベントPurchased Ticket（こちらもevent_idというプロパティを含む）をトリガーした際に、終了イベントのプロパティがエントリイベントのプロパティと比較されるように設定されています。2つが一致した場合、ユーザーはキャンバスを終了します。

これは次のことを意味します：

• ユーザーが最初に選択したチケットと同じチケットを購入した場合、キャンバスを終了し、リマインダーの受信が停止します。
• ユーザーが別のチケットを購入した場合、キャンバスに残り、元のチケットに関するフォローアップメッセージを引き続き受信します。

設定方法：

1. トリガーとなるカスタムイベント（Selected Ticketなど）とその関連プロパティ（event_idなど）を使用して、アクションベースのキャンバスエントリを設定します。
2. ターゲットオーディエンスステップで、完了カスタムイベント（Purchased Ticketなど）を使用して終了条件の例外イベントを設定します。
3. Add property filtersを選択し、基本プロパティevent_idの比較がequalsに設定されたフィルターを追加します。
4. Personalize valueトグルをオンにします。Personalization typeで、ワークスペースに表示されるラベルに応じてContext Variablesまたはキャンバス Entry Propertiesを選択します。次に、Attributeをevent_idに設定します。

これにより、Purchased Ticketイベントのevent_idが、元のキャンバスエントリイベントから保存されたevent_idと比較されます。これらのフィルターの設定の詳細については、終了条件の例を参照してください。

アクションパス：一致するアクションに基づく分岐

ユーザーをキャンバスに留めつつ、後続のアクションがエントリイベントに一致するかどうかに応じて異なるパスをたどらせたい場合は、アクションパスを使用します。

例：分岐パスを使用したチェックアウト放棄

このシナリオでは、アイテムを選択したが購入を完了しなかったユーザーに、最初にチェックアウト放棄メッセージが送信されます。その後、ユーザーはアクションパスステップに1週間保持され、その期間中のアクションに基づいて3つのパスに振り分けられます。

• 元の購入を完了した場合： カスタムイベントプロパティIDがエントリプロパティIDと一致します。これらのユーザーには、お礼メッセージやクロスセルのレコメンデーションを送信できます。
• 別の購入を行った場合： カスタムイベントプロパティIDがエントリプロパティIDと一致しません。これらのユーザーには、元のアイテムについてのリマインダーを送信できます。
• 購入しなかった場合： Everyone Else グループに振り分けられます。これらのユーザーには、より強力なインセンティブや最終リマインダーを送信できます。

設定方法：

1. アクションパスステップを追加し、評価ウィンドウ（1週間など）を設定します。
2. 最初のアクショングループ（元の購入）では、購入完了カスタムイベント（Purchased_Ticket など）のトリガーを追加します。Add property filters を選択し、基本プロパティ event_id の比較を equals に設定するフィルターを追加します。Personalize value をオンにし、Personalization type をワークスペースに応じて Context Variables または キャンバス Entry Properties に設定し、Attribute を event_id に設定します。
3. 2番目のアクショングループ（別の購入）では、同じトリガーイベントを追加しますが、比較を does not equal に設定し、同じコンテキスト変数の構成を使用します。
4. 購入完了イベントをまったく実行しなかったユーザーには、Everyone Else グループを使用します。

これらのフィルターの設定の詳細については、アクションパスの例を参照してください。

その他の活用例

この記事では購入放棄の例を使用していますが、完了アクションをエントリアクションと関連付ける必要があるあらゆるシナリオに同じパターンを適用できます。以下はその例です。

• 保険契約の更新: キャンバスをトリガーした特定の保険契約を更新したユーザーを退出させます。
• 予約リマインダー: 元の予約を確認したか変更したかに基づいてユーザーをBranchで分岐させます。
• 購読管理: 案内された特定のプランをアップグレードしたかどうかに応じて、ユーザーを異なるルートに振り分けます。
• イベント登録: 興味を示した特定のイベントへの登録を完了したユーザーを退出させます。

知っておくべきこと

• この記事の設定は例示的なものです。すべてのコンポーネントを本番環境にリリースする前に、開発環境でテストしてください。
• エントリイベントのプロパティ名とデータ型が、終了条件やアクションパスのステップで使用されているものと一致していることを確認してください。
• イベント間でのプロパティ比較の仕組みについては、コンテキスト変数を参照してください。