現場データサイエンティスト奮闘記

とある企業で働くデータサイエンティストの日々のアウトプット

データに不慣れなコンテンツ編集チームを2ヶ月でデータドリブン組織にした6つの方法

データ分析 ノウハウ

概要

この記事について

明けましておめでとうございます。新年1本目です。2019年ものんびり更新していければと思います。

さて、会社ではデータサイエンティストをしているのですが、「データ見れるようになりたい！」と他部署の方から相談を受けまして、ちょっとコンサルっぽいことをしておりました。その時にやったことのノウハウを公開できればと記事にしました。

そのチームはwebメティアで記事制作と編集を行うチームだったのですが、「自らデータを用いて物事の意思決定を行えるようになり、記事の完読率を向上させるグロースハックをする」というのを目標にしています。
この「データを用いて物事の意思決定を行えるようになる」という部分を2018年11月〜12月の2ヶ月間お手伝いさせていただき実現しました。

実際、2ヶ月後には自分たちだけで施策の実験としてABテストを行い、改善の精度を判断して施策の実行の意思決定ができるようになりました。

チームが2ヶ月で身につけたこと

データドリブンな意思決定を行うために、チームは具体的に以下のスキルを身につけました。

  • 自分たちのチームのKGI, KPIの数字のロジックを正確に理解している
    • 重要指標 KPI については、自らデータ分析をし更に細かい粒度で絞り込み施策のターゲットを詳細に詰めることができる
  • データを用いた仮説検証のプロセスを理解し、実践した
    • 仮説の根拠は定量的な証拠を示しながらその妥当性を主張できる
    • 相関関係と因果関係の違いを理解して、相関がある際も因果関係の証明を行う実験を行った
    • 検証の際には統計的な知識を用いて誰もが同じ水準で意思決定できるようになった（判断が属人化しない）
  • データを元に施策のターゲット・優先順位を明確に決めることができる
    • やるべきこと、しなくてもいいことの判断をメンバー全員が行える
  • 施策に対して実験計画を立案できる
    • 成功・失敗の基準が明確なのでPDCAのスピードが上がった
  • SQL, 統計検定手法を身につけた
    • データ収集から集計・統計による判断まで一通りを自分たちだけで行えることを意味する

これらをピックアップした理由は「データを用いて自分たちだけで仮説検証・意思決定までを自分たちだけで行えるような組織づくり」を実現できるのに必要なスキルを一通り身につけるためです。

チームがデータドリブンになるために具体的にやったことまとめ

実際にチームが上記のようなスキルを身につけるために行ったことを順番に挙げていきます。

1. 毎日データを必ず見る環境をつくる

習慣化させるには、日常の中にデータがあるような環境を整えてあげる必要がありました。
会社ではコミュニケーションツールとしてSlackを日常的に使っています。このツールにデータを混ぜていきます。

そのために、redashでKPIを可視化し、そのグラフや数値をSlackに毎日投稿することで毎日必ずデータを見る習慣をつけました。
日々の数値の動きを見ることでユーザーの動きを敏感に察知することができるほか、データそのものをまず身近に感じるための手段として用いています。

2. Google Analyticsを用いてKPIを深掘り

記事の完読率を上げたいので、完読する人・しない人の属性でユーザー行動をGAで分析し「直帰率・滞在時間」の2つに焦点を当てて仮説検証を行うことを決めました。
完読率をKGIとすると、直帰率と滞在時間はKPIという位置づけです。

3. KPIのボトルネックとなっているであろう仮説のアイディア出し

いきなりアイディア出しをするのではなく、KPIである「直帰率・滞在時間」の2つにとってのボトルネックを考えることで、具体的なアイディアが出ました。
また、「一見良さげだけど、直帰率や滞在時間に効かないならやらなくていいよね」という取捨選択も容易でした。

