実務活用と意思決定 公開日 更新日 著者 ベイズ統計実務活用ガイド

ベイズマーケティングで施策判断を更新する方法

ベイズマーケティングをA/Bテスト、CVR、問い合わせ数、ROI判断へ使う手順を、分布選択と期待損失の境界つきで整理します。

ベイズマーケティングで施策判断を更新する方法のアイキャッチ

リニューアル案、広告配分、LPのA/Bテスト、休眠顧客への再接触。マーケティング施策の会議では、少ない観測値から「続けるか、止めるか、追加で試すか」を決める場面が多くあります。ベイズマーケティングを実務で使う価値は、専門用語を増やすことではありません。施策前に持っていた仮説を確率分布として置き、観測データを加え、判断時点での不確実性を見える形に更新することです。

この記事では、マーケティング担当者や分析担当者が施策判断へ持ち込める最小の型に絞ります。CVRやCTRのような成功率はベータ分布、問い合わせ数や来店数のような件数はポアソン分布、売上差やROIのような連続量は正規分布または正の値だけを扱う分布で表します。大事なのは、分布名を覚えることではなく、指標の性質と意思決定の損失を対応させることです。

ベイズマーケティングは何を更新して判断するのか

ベイズマーケティングで更新する対象は、「施策が良さそう」という感覚ではなく、施策効果に関する確率的な見立てです。施策前の仮説、観測データ、更新後の分布、意思決定閾値を分けると、会議での論点がかなり整理されます。たとえばLP改善なら「CVRが何%上がったか」だけでなく、「上がった可能性がどれくらいあり、悪化している可能性をどこまで許すか」を扱います。

施策判断を確率更新で進める全体像

施策前仮説はpriorとして文章と数値で置く

施策前仮説は、単なる希望ではなく、事前分布として表せる情報です。過去の類似施策、既存チャネルの平均CVR、ブランド制約、季節要因、営業現場の知見がここに入ります。Google Meridianのprior説明でも、事前情報はモデルがデータを見る前に与える情報であり、業務知識や過去実験、ベンチマークを反映できるものとして扱われます。マーケティングでは、過去の勝ち施策をそのまま再利用するより、「この施策なら改善幅は小さいが悪化リスクも小さい」「新規チャネルなので改善幅も悪化幅も大きい」と幅を持たせる方が使いやすくなります。

実務では、priorを難しい数式で始める必要はありません。まずは「期待する中心値」「どれくらい外れると思うか」「ありえない値」を決めます。ROIのpriorのように正であるべき量を置きたい場合は、Meridianのprior説明が示すように、対数正規や半正規のような正の範囲を扱う分布が候補になります。逆に、施策差分がプラスにもマイナスにもなり得る連続量なら、正規分布で平均と標準偏差を置く方が会議で説明しやすい場合があります。

観測データはlikelihoodとして指標の性質に合わせる

観測データは、施策後に得たクリック、購入、問い合わせ、売上、継続、離脱などです。ただし、すべてを同じ表に入れて平均差だけで比べると、データの性質を失います。1000訪問中40件購入したCVRと、1週間で40件問い合わせがあった件数と、広告費100万円に対する売上増加の推定値は、同じ40という数字でも意味が違います。

CVRは成功か失敗かの試行です。問い合わせ数は期間あたりに何回起きたかという件数です。ROIは連続的な効果量で、媒体や季節の揺れを受けます。ベイズ更新では、この観測データの出方をlikelihoodとして置きます。指標の性質に合わないlikelihoodを選ぶと、意思決定で使う不確実性が過小または過大になります。

事後分布は会議で使う判断材料に変換する

更新後の事後分布は、グラフを眺めるためだけのものではありません。意思決定に使うなら、少なくとも三つの値へ変換します。第一に、施策Bが施策Aを上回る確率。第二に、採用したときに期待できる改善幅。第三に、間違って採用した場合の期待損失です。

勝率が高くても改善幅が小さく、実装コストやブランドリスクが大きければ採用しない判断はあり得ます。反対に、勝率がまだ十分高くなくても、悪化時の損失が小さく、追加観測の費用に見合うほど判断が変わる余地があるなら、小規模継続を検討できます。ここまで分けると、ベイズマーケティングは「勝った負けた」の速報ではなく、次の施策行動を選ぶための確率更新になります。

指標ごとにどの確率分布を選ぶべきか

分布選択は、分析者だけの技術選定ではありません。どの分布を選ぶかで、会議で答えられる問いが変わります。CVRを見たいのか、問い合わせ数を見たいのか、売上差やROIを見たいのかを先に決めると、ベータ分布、ポアソン分布、正規分布の役割が整理されます。

