Braze Liquidパーソナライズ 会員ランク・推し情報を扱うときのデータ設計注意点

Brazeを活用したCRM戦略において、読者の属性に合わせたパーソナライズは「開封率」や「コンバージョン率」を劇的に改善するエンジンとなります。しかし、その根幹を支えるLiquid（リキッド）の記述と、基盤となるデータ設計が噛み合っていなければ、意図しないメッセージの誤配信や、膨大なデータポイント消費によるコスト増大を招くことになります。

特に「会員ランク」のような単一のステータスと、「推し（お気に入り）」のような複数選択、あるいは変動の激しい情報をBrazeでどう扱うべきか。本記事では、日本国内のエンターテインメント・EC・サービス業の現場で求められる、実務的なデータ設計とLiquidの実装手順を詳しく解説します。

Brazeパーソナライズの鍵は「Liquid」と「データ設計」の同期にある

Brazeのメッセージング（Push通知、アプリ内メッセージ、メール）で動的な情報を差し込む際、使用されるのがオープンソースのテンプレート言語「Liquid」です。LiquidはBraze内の「ユーザープロフィール」にあるカスタム属性（Custom Attributes）や、イベントに含まれるプロパティをリアルタイムに参照します。

ここで重要なのは、「Liquidで何ができるか」ではなく「Liquidで処理しやすいデータ形式でBrazeに格納されているか」という視点です。例えば、会員ランクによって特典画像を変える場合、Braze側にランク名だけを送るのか、あるいは画像URLそのものを属性として送るのかによって、マーケターの運用負荷とLiquidの複雑性は大きく変わります。

会員ランクの実装：単一属性の「Custom Attributes」設計

会員ランクは、一人のユーザーに対して「一つの値」が確定する属性です。これはBrazeの「Custom Attributes（カスタム属性）」として管理するのが最適です。

ランク情報を「文字列」で持つか「数値」で持つか

ランク名を "Gold", "Silver" といった文字列で保持するのが一般的ですが、Liquidでの条件分岐を効率化するために「ランクスコア（数値）」を併用することをおすすめします。

• 文字列型 (String): rank_name: "Gold" → 直感的に分かりやすいが、ランクの上下関係をLiquidで判定（例：シルバー以上なら表示）する際に、複数の or 条件が必要になり、コードが冗長化します。
• 数値型 (Integer): rank_level: 3 → {% if {{custom_attribute.${rank_level}}} >= 2 %} と記述することで、ランクの上下関係を数式で処理でき、保守性が高まります。

ランクアップ・ダウンのフラグ管理とトリガー設定

会員ランクの変更をトリガーにキャンペーン（Canvas）を動かす場合、単に属性を上書きするだけでなく、「ランクアップイベント」をカスタムイベントとして発行する設計が必要です。BrazeのCanvasは属性の変更をトリガーにできますが、変更前後の値を比較して「ランクが上がったときだけ送る」という処理は、カスタムイベントをトリガーにした方が設計がシンプルになります。

【Liquidサンプル】ランク別メッセージの出し分け

以下は、会員ランクに応じて挨拶文とバナーを切り替えるLiquidの基本形です。

{% assign rank = {{custom_attribute.{rank_name}}} %}
{% case rank %}
{% when 'Gold' %}
いつもご利用ありがとうございます、ゴールド会員の{{{first_name}}}様！
<img src="https://example.com/images/gold_banner.jpg">
{% when 'Silver' %}
シルバー会員の{{{first_name}}}様へ、今月のおすすめ情報です。
&lt;img src="[https://example.com/images/silver_banner.jpg](https://example.com/images/silver_banner.jpg)"&gt;
{% else %}
{{{first_name}}}様へ、新着アイテムのご案内。
{% endcase %}

このように、会員ランクのような確定的なステータスは case 文を用いると可読性が向上します。しかし、より複雑なデータ統合を検討している場合は、事前に基盤側の設計を固めておくべきです。例えば、高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定 の記事で解説しているようなデータパイプラインを構築しておくことで、Brazeへのランク反映を自動化・正確化できます。

「推し」情報の管理：複数選択（Array）とネスト構造の注意点

エンタメ業界やファッションECで「お気に入りキャラクター」「フォロー中のブランド」などを扱う際、データは1つではなく「配列（Array）」になります。

カスタム属性における「配列」の限界とデータポイント消費

Brazeのカスタム属性には「文字列の配列」を格納できます。しかし、以下の制限に注意してください。

