Gunosyデータ分析ブログ

Gunosyで働くデータエンジニアが知見を共有するブログです。

不確実性と向き合うデータ分析

本記事は、Gunosy Advent Calendar 2020 12日目の記事です。

昨日はGTL所属の山本さんの「Terraform のエラーに落ち着いて立ち向かうために - Gunosy Tech Blog」でした。 GTL(Gunosy Tech Lab) 所属の大曽根です。オンライン会議は耳が痛くなるのでスピーカー+指向性マイクで運用しています。ダイナミックマイクは不要な気がしてきました。

はじめに

Gunosy (に限らず多くの企業) では、日々の施策の解釈にデータを活用しています。 しかし、データを集計するだけで結果がわからないこと (解釈の難しさ) や結果がわかりやすくても回答を見誤ることも多くあります。 その中で気をつけないといけない部分に関してざっくりまとめます。

基本のサイクル まず、非常によく使われる、仮説から検証可能なモデルを作成し、計測、学習する改善のサイクルです。

f:id:dr_paradi:20201211002833p:plain
改善のサイクル

データを見るのは当たり前でデータが起点ではないということです。 あくまで、仮説の成否を判断し、次のアクションにつなげるのがデータであるということを忘れてはいけません。

よく間違えがちなのが、仮説の時点で * この指標 (PVなどのKPI) を高める => この機能いるよね => A/Bテストしましょう (KPI見るだけなので楽)

になると仮説も浅いため、仮に失敗した後の学習も少なくなってしまいます。 易きに流されず下記の流れでしっかり行うことで、仮に失敗したとしても学習の結果をしっかり次に生かすことができます。

  • ユーザの課題解決するためにこの機能いるよね => それを証明するにはこういう指標がいるよね => A/Bテストしましょう (ログも含め実験の設計をちゃんとしないと事故るし大変)

もしくは

  • この指標 (PVなどのKPI) が (競合など比較して) 低い/下がっている => こういうユーザの課題があるのよね => なのでこの機能いるよね => A/Bテストしましょう (KPI見るだけなので楽)

の流れにすることで組織としてもプロダクトとしてもより学習の効率が上がります。

KPIツリーが全てではない

事業を理解し、また施策の優先順位を考える上でKPIツリーを作成するのは非常に重要です。 例えば、メディアビジネスなどは

f:id:dr_paradi:20201212202738p:plain
KPIツリーの例 (一部)

Revenue = PV * 1PVあたりの広告数 * 広告単価 PV = 1ユーザあたりの回遊数 * ユーザ数(DAU) のようにかけます。 DAUの算出方法などに関して気になった方は下記のブログを読んでみてください。

data.gunosy.io

KPIツリーという概念は非常に便利で、組織を分割した際にも「それぞれのKPIをどの程度伸ばすか」という目標を設定できます。 しかし、前述の 「この指標 (PVなどのKPI) を高める」という発想になり、ともすれば、ハック思考に陥りやすい点も注意が必要です。加えてARPU/ARPPUなどの割り算系の指標で分母が小さい場合に数値が大きくなり、成功したと判断してしまいスケールができない場合や、相互作用のある指標を見逃すこともあります。以下に

KPI自体は変数ではない

よくある問題で、KPI自体がコントラーラブルな変数であると誤解する場合です。自分のコントロールできる変数によるKPIの影響を把握する必要があります。目標設定や、施策の成否に対してKPIに関連し、かつその指標を見ることでチームが行動可能になる適切なメトリクスを選択する必要があります。

www2.slideshare.net

古典的で簡易な例として、野球では得点と失点を使ったピタゴラス勝率というものがあります。おそろしく当たり前の話として勝つためには得点を増やし、失点を減らすことが重要という指標になります。「得点を増やす」という指示だけではいくらなんでもチームを動かすのは難しいと思います。ホームランを打てば勝てるので、ホームランを打てる打者を獲得するだと選択肢の幅が狭くなってしまいます。 そこで、今度は(たまたま)得点相関の高い (上に計算の容易な) OPSという指標を下位の概念に持ちます。この指標は (四死球を含めた) 出塁率が上がれば高くなります。そうすると、打率の割に出塁率が高いバッターを獲得しようという人事戦略をとる、チームとしてファーストストライクまでは極力振らないようにするなどの選択肢を持つことができるようになります。

各指標で相反はないのか

KPIツリーから施策を考えた時に、各指標があたかも独立であるかのように思いやすい問題もあります。 有名な例として、限界効用逓減の法則があります。多くのアルゴリズムは

Revenue = PV * 1PVあたりの広告数 * 広告単価

を考えた場合、基本的に 1番目の広告の効果 >= 2番目の広告の効果 となり得るので、片方の変数を増加させた際に、上昇の度合いが次第に鈍化するようになります。 パラメータを変化させた時にどのような曲線を描くのかを考えることは非常に重要です。

ノイズは問題ないか

(施策効果の見積もりができている前提で)施策の効果を測定する際に季節性を考慮するのも意外に忘れがちです。 (季節性という程ではないですが、月毎に日数が異なるのも意外と面倒くさかったりします) 季節調整モデルなどを導入することである程度のノイズを除去することができます。 詳細は下記のブログにある通りです。

観測データ(生データ) = トレンド成分 + 季節成分 + 残差 で表現するものです。

旅行系のサービスであれば連休が多いシーズンの直前にユーザのアクティビティは上がるでしょうし、スポーツ系のサービスはシーズン以外はあまり見られない可能性があります。 アクティビティが低い期間でのアクティビティを強化するか、準備期間に当てるかのいずれが長期的に効果がよくなるかは判断が難しいところですので、サービスのオーナーの判断に任せられる部分かもしれません。

data.gunosy.io

また、昨今ではコロナでの自粛により需要のあり方が大きく変わってきています。 前述のトレンドに加え下記のような成分が追加される印象です。

観測データ(生データ) = トレンド成分 + 季節成分 + 残差 + 自粛成分

この記事にもあるように自粛、GoToトラベルそれぞれで異なるサービスが恩恵を受けていそうです。 「GoToトラベル」効果、アプリに 施策浸透に必要な使い勝手: 日本経済新聞

テストの方法

施策の効果検証にA/Bテストを用いていますが、全員に向けてのキャンペーンなどの検証には因果推論などを用いています (こちらは誰かが後日記事にしてくれるはず...)。A/Bテストでも広告案件の予算など、比較群で共通で持たざるを得ない場合には、A/Bテストの結果がそのまま実際の効果に反映されない場合もあるので注意が必要です・

おわりに

単純にデータがあり、KPIツリーなどで構造化できたとして意思決定を誤る落とし穴は各所に存在します。 データの活用は非常に重要ですが、失敗するとマイナスに働く可能性もあるので注意して運用する必要があります。 また、以前は正しいと思われてたことでも、新たに指標間での関連性が見つかったり、事業の状況が変化することで最大化 (最小化) するべき変数は変っていきます。そのため組織/文化としても定期的に指標を考え直し、学びほぐしをすることが重要だと考えています。