コンテキスト

コンテキストステップを使用すると、ユーザーがキャンバス内を移動するときに、ユーザーの変数を1つ以上作成、更新できます。例えば季節割引を管理するキャンバスでは、コンテキスト変数を使用して、ユーザーがキャンバスにエントリするたびに異なる割引コードを保存できます。

仕組み

コンテキストステップを使用すると、特定のキャンバスを経由したユーザーの移動中に一時データを作成して使用できます。このデータは、そのCanvas ジャーニー内にのみ存在し、異なるCanvase 間やセッション外では保持されません。

このフレームワーク内で、各コンテキストステップは、複数のコンテキスト変数(ユーザーのプロファイル情報を永続的に変更することなく、遅延のパーソナライズ、ユーザーの動的セグメント化、メッセージングの拡張を可能にする一時的なデータ)を定義できます。

たとえば、フライト予約を管理している場合、各ユーザーのスケジュールされたフライト時間のコンテキスト変数を作成できます。その後、各ユーザーのフライト時間に応じて遅延を設定し、同じキャンバスから個別のリマインダーを送信できます。

コンテキスト変数は、次の2 つの方法で設定できます。

• キャンバスエントリで:ユーザがキャンバスに入ると、イベントまたはAPI トリガのデータが自動的にコンテキスト変数に入力されます。
• コンテキストステップで:コンテキストステップを追加することで、キャンバス内でコンテキスト変数を手動で定義または更新できます。

各コンテキスト変数には以下が含まれます。

• 名前 (flight_time やsubscription_renewal_date など)
• データ型 (数値、文字列、時刻、配列など)
• LiquidまたはAdd Personalizationツールを使用して割り当てる値。

定義したコンテキスト変数は、キャンバス全体で {{context.${example_variable_name}}} という形式で参照できます。

たとえば、{{context.${flight_time}}} は、ユーザーのスケジュールされたの飛行時間を返します。

ユーザーがキャンバスにエントリするたびに (以前にキャンバスにエントリしたことがある場合でも)、コンテキスト変数は、最新のエントリデータとキャンバス設定に基づいて再定義されます。このステートフルなアプリ侵入により、各キャンバスエントリは独自の独立系コンテキストを維持でき、ユーザーs は各ステートに固有のコンテキストを保持したまま、同じジャーニー内で複数のアクティブなステートを持つことができます。

たとえば、ある顧客に2 つの次のフライトがある場合、2 つの別々のジャーニーステートが同時に実行され、それぞれに、出発時刻や送信先などの独自のフライト固有のコンテキスト変数が含まれます。これにより、ニューヨーク行きの午後2時の飛行に関するパーソナライズされたのリマインダーを送る一方で、明日のロス・アンヘレス行きの午前8時の飛行に関する別々の更新を送ることができ、各々のメッセージは、具体的な予約に関連したものであり続けることができます。

考慮事項

• コンテキストステップごとに最大10 個のコンテキスト変数を使用できます。
• 各コンテキスト変数名は最大100 文字です。
• コンテキスト変数名は有効な識別子s (文字、数字、アンダースコアのみ) である必要があります。
• コンテキスト変数の定義は最大10,240 文字です。
• API-トリガー ed Canvas に渡されるコンテキスト変数は、キャンバスのコンテキストステップで作成されるコンテキスト変数と同じ名前空間を共有します。これは、/canvas/trigger/sendエンドポイントコンテキストオブジェクトで変数purchased_itemを送信する場合、{context.${purchased_item}}として参照でき、キャンバスのコンテキストステップでその変数を再宣言すると、以前に送信されたものが上書きされることを意味します。
• コンテキストステップごとに最大50KB を保存でき、ステップごとに最大10 個の変数を分散できます。1 つのステップで最大50KB の可変長は、ユーザーに対して評価または保存されません。これらのサイズは順番に計算されます。たとえば、コンテキストステップに3 つの変数があるとします。
  • 変数1:30 KB
  • 変数2:19 KB
  • 変数3:2 KB
  • これは、他のすべてのコンテキスト変数の合計が50KB を超えるため、変数3 が評価または保存されないことを意味します。

コンテキストステップの作成