指標ごとに分布を選ぶ対応表

CVRやCTRはベータ分布で成功率を更新する

CVRやCTRは、訪問者ごとに購入したか、クリックしたかという成功/失敗の比率です。このような成功率を扱うときは、ベータ分布が実務上の出発点になります。ベータ分布は0から1の範囲に収まるため、CVRがマイナスになる、100%を超えるといった不自然な推定を避けられます。Stanのベータ二項分布の仕様でも、成功数、試行数、成功側と失敗側のprior countを使う形が示されています。

たとえば既存LPのCVRが長期的に3%前後で、直近の季節変動を考えると2%から4%が多いとします。新LPを出した後に、Aが3000訪問で90購入、Bが800訪問で32購入だった場合、単純なCVRはAが3.0%、Bが4.0%です。ただしBの訪問数は少ないため、4.0%をそのまま確定値にすると危険です。ベータ分布で更新すると、BがAを上回る確率と、悪化している可能性を同時に見られます。

ここで実務上の問いは「BのCVRが高いか」だけではありません。「Bを全面採用してもよいか」「まだ半分配信で追加観測すべきか」「改善幅が小さいなら別仮説へ移るべきか」です。ベータ分布は、このような成功率の不確実性を意思決定へつなげるために使います。

問い合わせ数や来店数はポアソン分布で件数を扱う

問い合わせ数、来店予約数、資料請求数、アプリ内イベント数のように、一定期間に何件起きたかを見る指標では、ポアソン分布が候補になります。PyMCのPoisson documentationでも、一定期間に起きるイベント数を扱う分布として説明されています。マーケティングでは、1日あたりの問い合わせ数、キャンペーン期間中のクーポン利用回数、配信後24時間の資料請求数などが該当します。

ただし、ポアソン分布を使う前に、件数が独立に発生しているか、平均発生率が大きく変わっていないかを確認します。広告予算を日ごとに大きく変えた、週末だけ店舗需要が跳ねる、同じ顧客が短時間に複数回イベントを起こす、といった条件では、単純なポアソンだけでは説明が足りません。この場合は、曜日、配信量、季節性、顧客数などを説明変数に入れたポアソン回帰や、過分散を扱うモデルを検討します。

施策判断では、「先週は問い合わせが40件、今週は50件だから増えた」と見るだけでは不十分です。平均発生率の事後分布を見て、増加が偶然の揺れに収まるのか、広告やLP変更と整合するのかを確認します。件数型の施策では、CVRよりも配信量や露出量の影響を受けやすいため、分母や露出条件を本文の表や会議資料に必ず添えるべきです。

ROIや売上差は正規分布だけでなく正の制約も見る

売上差、粗利差、顧客単価、ROI、mROIのような連続量は、正規分布で近似できる場面があります。正規分布は平均と標準偏差で説明しやすく、施策差分がプラスにもマイナスにもなり得るときに使いやすい分布です。Meridianのprior説明でも、正規分布は分布理解の例として使われ、標準偏差が不確実性の幅を表すことが示されています。

一方で、ROIのpriorのように正の値として扱いたい量では、正規分布が負の値にも確率を置く点が問題になることがあります。Meridianは、ROIには正の値だけに確率を置くLogNormalやHalfNormalがNormalより適する場合があると説明し、paid mediaのROI priorにLogNormalを使う設定例も示しています。会議では「平均ROIが1.2」という点だけでなく、「採算閾値を下回る確率」「過大なROIをどこまで信じるか」「そのpriorが実験結果や業務知識に合っているか」を確認します。

売上差の判断で重要なのは、媒体別、地域別、時期別にノイズが大きいことです。広告接触から購買までの遅れ、他チャネルとの相互作用、価格改定、在庫、競合キャンペーンが混ざります。正規分布を使う場合でも、分布の幅を小さく見積もりすぎないことが実務上の安全策になります。

分布選択を会議用の入力表にする

実務では、分布を毎回ゼロから議論すると止まります。そこで、施策会議の入力表に「指標」「観測単位」「候補分布」「必要な分母」「判断指標」を入れておきます。CVRなら訪問数と購入数、候補分布はベータ、判断指標はBがAを上回る確率と期待損失。問い合わせ数なら期間、露出量、件数、候補分布はポアソン、判断指標は平均発生率の増加確率。ROIなら媒体別費用、売上増分、候補分布は正規または対数正規、判断指標は採算閾値を上回る確率です。

この入力表を作ると、ベイズ分析が「高度な分析手法」ではなく、施策判断の会議運営に入ります。分析者はモデル式を説明する前に、どの事業判断へ答えるのかを確認できます。マーケティング担当者は、分布名を覚えなくても、自分が持っているデータが成功率型、件数型、連続量型のどれかを判断できます。

