プロダクトでのデータ活用を推進するために回避すべき 10 の罠
データドリブンにプロダクトを改善していきたい、とはどんなプロダクトマネージャーでも志すことですが現実には上手く行かないこともあると思います。その時に、参考になる動画を見つけたので紹介します。 Product School のチャンネルで公開されている Webinar: Top 10 Digital Analytics Mistakes by Amplitude's Adam Greco and WillowTree's Jeremy Stern です。登壇者の Adam Greco さんは Amplitude という分析プラットフォームの Product Evangelist 、 Jeremy Stern さんは WillowTree というプロダクトでのデータ活用を支援するコンサルティングサービスの Director of Product Analysis を担当されています。動画の見どころは、 Adam さんは 元 Salesforce の Marketing / Analytics の Senior Director として経験したこと、 Jeremy さんはコンサルティングの経験から生々しい実例をベースに話が聞けることです。動画再生回数がなぜか 400 回ぐらいしかないですが、私がこれまで見聞きしたデータ分析系の話の中でトップクラスに面白かったです。
ここからは、罠 + 回避方法という体裁で動画の内容をまとめていきます。
データ分析の責任者が存在しない
データ分析が「全員の仕事であり誰の仕事でもない」状態になっている。マーケティングチームが担当していたり、プロダクトチームが独自に行っていたり、データ分析の部門があったり、 IT 部門が管轄していたりする。これがどういう結末を招くかというと、組織横断でのデータ活用ができなくなる。マーケティングチームとプロダクトチームの連携が機能不全になるのはその最たる例で、使っているツールが異なるし使っている言葉も似ているようで微妙に異なったりするし、最悪データの取得元も異なる。
解決策として、 マーケティングチームとプロダクトチームの KPI がうまく連動するように調整を図ることが第一歩。マーケティングチームは Lead の獲得、プロダクトチームが Conversion の向上を KPI にしているとプロダクトチームは Conversion につながらない Lead 、たとえば学生向けのトレーニングなどにイライラすることになる ( なった ) 。
中央集権 vs セルフサービスの衝突
マーケティングチームとプロダクトチームとで分析のスタイルが異なる。マーケティングチームは中央集権的な管理で、分析が必要な時はチケットを発行し回答してもらうような形式を好む傾向がある。一方、プロダクトチームは自ら分析を行うセルフサービス型を好む傾向がある。
解決策として、どちらかに寄せるのではなく必要に応じハイブリッドにする必要がある。組織の規模やプロダクトのフェーズによってニーズが変遷するので、固定的にするとどちらかのチームとその KPI が割を食うことになる。
答えるべきビジネス上の質問がない
多くの企業はデータを集めるのが大好きだがどんなビジネス上の質問に答えるべきかを考えていない。 Amplitude での 10 年の活動で、 仕事の 95% は分析の背景にどんなビジネス要求があるのか問うことだった。顧客はデータを除去することを極端に嫌がるが、既存のデータから答えられる質問をリストアップ ( "Reverse Engineering" ) してぶつけてみると、そのうち半分には関心がなくなぜそんなことを聞くのか ? と言ってくる ( いや、こっちが聞きたいんだけど ) 。
解決策として、ビジネス要求をクリアにすること。ただし、要求は刻々と変化するため 6 ヶ月ごとに見直す、また優先度をつけることを推奨する。
要件定義の不備
データさえためておけば後からいくらでも分析できるという過信がある。必要なデータを取得するには、データ項目の定義やすり合わせ、 SDK や JavaScript による実装、きちんとデータが取得できるかのテスト、取得しているデータの意味を共有・トレーニングするなどそれなりに工数がかかる。後から、大量のイベントとプロパティがあるけど誰にも何を意味するか分からなくなったり ( 15 event / 20 properties ぐらいが適切 ) 、 Auto-tagging を過信してデータ品質に問題が生じたり、 Web のチームと Mobile のチームで別々にデータを収集していて統合する時もめたりする。
解決策として、分析も通常の開発と同じように事前に要件を話し合う必要があることを認識する。
実装の不備
プロダクト上のすべてのイベントが正しくトラッキングされて想定する顧客体験のどこでボトルネックが発生しているか分析できることが理想的だが、現実はプロダクトの開発がひっ迫してくると余裕を生むため真っ先に実装が省略されたりする。プロダクトマネージャーは、プロダクトをリリースしてほっとした後に、経営陣に報告するデータが何もないことに気づいて泣いたりする。 Salesforce ではリリース間近に分析機能を入れてユーザー体験が崩れたことがあった。
解決策として、プロダクトの開発の終盤ではなく中盤で分析のための機能を実装しトラックができることを早めにテストしておく。データ分析の実装をプロダクト開発の本流とは別のスイムレーンで管理する。
目的に合わない分析ツールを使っている
どんな分析ツールを使えばいいのか? はプロダクトチームからよく寄せられる質問だが、 BI ツール進化の背景から上手く要求を満たすツールはあまりない。というのも、データ活用はマーケティングの領域から始まり BI ツールはその文脈で成長してきたため、集計データを表示するダッシュボードは洗練されているが単一顧客の体験を追う機能は不足している。開発上のログツールはセッションのトラッキングを可能にするが、もともと不具合やパフォーマンス上の問題を検知することを目的にしているためマッチしていない。
解決策として、分析ツールを入れれば何とかなるという思考を捨てること。ツールは進化しているが、ユーザー体験のボトルネックを探るには顧客インタビューやプロダクトを使ったサーベイなど定量・定性両面のデータを突合する必要がありこれを単一ツールに期待することはまだ難しい。
データの品質にこだわっていない
要件定義の不備、実装の不備から連なる問題で、データの品質を軽視している。ある実装をすると、データにどのような影響を与えるのか事前に検証されていない。例えば、海外版を作る時ユーザー体験の一部分だけ ( トップページだけなど ) 対応すると一部だけ海外のユーザーの流入が増えデータがいびつになり既存の分析にも支障をきたす。
解決策として、データの品質とは何かを定義し、それに準じているか定期的にチェックする仕組みを構築するなどする。
データから得られた機会を共有しない
データを分析すると顧客がプロダクトを使うきっかけ / 使い続けるきっかけと考えられる洞察が得られることがある。「最近データから発見した洞察を 50 個リストアップしてくれ」と顧客に言っても何も出てこないことが往々にしてある。
解決策として、データから得られた知見を文書化して共有し、仮説を裏付けるための A/B テストなど具体的なアクションにつなげること。それがプロダクトへの貢献につながる。
データ分析をコストととらえている
データ分析基盤やデータ分析ツールをコストととらえてなるべく安くなるようマネジメントするのは大きな間違い。
解決策として、前述のとおりデータからプロダクトの成長につながる洞察を得る、文書化し共有する、具体的なアクションに転換する、成果を出すのプロセスを回すことが重要。
おわりに
動画の内容は以上です。AWS が無料で資料を公開している ML Enablement Workshop は、プロダクトで機械学習を活用できるようになるためのワークショップです。ワークショップ本体の資料に加え、本記事のような先進的プロダクトで活躍する方のノウハウをデータサイエンスを活用するプロダクトマネージャーを訪ねて と題し Q&A 形式でまとめています。ぜひワークショップのコンテンツと共に参考にしていただければ幸いです！GitHub で Star をしていただくとすぐにアクセス出来て、また Watch すると更新通知が来て便利です。
ワークショップの内容が気になる、というかたはカジュアルトークをしていますのでぜひお声がけください。