Braze Currents データエクスポートとDWH連携 施策効果分析のパイプライン設計

カスタマーエンゲージメントプラットフォーム「Braze」を導入した企業が、次に直面する課題が「データのサイロ化」です。Brazeの管理画面内でも開封率やクリック率は確認できますが、それらの行動が最終的に店舗での購入やLTV（顧客生涯価値）にどう寄与したかを可視化するには、自社のデータウェアハウス（DWH）との連携が不可欠です。

本記事では、Brazeが提供する高頻度データエクスポート機能「Braze Currents」を活用し、Google BigQueryやSnowflakeといったDWHへデータを統合するためのパイプライン設計を、実務的な視点で徹底解説します。

Braze Currentsを活用したデータ統合の重要性

Braze Currentsは、Braze内で発生するあらゆるイベントデータを、外部のストレージやDWHへほぼリアルタイムに自動転送する機能です。通常、MAツールやCRMツールからのデータ抽出はAPIを介して行われますが、数百万ユーザー規模のイベントデータをAPIで逐次取得するのは、レートリミットや保守コストの面で現実的ではありません。

Braze内部分析と外部DWH連携の違い

Brazeのダッシュボードは非常に優秀ですが、あくまで「Braze内での完結した行動」の集計に特化しています。外部DWHにデータを出すことで、以下のような高度な分析が可能になります。

• クロスチャネル分析：アプリ内メッセージを見たユーザーが、その後LINEや実店舗でどのような行動をとったかの紐付け。
• アトリビューション分析：どのキャンペーンが、どの程度のリードタイムを経てコンバージョンに寄与したかの算出。
• 機械学習への活用：エクスポートした生の行動ログを学習データとして使い、独自のレコメンドエンジンや離脱予測モデルを構築。

こうしたデータ活用の基盤として、BrazeとDWHをシームレスにつなぐ「パイプライン」の設計が、マーケティングDXの成否を分けます。特に複雑なデータ構造を持つLINE等のチャネルを併用する場合、共通のIDで名寄せを行うデータ基盤が重要となります。このあたりの全体像については、以下の記事が参考になります。

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

Brazeデータ出力手法の比較（API vs Currents）

Brazeからデータを取得する方法には、主に「User API」「Export API」「Currents」の3種類があります。実務において、これらをどう使い分けるべきか比較表にまとめました。

結論として、「過去のすべてのユーザー行動をSQLで分析したい」というニーズであれば、Currentsの導入が必須となります。逆に、特定のユーザーの最新ステータスだけを知りたい場合はAPIで十分です。

Currents連携先（DWH・ストレージ）の選定ポイント

Currentsは多くの出力先に対応しています。選定にあたっては、自社の既存インフラとの親和性が最も重要です。

• Google BigQuery：Google Cloudを利用している場合、最も設定が容易でクエリ速度も速い。パーティション分割テーブルが自動作成されるメリットがあります。
• Snowflake：マルチクラウド対応が強み。BrazeからのデータをS3等に一度置き、Snowpipeで自動取り込みする構成が一般的です。
• Amazon S3 / Google Cloud Storage：RAWデータをそのままアーカイブしたい場合や、独自のETL処理を挟みたい場合に選択します。

特に広告運用とのシナジーを考えるなら、Google Cloud（BigQuery）への統合は強力な選択肢になります。コンバージョンAPI（CAPI）との連携による広告最適化など、Currentsデータを「攻め」の施策に転用できるからです。

広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

【実践】Braze Currents × BigQuery 連携パイプラインの構築手順

ここからは、実務で最も要望の多い「BigQuery」への連携手順を解説します。作業は「Google Cloud側」と「Braze側」の両方で行います。

Step 1: Google Cloud側の準備

1. プロジェクトの作成/選択：データを蓄積するプロジェクトを選択します。
2. データセットの作成：Brazeデータ専用のデータセットを作成します（例：braze_currents_raw）。
3. サービスアカウントの作成：BrazeがBigQueryに書き込むための権限を持つサービスアカウントを作成します。
   • 必要なロール：BigQuery Data Editor, BigQuery Job User
4. JSONキーの生成：作成したサービスアカウントの「鍵」を発行し、JSONファイルをダウンロードしておきます。

Step 2: Braze管理画面でのCurrents設定

1. Braze左メニューの「Currents」を選択。
2. 「Create New Current」をクリックし、出力先に「Google BigQuery」を選択。
3. Integration Detailsの入力：
   • Google Cloud Project ID
   • Dataset ID
   • Step 1で取得したサービスアカウントのJSONキーの内容をペースト