A/Bテストは勝率だけで止めてよいのか

A/Bテストでよく起きる失敗は、途中で勝っている案を見つけた瞬間に止めることです。ベイズで「BがAを上回る確率」を出せるようになると、勝率だけを採用基準にしたくなります。しかし実務の意思決定では、勝率、改善幅、悪化時の損失、追加観測にかかる費用と判断が変わる余地を分ける必要があります。

A/Bテストを勝率と期待損失で判断する流れ

勝率は採用基準の一部でしかない

BがAを上回る確率が95%だったとしても、改善幅が0.1ポイントで実装コストが大きいなら、採用しない方がよい場合があります。反対に、勝率が80%でも、改善幅が大きく、悪化しても一部配信で止められるなら、段階的に広げる選択肢があります。勝率は「方向」の情報であり、「採用した場合にどれくらい得をするか」「外れた場合にどれくらい損をするか」までは含みません。

A/Bテストの報告では、最低でも三つを並べます。BがAを上回る確率、期待改善幅、期待損失です。期待損失は、誤った案を採用した場合に失う差を事後分布上で平均したものとして扱います。Bayesian A/Bの連続監視研究でも、posterior expected lossを事前に決めた閾値と比べる停止基準が提案されています。この値が小さければ、勝率が完璧でなくても採用しやすくなります。期待損失が大きければ、勝率が高くても追加観測や小規模展開を選びます。

早期停止は意思決定損失で決める

早期停止をするかどうかは、統計的な勝率だけでなく、事前に決めた事業上の許容損失で決めます。LP文言の軽微な変更なら、誤採用しても損失は小さいかもしれません。価格訴求、ブランド表現、解約抑止、法人向けの営業資料のように、悪化時の損失が大きい施策では、同じ勝率でもより慎重に扱います。

追加で1000訪問を観測するかどうかは、統計式だけで自動決定せず、期待損失、分布の重なり、施策の残り期間、観測コストを並べて決めます。期待損失がすでに小さく、追加観測しても採用・停止の判断が変わりにくいなら止めます。期待損失が大きく、分布の重なりが広く、追加観測の費用を払っても判断が改善しそうなら続けます。つまり、停止基準は「勝率が何%以上」だけではなく、「許容損失を下回ったか」「追加観測に事業上の意味が残っているか」で決めます。

小さい差はセグメントで都合よく切らない

A/Bテストの結果が微妙なとき、年齢、地域、流入元、端末、既存顧客/新規顧客で切ると、どこかに勝っているセグメントが見つかることがあります。これは実務上とても危険です。セグメントを増やすほど偶然の差を施策効果として見誤る可能性が上がります。

ベイズで扱う場合も、セグメントを見つけた後に説明を後付けするのではなく、施策前に「このセグメントで効果が違うはず」という仮説を置きます。さらに、セグメント別の推定を完全に独立させず、全体情報を共有するpartial pooling型の階層モデルを使うと、小さいセグメントの極端な値をそのまま信じにくくなります。これにより、少数データのたまたまの勝ちを全面展開するリスクを下げる読み方ができます。

報告文は断定ではなく次の行動で終える

A/Bテストの報告文は、「Bが勝ちました」ではなく、「BはAを上回る確率が高いが、改善幅と期待損失を踏まえると、全面採用、小規模継続、追加観測、仮説破棄のどれにするか」と書く方が実務に向いています。たとえば、Bの勝率が92%、期待改善幅が0.4ポイント、期待損失が小さいなら、低リスク範囲でBへ寄せる判断ができます。勝率が70%、期待改善幅は大きいが損失も大きいなら、対象セグメントを絞って追加観測します。

この書き方にすると、ベイズマーケティングは分析結果の発表ではなく、施策運用の更新ループになります。意思決定者は、数式ではなく損失と次の行動で判断できます。

セグメント別施策ではどう過学習を避けるのか

マーケティングでベイズを使いたくなる場面の一つが、セグメント別施策です。新規顧客、既存顧客、休眠顧客、地域、デバイス、広告チャネル、購買頻度ごとに効果が違うかを見たい。しかし、セグメントを細かくするほどデータは薄くなり、偶然の揺れが大きくなります。ここで必要なのは、個別最適を急ぐことではなく、全体と個別の情報をどう混ぜるかです。

セグメント別施策で小さい集団を扱う考え方

小さいセグメントは全体平均へ寄せて読む

