これまでの自分の経験に基づいて，データ分析の際に気を付けておくべきことを3つに纏めました．
後輩の進捗報告を聞く時などによく指摘する事で，データ分析の経験が浅い人が見落としがちな事を中心に書きました．
目的と手段
データ分析で一番最初に行うことは，目的の設定，もしくは目的を正しく理解することです．
前者は自分で目的を設定する場合，後者は目的が既に決まっている（例えば，上司や先輩が目的を設定してそれが担当者に降りてくる）場合です．
前者の場合は問題が起きることはほぼありませんが，後者の場合は手段が目的となってしまうという問題がよく起こります．
例えば，有料会員を増やすことが目的の場合に，上司や先輩が「まずはユーザをクラスタリングに掛けてみれば？」とアドバイスします．
そうすると，最初は目的を意識できているのですが，いつの間にかユーザをクラスタリングに掛けることが目的になっていたりします．
その結果，複雑なロジックでユーザをクラスタリングに掛けたものの，「So what?（だから何？）」になる事が多いです．
前記の例では，ユーザをクラスタリングに掛けることはあくまでも手段の一つなので，
- ユーザをクラスタリングに掛ける以外に，何か良い手段はないのか？
- 例えば，離脱率が高いページを見つけ，そのページを改修する方が効果的かもしれません．
- ユーザをクラスタリングに掛けた後に，具体的にどういう施策を打てるのか？
について考える事にもっと時間を割いた方が良いかもしれません．
そして，その方が結果的にROI(Retrun On Investment)が高くなるというのはよくあります．
データ分析の際は，目的と手段を明確に意識しておくことが大切です．
データの信頼性
目的と手段が整理できれば，いよいよ分析作業に取り掛かります．
但し，分析作業に取り掛かる前に確認すべき事があります．それがデータの信頼性です．
例えば，
- データが欠損している
- データは入っているが，正しくないデータが入っている
という事はよくあります．
後者の例として，ログデータのタイムスタンプが2030年などになっており，「未来のデータがやってきた！？」となるのはどの会社でもよく聞く話しです．
この場合，
- タイムスタンプが正しくない（例：未来の時刻になっている）データは分析対象から外す
- ログの取得部分のシステムを修正する
- 前記の例では，クライアント側で設定している時刻を取得している事が多いので，サーバ側で設定している時刻をタイムスタンプとして取得するようにシステムを修正します．クライアント側の時刻はユーザが自由に変更できますが，サーバ側の時刻がズレているということはほぼないので．
の対応策を取る必要があります．
信頼性の低いデータから導き出された結果は，時に間違った結論になり得ることがあります．
データ分析の際は，データの信頼性を担保することが大切です．
また，データの取得条件を揃えることも重要です．
例えば，ユーザの過去一年分のログデータを分析する場合を考えてみましょう．
その際，Aさん，Bさん，Cさんの過去一年分のログデータを取得しようと思って，
select
*
from
pv_log
where
created_at < current_date
and created_at >= current_date - interval '1 year'
and user_id in ('A', 'B', 'C')
;
のようなSQLでデータを抽出しました．
ただ，上記の場合に一つだけ気を付けなければならない事が一つだけあります．
それは，上記で抽出したデータは必ずしも一年分のログとは限らないという事です．
どういう事かと言うと，
- Aさんは2年前に会員登録
- Bさんは1年半前に会員登録
- Cさんは1ヶ月前に会員登録
だった場合に，Cさんのデータは実質一ヶ月分しかないという事です．
一年分のデータと一ヶ月分のデータを比較すると，前者の方がページ総閲覧数や総滞在時間は多い可能性が高く，また，休眠ユーザになっている可能性も高いです．
それでは，どう対応すれば良いのかというと，例えば，1年以上前に会員登録したユーザだけに限定した上で会員登録後一年間のデータを抽出するというのが一つの解決策です．
そうすれば，データの取得条件がより等しくなり，同じ土俵の上で分析を行う事が可能になります．
もちろん季節要因（夏に会員登録したユーザと冬に会員登録したユーザはサイト上の動きは違うかもしれない）などの因子は等しくなっていませんが，今回はそこまで深掘りはしません．
比較対象
データの信頼性も担保できれば，いよいよ本丸の分析作業に取り掛かかります．
ただ，ここでも注意することがあります．それは，適切な（正確に言うと，可能な限り条件が等しい）比較対象を設定することです．
分かりやすい例として，ネット広告におけるCPA(Cost Per Action)の分析を考えます．
今，10,000円のバナー広告を出稿し，バナー広告経由の予約が5件発生したとします．
この場合，CPAは2,000円（=10,000円 / 5)となり，想定していたCPAよりも高い・安いでバナー広告の価値を判断することが多いと思います．
本当にこれでいいのでしょうか？
結論としては，これで判断することは非常に危ういです．
理由は，5件の予約の中に，バナー広告が掲出されなくても発生した予約があったかもしれないからです．
特にリターゲティング広告においては，後で予約しようと考えていた所にたまたまバナー広告が表示されたので，それをクリックして予約したという状況は十分に起こりえます．
それでは，どう対応すれば良いのかというと，適切な比較対象を設定するということです．
前記の例では，バナー広告が表示されないユーザ群も用意するということです．
そして，バナー広告が表示されたユーザ群と表示されなかったユーザ群の予約件数の差を計算し，それを基にCPAを計算します（下記の例ではCPAは5,000円となります）．
実際のバナー広告ではユーザの制御（広告を表示するユーザと表示しないユーザの制御）が難しいので，期間で分ける事が多いです．
例えば，ある月の前半はバナー広告を出稿する一方で後半はバナー広告を出稿せずに，その予約件数の差を見るというものです．
A/Bテストは皆さんご存知だと思いますが，これはまさしく適切な比較対象を設定するための手法です．
データ分析の際は，適切な比較対象を設定することが大切です．