4. Event Selection（イベント選択）：転送したいイベントにチェックを入れます。
   • Message Engagement（配信、開封、クリックなど）
   • User Behavior（カスタムイベント、購入、アプリインストールなど）
5. 「Launch Current」で開始。

注意：一度Currentsを起動すると、Braze内の全ユーザーの該当ログが流出開始します。BigQueryのストレージコストに影響を与えるため、不要なイベント（例：頻繁に発生しすぎる特定のカスタムイベント）はチェックを外しておくことが運用上のポイントです。

エクスポートデータの種類とデータ活用（スキーマ解説）

Currentsで送られるデータは、イベントの種類ごとにテーブルが分かれます（BigQueryの場合）。代表的なテーブルとその意味を理解しておくことで、SQLでの分析がスムーズになります。

1. メッセージエンゲージメント・イベント

プッシュ通知、メール、アプリ内メッセージなどの反応を記録します。

• users_messages_send：メッセージが送信された記録。
• users_messages_open：開封（メールやアプリ内メッセージ）。
• users_messages_click：メッセージ内のリンククリック。
• users_messages_bounce：メール等の不達。リストのクレンジングに必須。

2. ユーザー行動イベント

SDKを通じてBrazeに送られたアクションの生ログです。

• users_behaviors_customevent：アプリやWebでの特定アクション。
• users_behaviors_purchase：購入ログ。price や currency カラムを含みます。

これらのデータには必ず user_id (または external_user_id) が含まれています。これをキーにして、社内の顧客マスタと結合することで、「Aというキャンペーンメールをクリックしたユーザーが、3日後に店舗で購入したか」を判定できるようになります。名寄せやID統合の詳細については、こちらの記事も参考にしてください。

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

施策効果分析のためのデータモデリング設計

Currentsから届くRAWデータ（生データ）は、そのままでは分析しにくい構造をしています。例えば、タイムスタンプがUnix時間であったり、特定のプロパティがJSONの文字列内にネストされていたりします。そこで、dbt（data build tool）などを用いた「データ変換」の工程を挟むのがモダンな設計です。

dbtを活用した変換の例

RAWデータのテーブルから、以下のような「分析用マート」を定義します。

• fact_daily_engagements：ユーザー×日単位での開封・クリック・コンバージョンをまとめたフラットなテーブル。
• dim_campaign_performance：キャンペーンIDごとのコスト、送信数、開封率、直接売上をまとめた集計テーブル。

このように、「高額なCDP」を導入せずとも、BigQueryとdbt、そしてBraze Currentsを組み合わせることで、自社に最適化されたデータ基盤を構築することが可能です。これは「モダンデータスタック」と呼ばれる手法であり、コストパフォーマンスに優れています。

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

運用時の注意点とコスト管理

最後に、Currentsを安定運用するための実務的なポイントを3点挙げます。

1. エラー監視と再試行

サービスアカウントの権限不足やDWH側の不具合で、データの書き込みが失敗することがあります。Braze管理画面の「Currents Alert」の設定を有効にし、失敗時にSlack等へ通知が飛ぶようにしておきましょう。なお、Braze側でデータが一定期間（通常数日間）保持され再試行されますが、それ以降はデータが消失するリスクがあるため早期対応が必要です。

2. DWH側のコスト増大への対策

Currentsは大量のデータを流し込みます。特にBigQueryの場合、ストリーミング・インサート料金が発生します。また、何も考えずに SELECT * で全期間のログをスキャンすると、分析コストが跳ね上がります。必ず time カラム等によるパーティション分割を利用し、必要な期間のみをスキャンするようにSQLを記述してください。

3. データ削除（GDPR/CCPA/改正個人情報保護法）への対応

ユーザーからデータ削除依頼があった場合、Braze内のデータだけでなく、CurrentsでエクスポートしてDWHに蓄積されたデータも削除する必要があります。user_id をキーに、特定ユーザーのレコードを一括削除できるスクリプトや運用フローを事前に決めておきましょう。

Braze Currents の Snowflake / Redshift / Databricks 連携パターン

BigQuery 以外の DWH への連携も Braze Currents は標準サポートしています。組織で既に利用している DWH に応じた連携パターンを整理します。

Snowflake への連携

