Brazeに不動産業向けの反響項目が標準で用意されていますか？

この記事では、そのような前提を置きません。反響受付や来場予約は、不動産会社が自社業務に合わせて定義するスキーマ例です。Braze固有の標準項目やネイティブ連携機能として紹介しているものではありません。

顧客IDにはメールアドレスを使ってよいですか？

変更や共有が起きる値を、そのまま恒久的な主キーにするのは避けます。既存の顧客管理側で一人に一つ発行し、変更履歴を管理できるIDを候補にし、Brazeへ渡すexternal_idとの対応を固定します。

API連携を始めれば反響データは自動で同期されますか？

APIの存在だけで自動同期にはなりません。送信元、送信時点、再送条件、更新方向、失敗時の担当を自社で決め、実装とテストを行う必要があります。この記事はその前段の判断項目だけを扱います。

不動産会社がBraze API連携前に決めるデータ境界｜顧客ID・反響イベント・更新責任

反響がポータル、来場予約が予約表、顧客情報がCRMにある状態で、先にAPI接続を始めると、「どの顧客の、どの出来事が正しいのか」を後から決めることになります。結果として、同じ顧客が複数に分かれたり、予約変更が古い値で上書きされたり、エラーを誰も確認しなかったりします。

先に決めるのは接続方法ではなく、正本、送る範囲、ID、イベントの発生時点、更新と失敗の責任です。SUUMO側とのデータ授受を検討している場合はSUUMO API連携前の確認事項、顧客データが複数部署に分かれている場合は不動産会社のデータ分断を解消する手順を先に切り分けてください。

正本と転送先を一行ずつ決める

Brazeをすべての情報の正本にする必要はありません。顧客管理、反響受付、予約管理で、最初に値を確定する場所を一つずつ決めます。Brazeへ渡すのは、その後のコミュニケーション判断に必要な値だけです。

情報	正本	Brazeへ渡す値	戻さない値
顧客識別	顧客管理システム	社内顧客ID	Braze側で生成された識別子
連絡先・同意	同意を取得・管理するシステム	許可された連絡先と状態	目的外の属性や社内メモ
反響	反響を最初に受けたシステム	受付時点、経路、対象の管理用ID	自由記述の全文や不要な個人情報
来場予約	予約を確定するシステム	予約・変更・取消の発生時点	担当者の非公開メモ

この表の「反響」と「来場予約」は、本記事が示す編集上のスキーマ例です。Brazeの標準フィールドや、不動産向け機能の名称ではありません。実際に何を渡すかは、自社の利用目的と同意範囲に合わせて決めます。

顧客IDの発行元と変更責任を固定する

Brazeの公式ドキュメントでは、external_idは送信するデータの対象となる利用者の一意な識別子であり、同じ利用者に複数のプロファイルを作らないため、SDKに設定する識別子と同じにするよう説明されています。

不動産会社側では、どのシステムが社内顧客IDを発行するかを決め、そのIDをexternal_idへ対応づけます。氏名、電話番号、メールアドレスは照合材料にはなっても、変更や共有が起きるため、単独で恒久的な主キーにしません。

仮顧客を本顧客へ統合するとき、どのIDを残すか。
同一人物の重複を見つけたとき、誰が統合を承認するか。
IDを変更したとき、対応表と再送履歴をどこに残すか。
IDがないデータを送信せず、どの一覧へ止めるか。

公式APIが扱えるものと、自社で決めるものを分ける

BrazeのAPIドキュメントでは、REST APIによって利用者を識別・追跡・管理でき、/users/trackでカスタムイベントの記録やユーザープロファイル属性の更新ができると説明されています。これは汎用的なAPI仕様です。不動産会社の反響や予約が、あらかじめ定義されているという意味ではありません。

また、利用するRESTエンドポイントは契約時に割り当てられたインスタンスに応じて異なり、APIキーには呼び出せるエンドポイントの権限を個別に設定できると案内されています。接続先と権限は推測せず、自社環境で承認された情報を実装担当へ渡します。

出典・Braze公式ドキュメント

Braze API documentation：ユーザーデータ、カスタムイベント、プロファイル属性を扱うREST APIの概要
Braze API overview：external_id、インスタンス別エンドポイント、APIキーの権限

イベント名は業務上の出来事と発生時点で決める

イベント名を「反響」「予約」のような名詞だけにすると、受付、変更、取消を区別できません。自社例として、出来事、確定条件、発生時点、重複判定に使うIDを一組にします。

編集上のイベント例	発生条件	時刻	重複防止
反響受付	受付元で一件として確定	受付システムの記録時刻	反響ID
来場予約確定	日時と拠点が確定	予約確定時刻	予約ID＋状態
来場予約変更	確定済み予約が更新	変更確定時刻	予約ID＋更新番号
来場予約取消	取消が確定	取消確定時刻	予約ID＋取消状態

この名称もBrazeネイティブの項目ではありません。実装時は自社の命名規則へ置き換え、送信前に業務責任者が意味を承認します。

更新とエラーの責任を同じ表に書く

連携処理が動くことと、データが正しいことは別です。項目ごとに更新方向を固定し、失敗を発見する人、元データを直す人、再送を承認する人を分けます。

元データ責任者：顧客ID、連絡先、同意、予約状態の誤りを修正する。
連携運用担当：未送信、拒否、重複、送信遅延を日次で確認する。
業務責任者：例外時に送る・止める・破棄する判断を承認する。
実装担当：失敗理由、対象ID、発生時刻、再送結果を追跡できるようにする。

空欄を既存値へ上書きするか、遅れて届いた古い更新を拒否するか、同じイベントの再送をどう見分けるかも実装前に決めます。エラー通知だけを作り、直す担当がいない状態は避けます。

権限は使うエンドポイントに限定する

Braze公式ドキュメントでは、APIキーごとに特定エンドポイントへの権限を設定し、認証できる呼び出しを制限できると説明しています。将来使うかもしれない権限をまとめて付けず、今回の転送に必要な範囲だけを申請します。

APIキーそのものを仕様書、チャット、記事へ貼りません。この記事ではログイン、キー発行、接続試験は行わず、責任者が承認すべき境界だけを示しています。

実装へ進む前のチェックリスト

Brazeへ渡す目的と、渡さない情報を書いた。
顧客、連絡先、同意、反響、予約の正本を一つずつ決めた。
社内顧客IDの発行元とexternal_idの対応を決めた。
反響・予約イベントの発生条件、時刻、重複判定IDを定義した。
空欄、古い更新、重複、送信失敗の扱いを決めた。
元データ修正、エラー確認、再送承認の担当を割り当てた。
自社インスタンスのRESTエンドポイントを承認済み情報で確認した。
APIキーの権限を、利用するエンドポイントだけに限定した。