Brazeを使いこなせないのは、機能の問題ではない

配信ツールとして使うだけでは、なぜ回収しにくいのか

Brazeには予測系の機能があります。そのうち離脱予測（Predictive Churn）について、公式ドキュメントはこう書いています。他の機能の要件は、本稿では確認していません。

With Predictive Churn, a tool in the Braze Predictive Suite, you can define what churn means for your business and identify the users you want to retain.

── Braze公式ドキュメント「Predictive Churn」（2026年8月25日取得。訳：Braze Predictive Suiteのツールである Predictive Churn では、自社にとって離脱が何を意味するかを定義し、引き留めたいユーザーを特定できます）

ここまでは、できることの説明です。使うための条件は、同じ機能の別ページ（トラブルシューティング）に書かれています。

使えるデータの種類が、この記事の芯です。予測は属性ではなくイベントで動きます。属性は「その人がいまどうか」を持つ器で、イベントは「いつ何をしたか」を持つ器です。イベントが無い状態では、この機能の前提を満たしません。（原文はイベントで動くと書いているだけで、「属性だけでは動かない」は私たちの読み方です）

属性とイベントは、何が違うのか

器の違いは、連携を組むときに決まります。公式ドキュメントは、属性についてこう書いています。

Braze doesn’t store time-series information for custom attributes, so you can’t get any graphs based on them like you can for custom events.

── Braze公式ドキュメント「Custom Attributes」（2026年8月25日取得。訳：Brazeはカスタム属性について時系列情報を保存しないため、カスタムイベントのようにグラフを得ることはできません）

属性は、時系列を持たない器だと公式が書いています。だから「いつ変わったか」を後から読めません。止まったことを読む必要がある機能では、イベントとして記録されている必要があるということになります。（この接続は私たちの読み方です。）

私たちが見てきた範囲では、基幹システムからの連携は属性を渡す形が多くあります。会員マスタや購買サマリを日次で同期する形が自然だからです。それは連携としては正しく動いていて、配信の出し分けにも使えます。ただ、そこにイベントが無いと、予測のような機能は前提から外れます。

データを増やせば解決するのか

イベントを増やす判断は、自然な次の一手です。ただ、増やすと費用の側が動きます。BrazeはMAUとデータポイントの2軸で課金されます。公式ドキュメント「Data points」は「Don’t waste data points. Only update changing data!」（データポイントを無駄にしないこと。変わるデータだけを更新すること）と書いています（出典：Braze公式ドキュメント「Data points」／2026年8月19日取得）。費用の仕組みはBrazeの費用の記事で、量ではなく形が問題になる構造は出し分けとデータの記事で扱いました。

つまり「全部イベントにする」も答えになりません。公式ドキュメントは、うまくいかないときに考えられる原因も3つ挙げています。ただし引用の直前の一文は取得できていないため、この説明がどの状況に対するものかは原文からは確定できません。

It likely means that the data sent to Braze is not ideal for this use case, that there are not enough users with which to build a model against, or that your product life cycle is longer than our current 60-day lookback window supports.

── Braze公式ドキュメント「Troubleshooting – Predictive Churn」（2026年8月25日取得。訳：それはおそらく、Brazeに送られているデータがこのユースケースにとって理想的とはいえないか、モデルを作るのに十分なユーザーがいないか、あるいは自社の製品ライフサイクルが現在の60日の遡り期間で扱える範囲より長い、ということを意味します）

3つの原因が並んでいます。データの適合、ユーザー数、そして製品ライフサイクル（product life cycle）の長さです。原文は「It likely means」で始まり、断定ではなく可能性として挙げられています。3つめは、配信の運用では動かせません。私たちの読み方ですが、製品ライフサイクル（購買や利用の周期）が60日の遡り期間より長い商材では、構造的に合いにくいということになります。

予測は、動き始めたあとも品質が変わるのか

公式ドキュメントのトラブルシューティングには「Prediction has poor quality」（予測の品質が低い）という項目が立てられています（出典：Braze公式ドキュメント「Troubleshooting – Predictive Churn」／2026年8月25日取得）。この項目の本文は、私たちが取得した範囲では末尾が切れているため、何をどう見直すかまでは本稿では扱いません。私たちが参照した範囲では、この指標の定義まで確認できていないため、本稿では具体値を扱いません。押さえたいのは、動かせばそのまま使える機能としてではなく、データ次第で品質が変わる前提で設計されている、という点です。

