こんにちは！クラウドファンディングサービスREADYFORでプロダクトマネージャー（PM）をしているまっきー（@Pod0_carp_us）です。
今年もアドベントカレンダーの季節がやってまいりました🎄
READYFORのプロダクト開発では、定性的なユーザーインタビューと定量分析を組み合わせながら、改善に役立つデータの可視化を進めています。
施策の効果を示すにはデータの裏付けが重要ですが、そのためにはツール、リソース、そして適切な分析の可視化など、全体を見据えた運用が欠かせません。
これを読んでいる方のチームでも似たような課題や取り組みがあるのではないでしょうか。
というわけで、12月3日は、特に僕の所属している開発チーム（全4人）でやっている施策効果の可視化について、失敗談やそれにどう対応したかお伝えします。
READYFORのプロダクト開発でどのように施策効果の可視化をしているか気になっている方に届けば幸いです！
【前提】主な利用ツール
READYFORでは、以下のデータソースやツールを中心に施策を可視化しています。
- AWS：DBのデータ保存（支援ログやプロジェクトデータなど）
- Google Analytics：ユーザーの行動ログ取得
- BigQuery：分析するテーブルの保存先
- dbt：分析するテーブルの加工。多様なデータソースを横断的に利用可能にする
- Redash：分析クエリを書く、可視化する
【前提】データ基盤に関わる人数規模
効果の可視化には、そもそも効果をデータとして取得しておくデータ基盤の整備が密接に関係します。
READYFORでは以下のメンバーがメインでやっています。
- SREチーム（3名）：環境構築の初期作業（特にインフラ寄り）
- データ基盤担当（1名）：環境構築の初期作業（特にAWSのDBのdbt管理寄り）
- PM（3名）：分析に使うdbtモデルの実装
環境構築の初期作業はSREチーム（3名、メインは1名）やデータ基盤担当（1名）が協力して行っており、ここは僕はおんぶに抱っこです。
作ってもらった公園で僕は遊んでるだけ、みたいな感じです🥰
PMの僕自身もdbtでデータソースとなるSQLやJinjaを書いて分析用テーブル自体にもコミットしています。
dbtを実装しているPMは、PM4人のうち3名です。
僕自身はSQLはある程度書けますが、Pythonを書けるわけではないので、Jinjaの実装はほとんどできておらず、他の人が書いたコードの拡張をするレベルです。
また、データ基盤担当は、1名しかおらず、社内メンバー向けの各種自動ツールの提供なども行なっている自動化ユーティリティプレイヤーのような方なので、データアナリスト部隊がしっかりいるわけではありません。
そんな事情があり、PMもデータ基盤の構築にある程度コミットしているのが特徴的かと思います。
また、PMに僕より分析力、開発力がすごい人がいるので、いつもとても助けて、特にルールメイクなどしてもらっています🙌
READYFORの効果測定フロー
ざっくり以下の流れです。
そもそもの施策検討のフェーズは省略してます。
①追うべき指標の決定
どの指標を伸ばすのかを明確にする（例：特定ページの閲覧率、クリック率など）
ボカシばかりで恐縮ですが、こんな風に施策の要件をまとめたGoogleドキュメントに書いています。
②分析のための要件定義
Google Analyticsの新イベント取得などの要件をGoogleドキュメントに書いています。
後述しますが、DataLayerのイメージまで書いているのがポイントです。
③リリース後の測定・可視化
- Redashでクエリを作成しダッシュボードにまとめる
- ダッシュボードは僕のチームで行った施策については１箇所にまとめ、チームメンバー（エンジニア3名）も見るハードルが低くなるようにしている
- 分析期間をGUIで簡単にいじって好きな期間で見られるようにしている
具体的な数字はぼかしますが、こんなふうなダッシュボードを作っています
④週次定例ミーティングでの施策の効果確認
定例の議事録をつけているGoogleドキュメントに以下のようにRedashのダッシュボードへのリンクを貼っています。
このアジェンダの名前は「ワクワクドキドキ効果コーナー！！！」です
実際にはワクワクドキドキすることは少なく、「なんでこんな結果なのかなぁ」とヤキモキしたり「あんまり効果なかったね」と残念な気持ちになることも多々です😇
効果の可視化における試行錯誤とその対策
それでは、ここからはどんな失敗があって、どう改善してきたかなどをご共有します！
なお、「効果の可視化」だけでなく「効果を計測できるようにする」前段部分も、よくつまづきポイントになるので、その段階から書いています。
1. 数値取得を考え忘れた！
リリース後に「GAイベント」や「パラメータ」が設定されていないことに気付く…という失敗も過去にありました。
このような設定漏れを防ぐため、仕様書に数値取得要件の欄を記載するなどの対策を行っています。
2. ABテストにしすぎた！
「必ず良くなる改修」や「やるべき改修」に対してもABテストを適用した結果、ABテストのためのパーツを出し分ける実装や、ABテストツール上でうまく動くようにする開発、ABテスト化後の本実装が改めて必要なことなどで、管理コストが増加しました。
→ 現在は、「一部の改修は最初から本実装する」といった基準を設け、必要に応じてABテストをすることにして、コストを低減するよう調整しています。
3. DataLayerの実装が違う！
READYFORでは、DataLayerに値を送信する実装をするところまでがフロントエンドの領分になっていて、DataLayerからGoogle Tag Manager上で値を受け取ってGoogle Analyticsに値が飛ぶようにするところはPMの領分になっています。
しかし、「イベント名自体を送信する」ことや、「どんなパラメータがほしいか」や「スネークケースかローワーキャメルケースか」などをはっきりさせずに実装依頼し、フロントエンドエンジニアとPMの間で認識齟齬があり、後から追加実装になることがありました。
今では仕様書上でDataLayerに飛ぶ値のイメージを記載するようにしています
↓これ
4. GTM設定をミスった！
Google Tag Managerの設定はPMである僕の担当ですが、イベントやパラメータの設定忘れやタイプミスがたまにありました。
数値取得の実装の際は必ず自分が手動テストを行い、Google Tag Managerのプレビュー機能と、Google Analyticsのデバッグ機能を使って、イベントが飛ぶこと、イベントの数が重複したりしないこと、パラメータの値が狙い通り入ることを確認しています。
Google Tag Managerのプレビュー機能だとイベントの重複がわかりづらかったり、実際にパラメータに入る値がわからないので、面倒ですがGoogle Analyticsのデバッグ機能も使っています。
↓Google Tag Managerのプレビュー機能だと実際にパラメータに入る値がわからない
↓Google Analyticsのデバッグ機能だと実際にパラメータに入る値がわかる
5. データ分析者しかわからない用語になってる！
例えば実行者向けのページへの流入元として「top_button」と書いてあったら、
これがどのページのどのボタンのことを指しているか非常にわかりづらいと思います。
「top_button」は実際にdbtの中で設定しているキーワードで、「トップページのヒーローエリアの[プロジェクトをはじめる]ボタン」のことなのですが、このようなデータ分析者が独自に設定した用語（特に英語のまま）だとわかりづらいので、可視化する際には和名に直すこと、その処理をクエリ上ではなく汎用的に使えるようdbtでやっておくことを意識しています。
↓日本語にクリックパーツ名を変換している例
↓「top_button」の正体は緑枠で囲ったボタン
6. どこにデータがまとまってるのかわからない！
かつては1施策1ダッシュボードにしていましたが、
作った本人の自分はどこでグラフを見られるのかわかっていても、チームメンバーまではなかなか浸透していない（と僕が感じる）ことがありました🤔
そこで、複数施策を1つのダッシュボードにまとめて、週次定例での確認に適した形にしました。
↓クエリ自体も増えていくが、クエリをまとめたダッシュボードもどんどん増えていく
7. ダッシュボードが重い！
Redashの1つのダッシュボードに複数施策を詰め込みすぎた結果、重たくなりグラフの表示にも時間がかかるようになり、操作性が悪くなってしまったことがありました。
そこで施策をリリース時期ごとにまとめる（四半期〜半年単位くらい）ことで、軽量化と見やすさのバランスを取りました。
↓なかなかグラフが表示されないダッシュボード（61個グラフがあるダッシュボードで、更新に10〜20秒くらいかかる）
8. 施策の効果が結局どんな意味を持つのかよくわからない！
例えば「クリック率が5%から10%になりました」は結構改善していそうなのですが、
結局これが会社の業績や部門の目標レベルの指標にどんな影響を与えたのかはわかりづらいということがあります。
そこで、ダッシュボードでは「効果が一番はっきり出る指標」をまず大事にしつつ、「アウトカムとして見るべき指標」を加えたりしています。
たとえば、クリック率は「効果が一番はっきり出る指標」で、支援数（クラウドファンディングサイトで金銭の対価としてリターンをもらう申し込みをした数）は「アウトカムとして見るべき指標」として扱うことが多いです。
9. 「新奇性効果」で一喜一憂しちゃう！
リリース直後、「なんだこのボタン」などとユーザーが感じ、その新鮮さから一時的に好結果が出ることがあります。
これを「新奇性効果」と言うのですが、リリース当日や翌日は本来のそのUI以上の結果が出たりします。
そして、その後落ち着くというケースが少なくありません。
リリース後の初動は一番気になるので見るは見るのですが、最終的に施策の効果を結論づけるのは数ヶ月は置いてからするようにしています。
イメージは、プロ野球の名球界に入るのは現役引退後しばらく経ってから、という感じです。
10. 時系列グラフの期間の粒度がちょうどよくない！
リリース直後は日次グラフで効果を測定していたものの、時間が経つとデータ量が多すぎてノイズが目立つようになることがあります。
こういうときは週次や月次のグラフを加えることで、全体のトレンドが掴みやすくなります。
逆に、リリース直後から月次のグラフを見ていると、伸びたのかどうかがよくわからないことになってしまいます。
面倒ですが、同じ指標でも「日次・週次」や、「日次・月次」、「週次・月次」などの期間の粒度（ディメンション）を変えたものを用意しておくと、短期間と長期間の分析ニーズ両方に応えられて便利です。
↓直近30日で見るときは日次の方が見やすい
↓直近1年で見るときは週次の方が見やすい
11. 期間をちょっと変えるだけなのに変更が面倒！
特にクエリを書く側ではなく、データを見る側の立場に立ったときに、「ちょっと期間を延ばして見たいんだけど」ということがよくありました。
例えば過去からの長期トレンドで見たいときや、打った施策が数ヶ月前になってきたときなどです。
そのため、Redashのクエリのパラメータ機能で「Date Range」という型を使い、分析対象の期間は可変にしています。
デフォルトは「直近30日間」にしてあって、少し前から見たいときは2クリックで期間を変えられる、というようにしています。
↓デフォルトは「直近30日間」
↓他の期間にも簡単に変更可能
↓日付指定も可能
12. 定例で効果の確認に時間がかかっちゃう！
ダッシュボードを1つにまとめたので、気軽にエンジニアもダッシュボードを見られるようになったのですが、いかんせんたくさんのグラフをまとめすぎていて、サッと見たいときにどのグラフを見ればいいのかわかりづらくなる問題が出てきました。
エンジニア3名との4人チーム定例で、毎週司会者を変えているのですが、僕以外が司会で「ワクワクドキドキ効果コーナー！！！」になったときに、あまり見なくてもいいグラフまで拾わなければいけないように感じて時間がかかりすぎることがあったので、このコーナーは僕がいつも話すように変えました🙋♀️
また、他のアジェンダで時間が足りなければ、自分は別時間で見ておいて、重要そうなグラフだけSlackで共有するようにしています。
最後に
READYFORのプロダクト開発では、日々のデータから得られるインサイトを元に、施策の改善や次のアクションを検討しています。
数値で可視化したデータは時折予想外の結果をもたらしますが、これもまたプロダクトの成長につながる大切な要素です。
一方で、可視化を進める中で発生する課題、例えば確認コストの増加については、引き続き試行錯誤を重ね改善していきたいと考えています。
本記事ではREADYFORの取り組みを紹介しましたが、他のサービスやチームでどのように施策効果の可視化を行っているのかも非常に興味があります！
特にRedashやdbtを使っている方々は、ぜひその事例をお聞きしてみたいです！
ぜひコメントをください💬
明日12月4日のREADYFORアドベントカレンダー2024は今同じチームでエンジニアをしている@toyocさんの担当です。
ぜひお楽しみに！
もしREADYFORのPMに興味があるという方はぜひお話ししましょう〜！🙋♀️
日本初クラウドファンディングの「READYFOR」サービスサイトはこちら
READYFOR採用ページ
READYFORのZenn公式ページ
僕のX
僕のnote
「みんなの想いを集め、社会を良くするお金の流れをつくる」READYFORのエンジニアブログです。技術情報を中心に様々なテーマで発信していきます。 ( Zenn: zenn.dev/p/readyfor_blog / Hatena: tech.readyfor.jp/ )
Discussion