• 連携方式：S3 / Azure Blob / GCS への Avro / Parquet 形式出力 → Snowflake Snowpipe で自動取り込み
• 典型遅延：5〜15分のニアリアルタイム取り込み
• 注意点：Snowflake Snowpipe のクレジット消費（GB単位）と、Braze Currents の Tier 課金（イベント量）を両方コスト試算
• 適合：マルチクラウド戦略・グローバル展開・データシェアリング重視の組織

Amazon Redshift への連携

• 連携方式：S3 → Redshift COPY コマンド（自動 or 手動）
• 典型遅延：S3 への出力は数分、Redshift 取り込みは設定次第（5〜60分）
• 注意点：Redshift Spectrum 経由で S3 を直接参照する選択肢もあり（コピー不要）
• 適合：AWS 中心の組織・既存 Redshift 投資があるケース

Databricks への連携

• 連携方式：S3 / ADLS Gen2 / GCS への Parquet 出力 → Databricks の Auto Loader / Delta Lake
• 典型遅延：ストリーミング処理で1〜5分の超低遅延
• 注意点：Delta Lake のスキーマ変更追従が標準で、Braze スキーマの追加にも自動対応
• 適合：ML/AI ワークロードと統合した分析、レイクハウス戦略

連携方式の選定マトリクス

Braze Currents のエクスポートスキーマ詳細

「Braze Currents で出力されるデータはどんな構造か」を理解することで、DWH 側の分析設計が立てやすくなります。主要イベント種別のスキーマを整理します。

1. メッセージング系イベント（messaging_engagement.*）

• email_sent_event：メール送信時の記録（送信時刻・キャンペーンID・メッセージ変種・受信者属性）
• email_opened_event：メール開封（開封時刻・受信者ID・キャンペーンID）
• email_clicked_event：メールリンククリック（クリック URL・遷移先）
• email_unsubscribed_event：配信停止
• push_notification_sent_event：プッシュ通知送信
• push_notification_opened_event：プッシュ通知タップ
• in_app_message_sent_event / opened_event：アプリ内メッセージ
• sms_sent_event / sms_delivered_event：SMS 送信・到達

2. ユーザー行動系イベント（user_behavior.*）

• users_behaviors_session_started_event：アプリ・サイトセッション開始
• users_behaviors_purchase_event：購入イベント（商品・金額・通貨）
• users_behaviors_custom_event：カスタムイベント（事業者が定義する任意の行動）
• users_behaviors_app_first_session_event：初回起動

3. ユーザー属性変更（users_messages.*）

• users_messages_email_subscription_event：メール購読状態変化
• currents_changed_event：属性変更履歴

実際の分析 SQL クエリサンプル（BigQuery 例）

Braze Currents を BigQuery に取り込んだ後の、定番の分析クエリを共有します。

クエリ1：キャンペーン別の配信効果サマリ

WITH sent AS (
  SELECT campaign_id, COUNT(*) AS sent_count
  FROM `project.braze.email_sent`
  WHERE DATE(_PARTITIONTIME) >= '2026-04-01'
  GROUP BY campaign_id
),
opened AS (
  SELECT campaign_id, COUNT(DISTINCT external_user_id) AS opened_users
  FROM `project.braze.email_opened`
  WHERE DATE(_PARTITIONTIME) >= '2026-04-01'
  GROUP BY campaign_id
),
clicked AS (
  SELECT campaign_id, COUNT(DISTINCT external_user_id) AS clicked_users
  FROM `project.braze.email_clicked`
  WHERE DATE(_PARTITIONTIME) >= '2026-04-01'
  GROUP BY campaign_id
)
SELECT
  s.campaign_id,
  s.sent_count,
  o.opened_users,
  c.clicked_users,
  ROUND(o.opened_users * 100.0 / s.sent_count, 2) AS open_rate,
  ROUND(c.clicked_users * 100.0 / o.opened_users, 2) AS ctr
FROM sent s
LEFT JOIN opened o ON s.campaign_id = o.campaign_id
LEFT JOIN clicked c ON s.campaign_id = c.campaign_id
ORDER BY s.sent_count DESC;

クエリ2：配信後の購入転換率（アトリビューション分析）

