コンテキスト変数
コンテキスト変数とは、特定のキャンバス内をユーザーが移動する過程で作成・使用できる一時的なデータである。それらは、遅延をパーソナライズしたり、ユーザーをダイナミックにセグメント化したり、メッセージングを充実させたりすることを可能にする。しかも、ユーザープロファイル情報を恒久的に変更することなく実現できる。コンテキスト変数はキャンバスセッション内でのみ存在し、異なるキャンバス間やセッション外では永続化されない。
コンテキスト変数の仕組み
コンテキスト変数は二つの方法で設定できる:
- キャンバスエントリで:ユーザがキャンバスに入ると、イベントまたはAPI トリガのデータが自動的にコンテキスト変数に入力されます。
- コンテキストステップで:コンテキストステップを追加することで、キャンバス内でコンテキスト変数を手動で定義または更新できる。
各コンテキスト変数には以下が含まれます。
- 名前 (
flight_timeやsubscription_renewal_dateなど) - データ型(数値、文字列、時刻、配列など)
- LiquidまたはAdd Personalizationツールを使用して割り当てる値。
定義したコンテキスト変数は、キャンバス全体で {{context.${example_variable_name}}} という形式で参照できます。
例えば、ユーザーのスケジュールされた{{context.${flight_time}}}フライト時刻を返すことができる。
ユーザーがキャンバスにエントリするたびに (以前にキャンバスにエントリしたことがある場合でも)、コンテキスト変数は、最新のエントリデータとキャンバス設定に基づいて再定義されます。このステートフルなアプローチにより、各キャンバスエントリは独自の独立系コンテキストを維持できる。これにより、ユーザーは同一のジャーニー内で複数のアクティブな状態を保持しつつ、各状態固有のコンテキストを維持できる。
例えば、顧客が2つのフライトを予約している場合、2つの別々の旅程状態が同時に進行する。それぞれに、出発時刻や送信先といったフライト固有のコンテキスト変数が存在する。これにより、午後2時のニューヨーク行きのフライトについてはパーソナライズされたリマインダーを送信しつつ、明日の午前8時のロサンゼルス行きフライトについては別の更新情報を送信できる。こうして各メッセージが特定の予約に関連した内容となるのだ。
考慮事項
コンテキストステップごとに最大10個のコンテキスト変数を定義できる。各変数名は最大100文字までで、英字、数字、またはアンダースコアのみを使用しなければならない。
コンテキスト変数の定義は最大10,240文字まで可能だ。APIによってトリガーされたキャンバスにコンテキスト変数を渡した場合、それらの変数はContextステップで作成された変数と同じ名前空間を共有する。例えば、/canvas/trigger/sendエンドポイントコンテキストオブジェクトpurchased_itemに変数 を送信した場合、それを として参照できる{{context.${purchased_item}}}。その変数をコンテキストステップで再定義すると、新しい値がそのユーザーのジャーニーにおけるAPI値を上書きする。
コンテキストステップごとに最大50KBを保存できる。これは最大10個の変数に分散して保存される。ステップ内の全変数の合計サイズが50KBを超える場合、制限値を超えた変数は評価も保存も行われない。例えば、コンテキストステップに3つの変数がある場合:
- 変数1:30キロバイト
- 変数2:19キロバイト
- 変数3:2 KB
変数3は評価も保存もされない。前の変数の合計が50KBを超えているからだ。
データ型
ステップで作成または更新されるコンテキスト変数には、次のデータ型を割り当てることができます。
コンテキスト変数は、カスタムイベントと同様のデータ型の形式を期待する。
配列型を使用する場合、Brazeはその値をJSONとして解析しようとする。これにより、オブジェクトの配列が正常に作成される。配列内のオブジェクトが有効なJSONでない場合、結果は単純な文字列の配列となる。
ネストされたオブジェクトやオブジェクトの配列には、Liquidas_json_stringフィルターを使う。コンテキストステップで同じオブジェクトを作成する場合、そのオブジェクトをレンダリングする必要があるas_json_string。例えば、 {{context.${object_array} | as_json_string }}
| データタイプ | 変数名の例 | 値の例 |
|---|---|---|
| ブール値 | loyalty_program | true |
| 数値 | credit_score | 740 |
| string | product_name | green_tea |
| 配列 | favorite_products | ["wireless_headphones", "smart_homehub", "fitness_tracker_swatch"] |
| 配列(オブジェクトの) | pet_details | [_mem_lt_br>_mem_amp_emsp;{ "id": 1, "type": "dog", "breed": "beagle", "name": "Gus" }_mem_lt_br>_mem_amp_emsp;,_mem_lt_br>_mem_amp_emsp;{ "id": 2, "type": "cat", "breed": "calico", "name": "Gerald" }_mem_lt_br>] |
| 時間(UTC) | last_purchase_date | 2025-12-25T08:15:30:250-0800 |
| オブジェクト (フラット化) | user_profile | { |
デフォルトでは、時刻データ型はUTCである。文字列データ型で時刻値を保存する場合、その時刻をPSTのような別のタイムゾーンとして定義できる。
例えば、ユーザーの誕生日の前日にメッセージを送信する場合、その前日に送信するというLiquidロジックが関連しているため、コンテキスト変数を時間データ型として保存する。ただし、クリスマスの日(12月25日)に休日のメッセージを送る場合、時間をダイナミックな変数として参照する必要はない。したがって、文字列データ型を使用するのが望ましい。
コンテキスト変数の使用
キャンバス内のLiquidを使用する場所ならどこでも、コンテキスト変数を使用できる。例えばメッセージステップやユーザー更新ステップで「パーソナライゼーションを追加」を選択するだけでよい。
たとえば、次のフライトの前に、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.」

コンテキストステップの情報を使用して、パーソナライズされた遅延オプション を追加できます。つまり、ユーザーを遅延させる変数を選択できます。
アクションパスと終了条件について
これらのトリガーアクションでは、コンテキスト変数またはカスタム属性のいずれかを使用してプロパティフィルターの比較を活用できる。[カスタムイベントを実行] または [購入] のいずれかを選択できます。これらのアクショントリガーは、基本プロパティとネストされたプロパティの両方に対するプロパティフィルターもサポートしている。
- 基本プロパティとの比較では、利用可能な比較はカスタムイベントで定義されたプロパティの型に一致する。例えば、文字列プロパティは完全に一致する正規表現の一致を持つ。ブール値のプロパティは真か偽になる。
- ネストされたプロパティとの比較では、型は事前定義されていない。そのため、ブール値、数値、文字列、時刻、年の日数といった複数のデータ型にわたる比較を選択できる。これは階層化カスタム属性の比較と同様である。比較時に、ネストされたプロパティの実際のデータ型と一致しないデータ型を選択した場合、ユーザーはアクションパスや終了条件に一致しない。
アクションパスの例
カスタム属性の比較では、アクションが実行された時点でのカスタム属性値を使用する。これは、比較時にこのカスタム属性が設定されていない場合、またはカスタム属性の値が定義されたプロパティ比較と一致しない場合、ユーザーがアクションパスのグループに一致しないことを意味する。ユーザーがアクションパスステップに入った時点で条件に合致していた場合でも、この現象は発生する。
以下のアクションパスは、カスタムイベントを実行したユーザーを、基本Account_Createdプロパティをコンテキストsource変数に設定してソートするようにapp_source_variable設定されている。

以下のアクションパスは、特定の製品名に対する基本brandプロパティshoesをコンテキスト変数に一致させるpromoted_shoe_brandように設定されている。

終了基準の例
キャンバス内のユーザー行動において、以下のいずれかの条件を満たした場合、ユーザーはキャンバスから退出する。
- 彼らはカスタムイベント「カート放棄」を実行し、
- カート内の基本プロパティ「Item」は、コンテキスト変数の文字列値
cart_item_thresholdと一致する。

キャンバス内のユーザー行動において、以下のいずれかの条件を満たした場合、ユーザーはキャンバスから退出する。
- 彼らは「本」という商品名で特定の購入を行う。
- その購入のネストされたプロパティは、ユーザーのカスタム”loyalty_program”属性「VIP」と等しい。

コンテキスト変数フィルター
オーディエンスパスと条件分岐ステップでは、事前に宣言されたコンテキスト変数を使用するフィルターを作成できる。
コンテキスト変数フィルターは、オーディエンスパスと条件分岐ステップでのみ利用可能である。
コンテキスト変数はキャンバスのスコープ内で宣言され、アクセス可能となる。つまり、セグメント内では参照できない。コンテキスト変数フィルターは、オーディエンスパスと条件分岐ステップで同様の機能を持つ。オーディエンスパスステップは複数のグループを表し、条件分岐ステップは二値の決定を表す。

キャンバスのコンテキスト変数が事前定義された型を持つのと同様に、コンテキスト変数と静的値の比較ではデータ型が一致していなければならない。コンテキスト変数フィルターは、ブール値、数値、文字列、時刻、および年の日数といった複数のデータ型間で比較を可能にする。これは、階層化カスタム属性に対する比較と同様である。
コンテキスト変数と比較には同じデータ型を使え。例えば、コンテキスト変数が時間データ型の場合、時間比較(例えば「前」や「後」など)を使う。データ型の不一致(例えば、時間コンテキスト変数との文字列比較など)を使用すると、予期しない動作を引き起こす可能性がある。
「年の日数」と「時刻」のフィルタータイプを選ぶ場合:日付を含むコンテキスト変数をフィルターでフィルタリングする際は、その日付が毎年繰り返されるかどうかによって、適切な比較タイプを選択せよ。
- 毎年繰り返される日付(誕生日、記念日、クリスマスなどの祝日など)には「年の日数」を使用する。この比較タイプは、年の要素を無視し、その年の日数(1~365/366)に基づいて計算する。
- 日付が絶対日付で繰り返さない場合(契約終了日、予約日、サブスクリプションの更新日など)は「時間」を使用する。この比較タイプは、年を含む完全なタイムスタンプに基づいて計算する。
絶対日付に「年の日数」を使用すると、計算が年成分を無視するため、誤った結果や予期しない結果が生じることがある。例えば、4月の先物契約終了日を63日以内かどうか判断する場合、「年の日数」を使用すると誤った一致が生じる可能性がある。これは単に日付番号(119対359)を比較するだけで、実際には4月まで188日あることを考慮しないためだ。
一般的な指針:その日付は毎年繰り返されるのか?はい → 「年の日数」を使う。いいえ → 「時間」を使う。
コンテキスト変数フィルターの一例を示す。コンテキスト/braze/変数product_nameと正規表現を比較する。

コンテキスト変数やカスタム属性との比較
コンテキスト変数またはカスタム属性との比較トグルを選択することで、事前に定義されたコンテキスト変数やユーザーのカスタム属性と比較するコンテキスト変数フィルターを構築できる。これは、APIトリガーなどユーザーごとにダイナミックに比較を行う場合や、コンテキスト変数にcontextまたがって定義された複雑な比較ロジックを簡略化するのに有用である。
例えば、ユーザーがダイナミックな期間アプリを利用していない場合に、パーソナライズされたリマインダーを送信したい場合を考えてみよう。具体的には、過去3日間アプリにログインしていないユーザー全員にメッセージが届くようにするのだ。
コンテキスト変数があるre_engagement_date。{{now | minus: 3 | append: ' days'}}それはとして定義されている。注意せよ、3 daysは変数量であり、ユーザーのカスタム属性としても保存される。もし(ユーザープロファイルのカスタム属性として保存されている)last_login_dateがre_engagement_date()の後ろにある場合、そのユーザーにはメッセージが送信される。

以下のフィルターは、コンテキスト変数 がコンテキストreminder_date変数 より前にあるかどうかappointment_deadlineを比較する。これにより、オーディエンスパスステップ内のユーザーをグループ分けし、予約期限前に追加のリマインダーを受け取るべきかどうかを判断できる。

タイムゾーンの一貫性に関する標準化
キャンバスでは、タイムスタンプ型を使用するイベントプロパティの大半は既にUTCで管理されているが、例外も存在する。Canvas Contextの追加により、アクションベースのキャンバスにおけるすべてのデフォルトのタイムスタンプイベントプロパティは、一貫してUTCで表示されるようになる。この変更は、キャンバスのステップやメッセージを編集する際の操作性をより予測可能で一貫性のあるものにするための、より広範な取り組みの一環である。この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかに関わらず、すべてのアクションベースのキャンバスに影響を与えることに注意せよ。
いかなる状況においても、タイムスタンプを希望のタイムゾーンで表現するには、Liquidtime_zoneフィルターを使用することを強く推奨する。このよくある質問は、コンテキストステップの記事で例として参照できる。
GitHub でこのページを編集