あるセグメントでCVRが10%上がったように見えても、訪問数が少なければ信頼しすぎない方がよいです。階層ベイズのpartial poolingでは、各セグメントの効果を完全に独立させず、セグメント間の類似性も推定します。rstanarmのvignetteでも、繰り返し二値試行に対してcomplete pooling、no pooling、partial poolingを比較し、partial poolingでは単位間の類似性を推定すると説明されています。マーケティングでは、データが多いセグメントは自分自身の観測値を比較的強く読み、データが少ないセグメントは全体情報も使って慎重に読む、という境界で使います。この縮約により、小さい集団の極端な数字だけで施策を決めるリスクを下げられます。

マーケティング会議では、「セグメントAで勝った」ではなく、「セグメントAは全体より高そうだが、観測数が少ないため不確実性が広い」と説明します。すると、全面展開ではなく追加配信、調査、次回テストの優先順位づけができます。

セグメント仮説は施策前に決める

セグメント分析でよくある問題は、結果を見た後にもっとも都合のよい切り口を選ぶことです。これを避けるには、施策前にセグメント仮説を決めます。たとえば、休眠顧客は割引よりも利用再開理由の提示に反応する、法人顧客は価格より導入手順に反応する、既存顧客は新機能訴求より活用事例に反応する、といった形です。

この仮説はpriorに反映できます。強い根拠があるなら差が出やすい分布にし、根拠が弱いなら全体平均に近い分布にします。重要なのは、分析後に説明を作るのではなく、施策前に「どの差なら意思決定に使うか」を決めておくことです。

チャネル配分ではMMMとA/Bテストを混同しない

広告チャネルの予算配分では、A/Bテストのように完全にランダム化できないことが多くあります。テレビ、検索広告、SNS、屋外広告、メール、営業活動は同時に動き、季節性や価格改定も重なります。Google MeridianやPyMC-Marketingが扱うMMMは、こうしたチャネル効果や予算配分を推定する文脈で使われます。Meridianはマーケティング投資の因果効果を扱うため、因果推論とベイズ統計を土台にする、と説明しています。

ただし、MMMの推定結果を個別LPのA/Bテスト結果と同じように読むと危険です。MMMはチャネルや時系列、地域差を扱うため、prior、制約、因果仮定、データ粒度が重要です。A/Bテストは比較的短いサイクルで変化を見られますが、MMMは媒体横断の予算判断やシナリオ比較に向きます。実務では、A/Bテストで訴求やLPを改善し、MMMで予算配分やチャネル効果を見直す、と役割を分けます。

過学習を避ける最終質問

セグメント別施策で最後に確認する質問は、「この差が本当だったとして、次に何を変えるのか」です。何も変えないなら、そのセグメント差は会議資料に載せる必要がありません。配信費、LP、オファー、営業接触、メール頻度、除外条件のどれを変えるのかを決めてから、分析するセグメントを選びます。

この順序を守ると、ベイズ分析は細かい差を探す作業ではなく、次の施策変更に必要な不確実性だけを更新する作業になります。

現場で使うときの最小ワークフローは何か

ベイズマーケティングを現場に入れるとき、最初から大きなモデルを作る必要はありません。むしろ、施策前、観測後、判断会議、次回テストの四つに分け、毎回同じ入力と出力で回す方が定着します。

施策判断へ落とす最小ワークフロー

施策前に決めること

施策前には、まず意思決定の単位を決めます。全面採用するのか、配信比率を変えるのか、追加観測するのか、仮説を捨てるのか。次に、主要指標と補助指標を分けます。主要指標がCVRならベータ分布、問い合わせ数ならポアソン分布、ROIのpriorならLogNormalやHalfNormalのような正の範囲を扱う分布を候補にします。売上差のようにプラスにもマイナスにもなり得る差分なら、正規分布を候補にします。最後に、採用閾値と許容損失を決めます。

この段階で決めるべきことは、分析手法よりも判断基準です。「BがAを上回る確率が90%以上、期待損失が月間粗利の一定範囲内なら段階採用」「確率が高くてもブランド毀損リスクがある表現は採用しない」「問い合わせ件数が増えても商談化率が下がるなら継続観測」など、施策ごとの停止条件を文章にします。

観測後に見ること

観測後には、まずデータ品質を確認します。配信比率が崩れていないか、計測タグが変わっていないか、除外すべき異常日があるか、セグメントの定義が途中で変わっていないか。ここを飛ばすと、どれだけ丁寧にベイズ更新しても、入力が壊れたままになります。

