BrazeとSegment CDP イベントスキーマ設計とファン行動計測の始め方

現代のマーケティングにおいて、顧客の「熱狂（ファン度）」を定量化し、それをリアルタイムなコミュニケーションに繋げることは、LTV（顧客生涯価値）向上の至上命題です。その中核を担うのが、カスタマーエンゲージメントプラットフォームのBrazeと、カスタマーデータプラットフォーム（CDP）のSegmentの組み合わせです。

しかし、単にツールを導入しただけでは、ファン行動の計測は実現しません。多くの現場で「どのようなデータを」「どのタイミングで」「どのような形式で」送るべきかというイベントスキーマ設計がボトルネックとなっています。本記事では、IT実務担当者の視点から、BrazeとSegmentを連携させ、ファン行動を正確に計測するための設計指針を徹底解説します。

BrazeとSegmentを連携させる「真の目的」

Brazeは、プッシュ通知、メール、アプリ内メッセージなどを駆使し、高度なパーソナライズメッセージを送ることに特化しています。一方で、データの収集・加工・統合については、外部のデータソースに依存する設計思想を持っています。

なぜ「直接実装」ではなくSegmentを介するのか

BrazeのSDKを直接アプリやWebに埋め込むことも可能ですが、Segmentを経由させることで以下のメリットが得られます。

• データの一貫性: Segmentに一度送れば、Brazeだけでなく、Google AnalyticsやBigQuery、その他の広告媒体へも同じ定義のデータを配信できます。
• 実装負荷の軽減: 複数のSDKを管理する手間が省け、コードがクリーンになります。
• データガバナンス: Segmentの「Protocols」などの機能を用い、設計したスキーマに合わない不正なデータを遮断できます。

Brazeのポテンシャルを左右する「イベントスキーマ」の定義

Brazeにおけるコミュニケーションのトリガーは、その多くが「イベント（Custom Events）」です。例えば、「商品を3回閲覧したファンに対してクーポンを送る」という施策を行う場合、Segment側で Product Viewed イベントが正しく、かつ十分なメタ情報（カテゴリ、価格など）を伴ってBrazeに届いていなければなりません。

データ基盤が整っていない状態で高機能なMAツールを導入しても、結果として「全配信」に近い運用に陥るケースが散見されます。これを防ぐためには、上流のデータ設計が不可欠です。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

SegmentからBrazeへのデータマッピング：基本の4要素

SegmentからBrazeへデータを送信する際、主に使われる4つのAPIメソッドがあります。それぞれの役割を正しく理解することが、設計の第一歩です。

Identify：ユーザーの特定と属性（Attributes）の同期

identify メソッドは、「誰が」そのユーザーであるかを特定し、その人物の属性情報を記録します。Segmentで実行された identify は、Brazeの User Attributes（カスタム属性） として反映されます。

analytics.identify('user_id_12345', {
name: '田中 太郎',
email: 'tanaka@example.com',
membership_level: 'Platinum',
total_purchase_count: 50
});

Brazeでは、これらの属性を用いて「セグメント（配信対象者の抽出）」を作成します。

Track：ファン行動（Events）の捕捉とプロパティ

track メソッドは、「何をしたか」という行動を記録します。これはBrazeの Custom Events に対応します。

analytics.track('Article Completed', {
title: 'Braze活用ガイド',
category: 'Tech',
word_count: 15000
});

重要なのは、Brazeにおいてイベントは「トリガー（配信のきっかけ）」として機能する点です。特定の行動直後にメッセージを送る、あるいは過去30日間に特定の行動をX回以上行ったユーザーを抽出するといった運用が可能になります。

Group：B2Bや組織単位の管理

SaaSやB2Bビジネスの場合、個人だけでなく「会社（Account）」単位での管理が必要です。Segmentの group メソッドを用いることで、Braze上でも企業単位の属性管理が可能になります。ただし、Brazeは基本的にB2C（個人軸）のツールであるため、組織単位のデータは「User Attribute」としてフラットに持たせる設計が一般的です。

Alias：既存ユーザーと匿名ユーザーの紐付け

ログイン前の匿名ユーザーの行動と、ログイン後の特定ユーザーの行動を紐付ける際に利用します。Brazeの alias 機能とSegmentの alias は挙動が異なる場合があるため、Braze Destinationの設定で「Automatically merge anonymous users」などのオプションを確認する必要があります。

【実務編】ファン行動を計測するイベントスキーマ設計ガイド