-- メール送信後 7日以内に購入したユーザーの転換率
WITH email_recipients AS (
  SELECT external_user_id, campaign_id,
         MIN(time) AS email_sent_at
  FROM `project.braze.email_sent`
  WHERE DATE(_PARTITIONTIME) BETWEEN '2026-04-01' AND '2026-04-30'
  GROUP BY external_user_id, campaign_id
),
purchases AS (
  SELECT external_user_id, time AS purchase_time, product_id, price
  FROM `project.braze.users_behaviors_purchase`
  WHERE DATE(_PARTITIONTIME) BETWEEN '2026-04-01' AND '2026-05-07'
)
SELECT
  r.campaign_id,
  COUNT(DISTINCT r.external_user_id) AS recipients,
  COUNT(DISTINCT p.external_user_id) AS purchasers,
  ROUND(COUNT(DISTINCT p.external_user_id) * 100.0 / COUNT(DISTINCT r.external_user_id), 2) AS conversion_rate,
  SUM(p.price) AS total_revenue
FROM email_recipients r
LEFT JOIN purchases p
  ON r.external_user_id = p.external_user_id
  AND p.purchase_time BETWEEN r.email_sent_at AND TIMESTAMP_ADD(r.email_sent_at, INTERVAL 7 DAY)
GROUP BY r.campaign_id
ORDER BY total_revenue DESC;

Braze Currents コスト最適化の実務テクニック

Braze Currents はイベント量に応じて Tier 課金されるため、活用度が増すほどコストが膨らみます。実プロジェクトで使える6つの最適化テクニックを共有します。

レバー1：出力イベントの絞り込み

「全イベントを Currents で出す」と1日数千万件になることも。活用予定のイベントだけ選択的に出力することで、Currents コストを半減できます。

レバー2：DWH側のパーティション設計

取り込み先 BigQuery / Snowflake で日付パーティション + ユーザーIDクラスタリングを施せば、分析クエリのスキャン量を90%以上削減可能。

レバー3：マテリアライズドビュー化

「日次のキャンペーン別配信効果サマリ」などの定型クエリは、毎日1回計算するマテリアライズドビューにして、BIツール側はそこを参照。日次クエリ数を圧倒的に削減。

レバー4：データのライフサイクル管理

過去2年以上経過した Currents データは、低コストのアーカイブストレージ（BigQuery Long-term Storage / S3 Glacier）に自動移動。容量コストを大幅削減。

レバー5：dbt によるデータ変換最適化

Currents の生データをdbt modelで日次変換し、分析用に整形した中間テーブルに集約。BIツールが生データを直接参照しない構成にする。

レバー6：Reverse ETL とのループ最適化

DWH で計算したセグメントを Braze に戻す（Reverse ETL）際、頻度・対象を最適化。「リアルタイム配信が必要なセグメント」と「日次バッチで十分なセグメント」を分けて運用。

Braze Currents 運用上の落とし穴と対策

落とし穴1：スキーマ変更の自動追従

Braze は年に数回スキーマを更新するため、自動取り込みパイプラインが破綻することがあります。dbt のテストまたはDataform の Assertionでスキーマ変更を即座に検知する設計が必須。

落とし穴2：イベント漏れの監視

Currents エクスポートが何らかの理由で停止した場合、データ欠損に気づくのが遅れる。日次のイベント数を Looker Studio で可視化し、前日比 -50%以上の異常を自動アラート。

落とし穴3：個人情報の取り扱い

Braze には個人情報（メール・電話番号・氏名）が含まれます。DWH に出力する際のPII マスキングとBI ユーザーへの権限分離を設計時に組み込む。

落とし穴4：GDPR / CCPA / 改正個人情報保護法対応

退会者・削除依頼者の Currents データを、DWH 側でも物理削除する必要があります。退会→Braze→Currents→DWH 削除の連鎖フローを初期から設計。

関連ガイド・クラスター

• Braze 完全ガイド：CRM/CDP/MA連携・Currents活用・3業種事例 — Braze 全体像
• BigQuery 完全ガイド：Snowflake/Redshift比較・業界別導入・コスト最適化
• データ統合コストを下げるETLツール比較
• CDP導入完全ガイド：顧客体験革新・MA シナリオ
• 【ピラー】BigQuery／モダンデータスタック完全ガイド

まとめ：Brazeを「配信ツール」から「データ中核」へ進化させる

Braze Currentsは、単なるデータ転送機能ではありません。Brazeを「施策を実行するだけのツール」から「顧客の熱量をリアルタイムに把握するセンサー」へと進化させるための鍵です。DWHと連携し、施策結果をSQLで深掘りできる環境を整えることで、マーケティングのPDCAは劇的に高速化します。

「高額なツールを買ったけれど、効果測定が曖昧で改善が進まない」という状況を打破するために、まずはCurrentsによるパイプライン設計から着手してみてはいかがでしょうか。設定に関する詳細は、Brazeの公式ドキュメント（Braze User Guide）も併せてご確認ください。