次に、事後分布から判断値を出します。CVRなら勝率、期待改善幅、期待損失。件数なら平均発生率の増加確率と、露出量を調整した上での増加幅。ROIなら採算閾値を上回る確率と、過大推定の可能性。期待損失を使う場合は、採用前に許容損失の閾値を決め、後から都合よく基準を動かさないようにします。これらを同じフォーマットで残すと、次回のpriorにも使えます。

判断会議で決めること

判断会議では、分析結果を「採用」「停止」「追加観測」「仮説修正」のいずれかに必ず落とします。勝率だけを見せると、判断者は高い数字に引っ張られます。期待損失、実装コスト、ブランドリスク、学習価値を並べると、意思決定の理由が残ります。

特に小さい改善では、追加観測に事業上の意味が残っているかを見ます。もう少しデータを集めても判断が変わらないなら、早く次の仮説へ移る方がよいです。反対に、分布が広く、施策の潜在価値が大きく、観測コストを払っても判断改善が見込めるなら、配信比率を下げてでも続ける価値があります。ベイズマーケティングの強みは、判断を一度で終わらせず、次の観測設計へ戻せることです。

次回テストへ残すこと

最後に、今回の事後分布を次回のprior候補として保存します。ただし、すべてをそのまま使うのではありません。季節性、媒体変更、価格改定、ターゲット変更、LP構成変更があれば、過去結果の信頼度を下げます。施策条件が近ければ強めのpriorにし、条件が違えば弱めのpriorにします。

残すべきメモは、施策名、対象セグメント、主要指標、候補分布、priorの根拠、観測データ、事後分布の要約、判断、次に変えることです。このメモがあると、次回の会議で「前も勝ったから」ではなく、「前回の条件ではこの程度の効果があり、今回は条件がどれだけ違うか」と議論できます。

まず何から始めればよいか

最初の一歩は、既存の施策会議に確率更新の欄を一つ足すことです。CVR型、件数型、連続量型のどれかを選び、prior、観測データ、事後分布、判断基準を1枚にまとめます。いきなりMMMや階層モデルを導入するより、1つのA/Bテストや1つの問い合わせ改善施策で、勝率と期待損失を並べる方が定着しやすいです。

ベイズマーケティングを1施策から始めるための確認項目

ベイズマーケティングは、施策判断を自動化する魔法ではありません。少ないデータでも、過去知見と新しい観測を分けて扱い、不確実性を残したまま次の行動を選ぶための方法です。ベータ分布、ポアソン分布、正規分布は、そのための道具です。実務で重要なのは、どの分布を選ぶかよりも、何を採用し、何を保留し、何を次に観測するかを、確率と損失の言葉で説明できることです。

よくある質問

ベイズマーケティングはA/Bテストだけに使うものですか?
いいえ。A/BテストではCVRやCTRの成功率更新に使いやすいですが、問い合わせ数のような件数、広告チャネルのROI、セグメント別施策の効果推定にも使えます。指標の性質に合わせて分布と判断基準を変えることが重要です。
CVRを見るなら必ずベータ分布を使えばよいですか?
成功/失敗の比率を扱う出発点としてベータ分布は有用です。ただし、流入元、時期、顧客属性で差が大きい場合は、単純なベータ更新だけでなく、説明変数やpartial pooling型の階層モデルを検討します。小さいセグメントの極端な値をそのまま施策効果と決めつけないことが重要です。
ポアソン分布はどんなマーケティング指標に向いていますか?
一定期間の問い合わせ数、来店予約数、資料請求数、イベント発生数のような件数型の指標に向いています。ただし、曜日や広告配信量で平均発生率が大きく変わる場合は、露出量や季節性を入れたモデルにする必要があります。
ベイズ分析の結果はどの値で意思決定すればよいですか?
勝率だけでなく、期待改善幅、期待損失、追加観測にかかる費用と判断が変わる余地を一緒に見ます。期待損失を使う場合は、採用前に許容損失の閾値を決めます。勝率が高くても改善幅が小さい場合や、悪化時の損失が大きい場合は、全面採用ではなく小規模継続や追加観測を選ぶことがあります。

関連記事

出典

  1. Introduction to Priors | Meridian | Google for Developers
  2. Introduction to Bayesian Modeling & Causal Inference Theory | Meridian | Google for Developers
  3. Introduction to Media Mix Modeling | PyMC-Marketing
  4. Introduction to Bayesian A/B Testing | PyMC example gallery
  5. Beta-Binomial Distribution | Stan Functions Reference
  6. pymc.Poisson | PyMC documentation
  7. Martingale Stopping Rule for Bayesian A/B Tests in Continuous Monitoring
  8. Hierarchical Partial Pooling for Repeated Binary Trials | rstanarm
  9. Choose and configure treatment prior types | Meridian | Google for Developers