ステップ1:ステップを追加する

キャンバスにステップを追加し、サイドバーからコンポーネントをドラッグアンドドロップするか、 plus ボタンを選択し、Context を選択します。

ステップ2: 変数の定義

コンテキスト変数を定義するには

1. コンテキスト変数にname を指定します。
2. データ型を選択します。
3. Liquid 式を手動で記述するか、Add Personalization を使用して既存の属性からLiquid スニペットを作成します。
4. コンテキスト変数の値を確認するには、プレビューを選択します。
5. (オプション) 変数を追加するには、コンテキスト変数を追加 を選択し、ステップs 1～4 を繰り返します。
6. [完了] を選択します。

これで、[パーソナライズを追加する] を選択して、メッセージステップやユーザー更新ステップなど Liquid を使用する任意の場所で、コンテキスト変数を使用できます。フルウォークスルーについては、コンテキスト変数の使用を参照してください。

コンテキスト変数のデータ型

ステップで作成または更新されるコンテキスト変数には、次のデータ型を割り当てることができます。

デフォルトでは、時刻データタイプはUTCです。文字列データ型を使用して時刻値を格納する場合は、PSTのように別のタイムゾーンとして時刻を定義できます。

たとえば、誕生日の前日にユーザーにメッセージを送信する場合、前日の送信に関連付けられている流動ロジックがあるため、コンテキスト変数を時間データタイプとして保存します。ただし、クリスマスデー(12月25日)にホリデーメッセージを送信する場合は、時刻をダイナミックな変数として参照する必要はありません。そのため、文字列データ型を使用することをお勧めします。

コンテキスト変数の使用

たとえば、次のフライトの前に、VIP ラウンジへのアクセスについて乗客に通知したいとします。このメッセージは、ファーストクラスのチケットを購入した乗客にのみ送信する必要があります。コンテキスト変数は、この情報を追跡する柔軟な方法です。

ユーザーは、飛行機のチケットを購入するときにキャンバスに入ります。ラウンジアクセスの適格性を判断するために、コンテキストステップでlounge_access_grantedというコンテキスト変数を作成し、その後のユーザージャーニーのステップでそのコンテキスト変数を参照します。

このコンテキストステップでは、{{custom_attribute.${purchased_flight}}} を使用して、購入したフライトのタイプがfirst_class かどうかを判断します。

次に、{{context.${lounge_access_granted}}} がtrue であるユーザーをターゲットにするメッセージステップを作成します。このメッセージは、個人化されたラウンジ情報を含むプッシュ通知となります。このコンテキスト変数に基づいて、適格な乗客は、フライト前に関連するメッセージを受け取ります。

• ファーストクラスの乗客は次のメッセージを受け取ります:「Enjoy exclusive VIP lounge access!」
• ビジネスクラスとエコノミークラスの乗客は次のメッセージを受け取ります:「Upgrade your flight for exclusive VIP lounge access.」

アクションパスと終了基準の場合

次のトリガー アクションs では、プロパティ フィルターs をコンテキスト変数またはカスタム属性s と比較することができます。[カスタムイベントを実行] または [購入] のいずれかを選択できます。これらのアクション トリガーs は、基本プロパティーとネストされたプロパティーの両方のプロパティ フィルターs にも対応しています。

• 基本プロパティーと比較する場合、使用可能な比較は、カスタムイベントで定義されたプロパティの種類と一致します。たとえば、文字列プロパティは、正規表現一致と完全に等しくなります。ブール値のプロパティはtrue またはfalse になります。
• ネストされたプロパティと比較する場合、型は事前定義されていないため、階層化カスタム属性s の比較と同様に、ブール値、数値、ストリング、時刻、および曜日の複数のデータ型の比較を選択できます。比較時にネストされたプロパティの実際のデータ型と一致しないデータ型を選択した場合、ユーザーはアクションパスまたは終了基準と一致しません。

アクションパスの例

• perform custom event
• make purchase

終了基準の例

• perform custom event
• make purchase

コンテキスト変数フィルターs

Audience PathsおよびDecision Splitステップsで、事前に宣言されたコンテキスト変数を使用するフィルターsを作成できます。