「ファン行動」とは、単なる「購入」や「ログイン」だけではありません。そのブランドを愛用しているからこそ発生する「深掘りされた行動」を定義し、計測する必要があります。

命名規則（Naming Convention）の標準化：Object-Actionフレームワーク

イベント名が clicked_button や send_data のような曖昧なものになると、Braze側でセグメントを作成する際に混乱を招きます。Segmentが推奨する Object + Action の形式を採用しましょう。

• Order Completed（注文完了）
• Content Favorited（お気に入り登録）
• Community Post Created（投稿作成）

「ファン」を定義するための重要プロパティ設計

Brazeで高度な条件分岐（Liquidを用いた動的表示など）を行うには、イベントに付随するプロパティの設計が肝です。

WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ

Braze × Segment 連携設定のステップバイステップ

実務的な設定手順を解説します。設定を誤ると、データの欠落や意図しないコスト増につながります。

1. Segment側でのBraze Destination設定

Segmentの管理画面から「Destinations」を選択し、「Braze」を検索して追加します。この際、Brazeのインスタンス（例：US-01, EU-02など）を選択する必要があります。これはBrazeのダッシュボードURLから確認可能です。

2. Connection Modeの選択（Cloud-mode vs Device-mode）

ここが実務上の最大の分岐点です。

• Cloud-mode: SegmentサーバーからBraze APIへデータを飛ばします。アプリのサイズを軽量に保てますが、Brazeのアプリ内メッセージやプッシュ通知の「自動計測」機能の一部が制限される場合があります。
• Device-mode: BrazeのSDKをSegment経由でクライアントサイドにロードします。Brazeの全機能を利用可能ですが、アプリのバイナリサイズが増加します。

推奨事項: アプリ内メッセージやプッシュ通知を主軸にする場合は、Device-modeを選択するのが一般的です。

3. Braze側でのAPIキー発行とエンドポイント確認

Brazeの「Developer Settings」から、Segment専用のAPIキー（Rest API Key）を発行します。この際、必要なパーミッション（ users.track, users.identify など）を過不足なく付与してください。

高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例

よくあるエラーとトラブルシューティング

連携運用が始まると、必ずと言っていいほどデータ整合性の問題が発生します。

ユーザーが統合されない（Internal IDの不一致）

Segmentの userId と、Brazeの external_id が一致していないケースです。Brazeは external_id をもとにユーザーを一意に識別します。Segmentの identify メソッドで渡すIDが、バックエンドのDBのプライマリキーと一致しているか、各プラットフォーム（iOS/Android/Web）で共通化されているかを再確認してください。

属性値が更新されない（データ型の不一致）

例えば、当初「数値（Integer）」として送っていた total_points を、誤って「文字列（String）」で送ってしまうと、Braze側で正しく処理されなかったり、フィルタリングが効かなくなったりします。Brazeのデータ型は一度定義されると厳格に扱われるため、Segmentのプロトコル機能で型チェックを行うのが安全です。

API制限（Rate Limits）によるデータ損失の防ぎ方

BrazeにはAPIエンドポイントごとにレートリミットが存在します。大量のユーザーデータを一括で identify したり、バッチ処理で数百万の track イベントを投げると、一部が429エラーで拒否される可能性があります。Segment側でリトライ機能が働きますが、根本的な解決にはBrazeの「Data Volatility」を理解し、不要なイベント（例：スクロール率など）をBrazeに送らないよう、Segment側のフィルタ機能（Destination Filters）で絞り込むことが肝要です。

まとめ：データ基盤を「施策のエンジン」に変えるために

BrazeとSegmentの連携は、強力なマーケティング基盤を構築する最短ルートの一つです。しかし、その真価は「いかにきれいなデータが流れているか」にかかっています。初期のスキーマ設計を疎かにせず、以下の3点を意識して運用を開始してください。

1. ビジネスゴールから逆算したイベント定義: 「どの行動がファン化のサインか」を明確にする。
2. 厳格なドキュメンテーション: SegmentのSpecをベースに、社内の共通言語としてイベント名を管理する。
3. 段階的な拡張: 最初から全データを送るのではなく、施策に必要なデータから順次連携を広げる。

正確なデータに基づくリアルタイムな体験提供こそが、ユーザーを真のファンへと変える唯一の道です。実装に関する最新の仕様は、必ず Braze公式ドキュメント および Segment公式ドキュメント を参照してください。