「データはかなり蓄積しているので、何か分析できないでしょうか」。実際に相談を受けてデータを見てみると、量は十分にあるのに、事業上知りたいことに答えられないケースがあります。
原因は分析手法ではなく、もっと前にあることがあります。事業やサービスを始めるときに、「将来何を判断するために、どんなデータが必要か」が設計されていないのです。この記事では、筆者が支援した百貨店の事例をもとに、事業開始前に考えておきたいデータ取得設計について解説します。
データはあるのに分析できないのは、「何を知りたいか」が決まっていないから
データが大量にあっても、「何を知るためのデータなのか」が整理されていなければ、事業の意思決定につながる分析は難しくなります。
ここでいうデータ取得設計とは、将来の分析や意思決定を想定し、「何のデータを、どの粒度で、どのタイミングで取得するか」を事前に考えることです。
筆者が以前支援した、ある百貨店でも同じ問題がありました。その百貨店では自社のクレジットカードを発行していましたが、カードを通じて顧客の何を知りたいのか、どんな意思決定につなげたいのかは十分に整理されていませんでした。
後から分析しようとすると、分かるのは主に「どの加盟店で、いくら決済したか」です。たとえば「日比谷花壇で3,000円使った」といった情報です。
もちろん、これにも価値はあります。ただ、「日比谷花壇で3,000円」だけでは、その人が何を買ったのか、なぜ買ったのか、どんな購買傾向を持つのかまでは分かりません。
もし購買内容まで分かれば、マーケットバスケット分析、つまり「どの商品とどの商品が一緒に購入されやすいか」を調べる分析や、顧客クラスタリング、つまり購買傾向が似た顧客をグループに分ける分析に発展させられる可能性があります。ただし、当時のカードの仕組みで商品明細まで取得できたかは確認できていません。
重要なのは、商品明細そのものではありません。「顧客の購買行動を理解したい」という目的が先にあれば、そのために何が必要か、現実的に何が取れるかを事業開始時に検討できた、ということです。
似た話を、あるQRコード決済サービスの分析現場で働いていた方から聞いたことがあります。その方によると、「居酒屋で決済した後にラーメン店で決済した」といった行動は分かっても、「飲んだ後にラーメンを食べる人がいる」程度で止まり、事業上の示唆につなげにくかったそうです。
これは、そのサービス全体について検証した話ではなく、あくまで分析現場にいた一人から聞いたエピソードです。ただ、百貨店の事例と共通するのは、データがあることと、事業上の問いに答えられるデータがあることは別だという点です。
データ取得設計は「KPI→論点仮説→必要なデータ」の順に考える
では、事業開始前にどんなデータを取るべきなのでしょうか。将来使いそうなデータを、とにかく多く集めればよいわけではありません。
筆者は、「事業KPI→論点仮説→仮説を検証するためのデータ」の順に考えることが重要だと考えています。
KPI（重要業績評価指標）とは、事業が目標に向かって進んでいるかを測る指標です。論点仮説とは、「この事業がうまくいくかを判断するうえで、何が重要な条件になるのか」という仮の見立てです。
たとえば、「この事業が成立するには、高価格帯の商品を購入する顧客のLTVが十分に高い必要があるのではないか」と仮説を置いたとします。LTV（Life Time Value：顧客生涯価値）とは、一人の顧客が取引期間全体を通じて企業にもたらす価値です。
この仮説を検証するには、売上だけでなく、高価格帯の商品を購入した顧客を識別できること、その顧客が継続して利用しているかを追えることなどが必要になります。属性情報を直接取れないのであれば、代替できる変数がないかを考えます。
株式会社エブリーも、2023年に公開したログ設計事例で、分析したいことを整理したうえで、必要なイベントやログ項目へ落とし込む流れを紹介しています。[1]
| ありがちな進め方 | データ取得設計から考える進め方 |
|---|---|
| 取れるデータをとりあえずためる | 事業KPIを決める |
| データがたまってから分析テーマを考える | KPIを左右する論点仮説を置く |
| 分析時に足りないデータに気づく | 仮説検証に必要なデータを決める |
| 取れなければ分析を諦める | 代替変数・追加取得・問いの変更を考える |
新規事業では、KPIだけでなく、一定期間で撤退や方向転換を判断するイグジットクライテリア（撤退・見直しの判断基準）を置くことがあります。
ここでも、「基準に達した／達しなかった」だけでは不十分です。高価格帯顧客のLTVは想定通りなのに新規獲得が弱いのか、そもそもLTV自体が想定より低いのかでは、次に取るべき対応が変わります。
だからこそ、ローンチ前に最低限考えたいのは、「この事業の成否を左右する論点は何か」「その論点を後から検証できるデータが残るか」です。
最初から完璧でなくていい。仮説に応じて追加データを取る
将来必要になるデータを、最初からすべて予測するのは現実的ではありません。事業を始めて顧客の反応を見ることで、初めて分かることもあります。
そのため、データ取得設計は一度で完成させるものではありません。事業性を判断するための最低限のデータを先に押さえ、その後は仮説に応じて追加取得していく方が現実的です。
たとえば百貨店の例で、既存データから「特定の顧客群はLTVが高そうだ」という傾向が見えてきたとします。次に知りたいのは、「その人たちは何を好むのか」「何を提案すれば、さらに利用してもらえるのか」です。
その情報が既存データになければ、アンケートを行う、メルマガへの反応を見るなど、別の方法で追加データを取得できます。そこからクロスセルやアップセルの仮説をつくり、施策へつなげていきます。
重要なのは、最初から顧客について何でも分かるデータベースを作ることではありません。
「KPIを設定する→事業成立の論点について仮説を置く→仮説を検証できるデータを取る→分析して新たな仮説が生まれたら追加データを取る」
この循環を回せるようにしておくことが、現実的なデータ取得設計だと考えています。
まとめ：分析できるかどうかは、データを取る前から決まっている
「データがたまったら、後から分析すればいい」と考えていると、いざ分析するときに、答えたい問いに必要な情報が残っていないことがあります。
一方で、将来必要になるデータをすべて予測し、事業開始前から完璧に取得する必要もありません。
まず確認したいのは、「この事業の成否を左右する論点は何か」「それを後から検証できるデータが残る設計になっているか」です。
すでに事業が動いている場合も、いま持っているデータから何が分かり、何が分からないかを整理すれば、追加で取得すべきデータや、現実的に検証できる別の問いが見えてきます。自社のデータでどこまで判断できるのか分からない場合は、分析手法を選ぶ前に、事業上の問いと取得データの対応関係を整理するところから始めるとよいでしょう。
参考文献
- 株式会社エブリー「分析に向けたログ設計の話」2023年