コンテキスト変数は宣言され、キャンバスのスコープでのみアクセス可能です。つまり、Segment s では参照できません。コンテキスト変数フィルターs は、オーディエンスパスおよびディシジョン分割ステップs-オーディエンスパスステップs では複数のグループを表し、ディシジョン分割s はバイナリ決定を表します。

キャンバスのコンテキスト変数の定義済みタイプと同様に、コンテキスト変数と静的値の比較には、一致するデータ型が必要です。コンテキスト変数フィルターでは、階層化カスタム属性 s の比較と同様に、ブール値、数値、文字列、時刻、および曜日の複数のデータタイプの比較が可能です。

以下は、コンテキスト変数product_name を正規表現/braze/ と比較するコンテキスト変数フィルターの例です。

コンテキスト変数またはカスタム属性s との比較

コンテキスト変数またはカスタム属性トグルと比較を選択することで、以前に定義されたコンテキスト変数またはユーザー カスタム属性s と比較するコンテキスト変数フィルターs を作成できます。これは、API-トリガー ed context など、ユーザーごとにダイナミックなな比較を実行する場合や、コンテキスト変数間で定義された複雑な比較ロジックを圧縮する場合に役立ちます。

• example 1
• example 2

ユーザー パスのプレビュー

ユーザー パスs でテストと[ プレビューを実行して、メッセージが正しいオーディエンスに送信され、コンテキスト変数が期待される結果に評価されることを確認することをお勧めします。

無効なコンテキスト変数を作成する一般的なシナリオを必ず守ってください。ユーザー パスをプレビューするときに、コンテキスト変数、およびユーザーs と任意のコンテキスト変数を照合するオーディエンス、ディシジョン、またはアクションパス ステップの比較を使用して、パーソナライズされた遅延ステップs の結果を表示できます。

コンテキスト変数が有効な場合は、キャンバス全体で変数を参照できます。ただし、コンテキスト変数が正しく作成されていない場合、キャンバス内の将来のステップも正しく実行されません。たとえば、コンテキストステップを作成してユーザーにアプリの軟膏時間を割り当て、アプリの軟膏時間の値を過去の日付に設定した場合、メッセージステップのリマインダーメールは送信されません。

接続されたコンテンツ文字列のJSON への変換

コンテキストステップでコネクテッドコンテンツ呼び出しを実行すると、整合性とエラー防止のために、呼び出しから返された JSON が文字列データ型として評価されます。この文字列をJSON に変換する場合は、as_json_string を使用して変換します。以下に例を示します。

1
2
{% connected_content http://example.com :save product %}
{{ product | as_json_string }}

タイムゾーン整合性の標準化

タイムスタンプタイプを使用するほとんどのイベントプロパティはキャンバスですでにUTCになっていますが、いくつかの例外があります。キャンバスコンテキストを追加すると、アクション ベースのキャンバスのすべてのデフォルトタイムスタンプイベントプロパティは一貫してUTC になります。この変更は、キャンバスステップやメッセージを編集する際に、より予測可能で一貫性のあるエクスペリエンスを確保するための、より幅広い作業の一部です。この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかに関係なく、すべてのアクションベースのキャンバスに影響を与えることに注意してください。

トラブルシューティング

無効なコンテキスト変数

以下の場合、コンテキスト変数は無効と見なされます。

• 埋め込み接続コンテンツへの呼び出しが失敗します。
• 実行時のLiquid 式は、データ型と一致しない値、または空(NULL) の値を返します。

たとえば、コンテキスト変数のデータ型がNumber であるが、Liquid 式が文字列を返す場合、これは無効です。

このような状況では次のようになります。

• ユーザーは次のステップに進みます。
• キャンバスステップ分析では、これは_未更新_としてカウントされます。

トラブルシューティングの際には、_未更新_指標を監視して、コンテキスト変数が正しく更新されることを確認します。コンテキスト変数が無効な場合、ユーザーはコンテキストステップを過ぎてもキャンバスに留まることができますが、後のステップには適さない場合があります。

各データ型の設定例については、コンテキスト変数データ型を参照してください。

よくある質問

キャンバスコンテキストが一般的に使用可能になると、何が変わりますか?

キャンバスコンテキストが一般的に使用可能になると、次の情報がアプリされます。

• アクション ベースのキャンバスのdatetime type がトリガーイベントプロパティ のすべてのタイムスタンプは、必ずUTC になります。
• この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかにかかわらず、アクションベースのすべてのキャンバスに影響します。

この変更の理由は何ですか?

この変更は、キャンバスステップやメッセージを編集するときに、より予測可能で一貫性のあるエクスペリエンスを作成するための、より幅広い作業の一部です。

この変更はいつ有効になりますか?

• キャンバスコンテキストの早期アクセスに参加している場合、この変更はすでにアプリ嘘になっています。
• キャンバスコンテキストの初期アクセスに参加していない場合は、初期アクセスに参加したとき、またはキャンバスコンテキストが一般的に使用可能になったときに、この変更がアプリされます。

API-トリガーキャンバスまたはスケジュールされたキャンバスは、この変更の影響を受けますか?

いいえ。

この変更は、キャンバスのエントリプロパティーに影響しますか?

はい。これは、canvas_entry_propertyがアクションベースのキャンバスで使用されており、プロパティの種類がtimeの場合、canvas_entry_propertiesに影響します。どのような状況でも、必要なタイムゾーンで表されるタイムスタンプには、リキッドtime_zone フィルターを使用することをお勧めします。

これを行う方法の例を次に示します。

新しいタイムスタンプの振る舞いが私のメッセージにどのように影響するかの実用的な例は何ですか?

たとえば、メッセージステップに次の内容を含むアクションベースのキャンバスがあるとします。

1
Your appointment is scheduled for {{canvas_entry_properties.${appointment_time} | date: "%Y-%m-%d %l:%M %p"}}, we'll see you then!

これにより、次のメッセージが表示されます。

1
Your appointment is scheduled for 2025-08-05 4:15pm, we’ll see you then!

Liquidを使用してタイムゾーンが指定されていないため、ここでのタイムスタンプはUTCです。

タイムゾーンを明確に指定するには、以下のようにリキッドtime_zone フィルターs を使用します。

1
Your appointment is scheduled for {{canvas_entry_properties.${appointment_time} | time_zone: "America/Los_Angeles" | date: "%Y-%m-%d %l:%M %p"}}, we'll see you then!

これにより、次のメッセージが表示されます。

1
Your appointment is scheduled for 2025-08-05 8:15am, we'll see you then!

America/Los アンヘレスタイムゾーンはLiquid を使用して指定されているため、ここでのタイムスタンプはPST です。

推奨されるタイムゾーンは、以下のような支払いプロパティーの読み込むで送信することもでき、リキッドロジックで使用できます。

1
2
3
4
{
  "appointment_time": "2025-08-05T08:15:30:250-0800"
  "user_timezone": "America/Los_Angeles"
}

コンテキスト変数は、Canvas エントリプロパティとはどのように異なるのですか?

コンテキストステップの初期アクセスに参加している場合は、キャンバスエントリのプロパティがキャンバスのコンテキスト変数として含まれるようになりました。つまり、Liquid スニペットでコンテキスト変数を使用する場合と同様に、Braze API を使用してキャンバスエントリのプロパティを送信し、他のステップでこれらのプロパティを参照できます。

変数は、1つのコンテキストステップ内で相互に参照できますか?

はい。コンテキストステップのすべての変数は、シーケンスで評価されます。つまり、以下のコンテキスト変数を設定できます。

これは、複数のコンテキストステップにも適用されます。例えば次のシーケンスを考えてみます。

1. 最初のコンテキストステップでは、JobInfo という変数を作成して値 job_title を設定します。
2. メッセージステップは {{context.${JobInfo}}} を参照し、job_title をユーザーに表示します。
3. その後、コンテキストステップによってコンテキスト変数が更新され、JobInfo の値がjob_description に変更されます。
4. JobInfo を参照する以降のすべてのステップで、更新された値job_description が使用されるようになりました。

コンテキスト変数は、キャンバス全体で最新の値を使用します。更新を行うたびに、その変数を参照する後続のすべてのステップに影響します。