• 配列の要素数制限: 公式ドキュメントによれば、配列の要素数はデフォルトで制限はないものの、属性全体のサイズ（ペイロード）が大きすぎると、APIのパフォーマンスに影響します。
• データポイント: 配列内の要素を1つ追加・削除するたびに、そのユーザープロフィールの更新としてデータポイントを消費します。頻繁に更新される「お気に入り」情報をすべて配列で同期し続けるのは、コスト面で不利になる場合があります。

複数推しの中から「最推し」を特定する設計

「推し」が複数いる場合、メッセージの件名には「最推し」の名前を入れたいという要望がよくあります。この場合、配列とは別に primary_fav_artist のような単一の属性を持たせるのが、Liquidの処理を軽くするコツです。Liquid内で配列をループ（for文）して特定条件に合うものを探す処理は、メッセージ送信の負荷（オーバーヘッド）を高めるからです。

【Liquidサンプル】配列データを用いた動的コンテンツ生成

ユーザーがフォローしているブランド（配列名：followed_brands）の中に「Apple」が含まれている場合のみ、特定のオファーを表示するコードです。

{% assign brands = {{custom_attribute.${followed_brands}}} %}
{% if brands contains 'Apple' %}
Apple製品をお持ちの方へ、特別なアクセサリーセールのお知らせです。
{% endif %}

このように contains 演算子を使うことで、配列内の特定の値を簡易的にチェックできます。ただし、属性名や値に日本語（マルチバイト文字）が含まれる場合は、エンコーディングに注意が必要です。公式の Braze Liquid Documentation を参照し、利用可能なフィルタを確認してください。

データ連携手法の比較：SDK・API・リバースETL

Brazeにパーソナライズ用のデータを送る方法は、主に3つあります。目的と更新頻度によって使い分けます。

特に、広告配信と連動させたパーソナライズを行う場合は、広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ で紹介しているような、データ基盤からの一括連携（リバースETL）が、整合性とコストのバランスを最もとりやすい手法となります。

実務で直面する「Liquidエラー」と回避策

Brazeの運用で最も避けたいのが、Liquidの記述ミスによる「{{…}}」という文字列がそのままユーザーに届いてしまう事態です。

データが「null」の場合のフォールバック設定

カスタム属性に値が入っていない（null）ユーザーに対しては、デフォルト値を設定するのが鉄則です。Liquidの default フィルタを活用しましょう。

こんにちは、{{${first_name}}}様。

こんにちは、{{${first_name} | default: 'お客様'}}様。

文字数制限とエンコーディングの罠

Push通知の「タイトル」や「本文」には文字数制限があります。Liquidで動的に長い文字列（例：推しのフルネームなど）を流し込むと、最も重要な「お得な情報」が末尾で切れてしまうことがあります。truncate フィルタを使って、最大文字数を制限する処理を推奨します。

{{custom_attribute.${primary_fav_artist} | truncate: 10}} の最新情報！

また、LINEなどの外部メッセージチャネルと連携する場合は、さらに特有の制約が加わります。LINE データ基盤から直接駆動する「動的リッチメニューとキャンペーンモジュール」のアーキテクチャ で解説している通り、BrazeからLINEへ渡すデータ形式も、Liquid側で正しくハンドリングしなければなりません。

まとめ：スケーラブルなパーソナライズ基盤を構築するために

Brazeを用いたパーソナライズは、単なる「名前の差し込み」を越え、会員ランクや推し情報に基づいた「体験の最適化」へと進化しています。その成功のためには、以下の3点を意識した設計が不可欠です。

1. Liquidの負担を減らす: 複雑な計算や判定は、Brazeに送る前のデータ基盤（BigQuery等）側で処理し、Brazeには「判定済みの値」を送る。
2. 属性の型を使い分ける: 比較が必要なものは数値型、複数のフラグが必要なものは配列型、表示用の名前は文字列型と、用途を明確にする。
3. フォールバックを忘れない: データは常に「欠損している可能性がある」という前提で、Liquidのdefault値を設定する。

データ設計を疎かにしたままLiquidのテクニックだけで解決しようとすると、将来的にメッセージのパーソナライズパターンが増えた際に、管理不能な「スパゲッティコード」と化してしまいます。本記事で紹介した設計思想をベースに、自社のビジネスモデルに最適化したデータ構造を構築してください。

Brazeの導入費用や詳細な仕様については、公式の料金ページ を確認し、自社のデータポイント消費予測と照らし合わせて検討することをお勧めします。