仮説を出すときのコツとしては「ユーザーは不満に思うだろう」という気持ちの部分で終わらずに「ユーザーがここでイライラした結果、サイトを離脱してしまうだろう」と行動ベースで考えた点です。
ユーザーが本当に不満に思っているかどうかは知りようがないですが、離脱しているかどうかは事実として計測することができるため、仮説の妥当性をデータで示すことが可能になります。

4. 仮説の前提が事実かどうか確認する

意見の一つに「長文記事は読まれづらい（完読率が低い）から、記事を短くしてはどうか」というものがありました。
しかし、よく考えてみると「長文記事は完読率が低い」という前提は無条件に肯定しても良いのでしょうか？
この前提が崩れていた場合、この仮説は説得力を失うことになります。

実際に記事の文字数と完読率の相関性を調査したところ、相関関係としては長文ほど完読率が下がる結果となり、この仮説は妥当であることが示されました。
しかし同時に完読率が著しく下がる長文記事の文字数は5,000文字以上であることがわかり、5,000文字を超えるような記事は全体のほんの数%しかないため、これを改善しても全体の完読率の改善にはほとんど影響しないことがわかりました。

結果としてこの仮説は棄却されることとなるのですが、意思決定を行う前にデータで根拠を示しておくことで必要性の有無を判断できるという好例でした。

5. 施策の優先順位を決めてABテストで実験した

ある程度確度の高い仮説が出揃ったら、優先順位を決めます。優先順位の決め方には色々あるでしょうが、今回は「直帰率に最も効きそうな順」で優先度を決定しました。

  • 記事の動線を整備する
  • 目次の充実化
  • 図表を増やす

上記2点は、内部事情でシステム開発が必要でありライター・編集者のみからなるこのチームだけではすぐには動けませんでした。
こういった制約もあるので、実際に最初に行う施策はチーム内で完結する3つ目の「図表を増やす」にしました。

ここで気をつけなければならないのは「図表を増やすことで直帰率が改善する」のはあくまで仮説であって事実ではありません。また、相関があったとしても因果関係ではありません。
この仮説が事実であるかを確かめる実験が必要です。

因果関係を証明する一つの手段としてABテストがあります。今回は図表を増やす記事、増やさない記事を10記事ずつ用意してABテストを実施しました。
ABテストの結果はカイ二乗検定という統計検定の手法で定量的に判断が可能なので、redashを作成して毎日数値をチェックしながら有意差がでるまでテストを実施しました。

結果は有意差が出て、「図表を増やすことで直帰率が改善する」ことが確かめられたので、実際に全ての記事に画像を挿入する施策へと展開しました。
ちなみに、実験の開始から全記事に展開するという施策の意思決定までわずか10日ほどです。非常に判断がスピーディーです。

このように小さく実験を行うことで施策の実行スピードを早めることが可能です。

6. SQLを実際に書き、カイ二乗検定を実際にやってみた

データを用いて意思決定を行う以上、自分たちだけである程度はデータを扱うことが必須です。 データの収集・集計の手段としてSQLというプログラミングを用います。統計に基づいて判断するためにカイ二乗検定の手法も学びました。

チームにはプログラム未経験者が多くいたので、SQLは基礎から教えています。初心者でもとっつきやすい言語なので1〜2週間ほどで基本的な構文は扱えるようになり、記事の完読率程度であれば自力でデータ収集できるようになりました。

カイ二乗検定にしても、Google スプレッドシートには CHITEST という関数があり、これでカイ二乗検定のp値を算出できるので、やり方さえ覚えればプログラミングなしでも誰でもできます。

終わりに

データに不慣れであっても、習慣化や自力でデータを扱う訓練を行えば、それを使って改善に活かすこともできるという例です。

この記事自体は、社内向け資料として作った資料を外部に公開できるように実データを伏せたり色々ぼかしたりしてリライトしています。
画像とか具体的な数値があった方がイメージが伝わりやすいかなと思いつつも、機密情報ですので泣く泣く断念しています。文字ばかりで読みづらい記事になってしまいましたが、ご容赦いただければ幸いです。

この記事が似たようなことでお困りの方に少しでも助けになれば幸いです。