Brazeを入れたあと、どこから決め直せるのか

ここからは私たちの進め方です。入れたあとでも、決め直せます。3つあります。

• 使いたい高度な機能を1つ選び、その要件を先に読む。離脱予測なら、目安として示されているユーザー数・イベントであること・60日という上限が公式に書かれています。要件を満たさない機能を前提に投資を説明すると、説明の材料が足りなくなります
• 属性で渡すものと、イベントで渡すものを分けて設計する。会員ランクや住所は属性で足ります。止まったことを読みたいものは、イベントにする必要があります。この仕分けは、連携を組む時点で決めておくと手戻りが少なくなります。あとから足す場合も、まず1イベントから始められます
• 製品ライフサイクル（購買や利用の周期）を先に測る。60日という上限に対して、自社の周期が長いか短いか。長い商材では、予測に頼らない設計を先に考えることになります

使いたい機能の要件を先に読むことが要点です。Brazeの評価は「使いこなせているか」ではなく「何を動かすために入れたか」で決まります。器を入れる前に決めることの順序は顧客資産化の設計順序で扱いました。

よくある質問

Brazeを配信ツールとして使うのは、間違いですか？

間違いではありません。複数のチャネルを1つの画面から出せるだけでも運用は楽になります。ただし私たちが確認した離脱予測（Predictive Churn）には、公式ドキュメントに前提が書かれています。離脱予測（Predictive Churn）は「Typically, you need 300,000 Monthly Active Users in a single workspace」（通常、1つのワークスペースに30万の月間アクティブユーザーが必要です）とされ、「Predictive Churn works with custom events as opposed to custom attributes」（カスタム属性ではなくカスタムイベントで動きます）と明記されています。（出典：Braze公式ドキュメント「Troubleshooting – Predictive Churn」／2026年8月25日取得）

Brazeの離脱予測を使うには、どれくらいのユーザー数が必要ですか？

公式ドキュメントは「Typically, you need 300,000 Monthly Active Users in a single workspace」（通常、1つのワークスペースに30万の月間アクティブユーザーが必要です）としています。原文は「Typically」で始まるため、絶対の下限として書かれているわけではありません。また予測対象の定義（prediction audience definition）は「cannot exceed 100 million users」（1億ユーザーを超えられません）とされています。（出典：Braze公式ドキュメント「Troubleshooting – Predictive Churn」／2026年8月25日取得）

カスタム属性を入れておけば、予測は動きますか？

動きません。公式ドキュメントは「Predictive Churn works with custom events as opposed to custom attributes」（Predictive Churnは、カスタム属性ではなくカスタムイベントで動きます）と明記しています。公式ドキュメントは「Braze doesn’t store time-series information for custom attributes」（カスタム属性については時系列情報を保存しない）とも書いています。だから「いつ変わったか」を後から読めません。止まったことを読む必要がある機能では、イベントとして記録されている必要があります。（この器の対比は私たちの整理です。出典：カスタムイベントで動く点は Braze公式ドキュメント「Troubleshooting – Predictive Churn」、時系列情報を保存しない点は同「Custom Attributes」／いずれも2026年8月25日取得）

製品ライフサイクルが長い商材でも、離脱予測は使えますか？

公式ドキュメントは、離脱を「up to 60 days」（最大60日）のあいだに起きるものとして定義できるとしています。そして、うまくいかないときに考えられる原因の1つとして「your product life cycle is longer than our current 60-day lookback window supports」（自社の製品ライフサイクルが現在の60日の遡り期間で扱える範囲より長い）という原因を挙げています。製品ライフサイクル（購買や利用の周期）が60日より長い商材では、構造的に合いにくいということになります。これは私たちの読み方です。（出典：Braze公式ドキュメント「Troubleshooting – Predictive Churn」／2026年8月25日取得）

イベントを増やせば解決しますか？

費用の側が動きます。Brazeはデータポイントで課金され、公式ドキュメントは「Only update changing data!」（変わるデータだけを更新すること）と書き、変わらない同じデータを送り続けないための仕組みを用意することを推奨しています。増やす方向だけで解くと、使っていないデータの分も使用量に積み上がります。費用の仕組みはBrazeの費用の記事で扱いました。（出典：Braze公式ドキュメント「Data points」／2026年8月19日取得）