データ分析・集計で気をつけている8つのこと

本記事はWantedly 21新卒 Advent Calendar 2021の12日目の記事です!
なんとか半分まで来ました。後半戦もよろしくお願いします🙏

本記事では、入社してからデータ分析する中で先輩からいただいたフィードバックをまとめてみました。当たり前のことも多いですが、時間に追われ、焦ってしまうと意外とできないので、自戒の意味も込めてここに残しておきます。

集計前(目的理解・課題設計)編

集計の目的を理解する

「〇〇を集計して」と依頼された時は、なぜその集計が必要なのか理解してから、手を動かすようにしています。目的に応じてアウトプットが変わりうるからです。

例えば「プラットフォーム内のユーザ数を集計して」と言われた時に、「特定経路のユーザ流入が減っている懸念」が背景にあれば、アウトプットには「流入経路ごとのユーザ数」が必要です。
一方、「グロース施策の打ち手を決めたい」という背景があれば「セグメントごとのユーザ数」が必要でしょう。

出戻りを防ぐため、プロジェクト全体の流れから目的を推察し、集計を始める前にチームメンバーに確認してから進めると良いでしょう。

比較時は、あらかじめ解を出せる基準を定める

A/Bテストなど、複数の施策やモデルの比較をする場合、あらかじめ解を出せる基準を定めるようにしています。数字を見てから結論を出すと、「自分が作ったモデルや施策の方が良いだろう」というバイアスに引っ張られた解釈をしてしまうからです。

「一般的なメール開封率xx%より5%高かった場合、送信対象者はこのメールのコンセプト興味を持っていると言える」というような明確な基準を定めてから手を動すと良いでしょう。

集計方針・指標の定義・アウトプット形式を共有してから集計する

集計方針・指標の定義・アウトプット形式を共有し、認識を揃えてから、集計するようにしています。自然言語でのやりとりでは意外と齟齬が生まれやすく、出戻りの原因になるからです。

例えばメールのクリック率の集計をする場合、一口にクリック率と言っても、"クリック回数/開封数", "クリック人数/開封数", "クリック回数/送信数", "クリック人数/送信数"のように如何ようにも定義が作れてしまいます。

集計前にアウトプット形式を定められるくらい綿密に集計方針を決めることで、出戻りを防ぐことができます。また、方針をあらかじめ考えておくことで、クエリを書く作業と明確に切り分けることができ、効率が上がるという副次的な効果も得られます。

集計中(クエリ作成・評価)編

必ず定性評価する ＆ 定性評価も基準を設けて定量的に測る

例えば機械学習モデルを作った時、オフライン評価値で定量評価をすると思います。この時必ず、定性評価(人の目で出力のチェック)もするようにしています。人間の知覚能力は意外に高く、定量的に評価しきれない部分に対して、洞察を得ることができるからです。

アイテムを推薦するランキングモデルであれば「Top10アイテムのURLに実際にアクセスしてチェック」のように、定性評価をします。

また、定性評価をモデルの選択などの意思決定に使う場合、「誰が見返しても同じように評価できる」、「手がけたモデルに対して、バイアスが働かせない」ために以下のように基準を設けて、定量的に測るようにしています。

悪い定性評価の例

• ランキング上位のアイテムを確認し、ユーザの嗜好にあったアイテムが出ているかチェックする

良い定性評価の例(もっといい例があったかも...)

• 新旧２つのランキングのtop10アイテムを以下の基準で採点し、この合計値が高い方を採用する
• • 1: ユーザが過去閲覧したカテゴリと同じなど理由から、購入する確率が高いアイテム
  • 0: 購入する確率について判断する材料がないアイテム
  • -1: ユーザが既に購入しているなどの理由から、購入する確率が低いアイテム

ファクトとディメンションを意識してクエリを書く

集計クエリは、どんなファクト(=指標)とディメンション(=切り口)で集約すれば欲しい値が得られるかを考え、アウトプットに必要な中間テーブルを洗い出してから、クエリを書くようにしています。

クエリの集計ミスはほとんどがwhereやjoinで起こるため、集約に必要なkeyを揃えた中心となるテーブルを用意し、そのテーブルに各ファクトをjoinしていくと良いと思います。

必ずクエリ結果のセルフレビューをする

集計クエリは必ずセルフレビューするようにしています。アプリケーションのコードと違い、集計クエリは間違っていてもエラーを吐き出さず、ミスに気づきにくいからです。

セルフレビューする際は以下のようにチェックをしています。

• 集約前の中間テーブルを適当なkey(ex. user_id, やitem_id) で絞って、要件通りに値が入っているか確認する
• 集約結果のディメンション(ex. item_id, user_id)のURLを発行して正しそうか確認する

集計後(まとめ・レポート)編

報告時に必要な情報を落とさない

集計結果をもとにマネージャーに意思決定を依頼するときは、重要な部分に絞って共有する必要があります。その時は必要な情報を落とさないように、以下のことを心がけています。

• クリック率など、割合の指標は分子/分母を表記する
• 定量的な結果はdropしない
• 事実と解釈を明確に分けて書く
• 結果から考えうるNextActionを提示する

レポートには再現可能な情報を残す

集計結果をレポートする場合は、誰が見ても再現可能な情報を残すようにしています。検算や再度似た集計をする場合の足掛かりになるためです。具体的には、書いたクエリ、使った指標の定義をまとめています。

おわりに

入社直後は「高度な技術を学んで、複雑な分析ができるようになるぞ！」とか、「分析だけじゃなくてアプリケーション開発もできるようになるぞ！」とか意気込んでいたのですが、意外と基本的な項目を押さえ、ミスなく分析をすることだけで難しいんだなと気付かされました。

簡単に身につくことではないので、日々の業務を丁寧にこなして自然にできるようにやっていきたいです💪

参考書籍・記事

これまでのデータ分析・集計で参考になった記事や書籍を紹介しておきます。こちらも合わせてご覧ください🙏

SQLに関する書籍

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ

SQLを扱うエンジニア必携のロングセラー、10年ぶりの改訂！――SQLの正しい書き方・考え方が学べる本 開発者のためのWebマガジン「CodeZine」の人気連載を大幅加筆・修正して2008年に刊行、好評を博した『達人に学ぶSQL徹底指南書』の改訂・第2版です。 ...

https://amzn.to/3ERxWXK

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ時代のSQL活用術・レシピ集 本書は、著者が普段の業務で実際に作成しているレポートやSQLのコードをより汎用化し、レシピ集としてまとめたものです。「データの加工」「売上の把握」「ユーザーの把握」「Webサイト内のユーザー行動の把握」「異常値の検出」「検索機能の評価」「レコメンド」など、具体的なシーン別に、実践的な手法とノウハウを解説しています。 ●読者対象 ...

https://amzn.to/3EO2idH

ロジカルシンキングに関する書籍

イシューからはじめよ──知的生産の「シンプルな本質」

★ロジカルシンキング・問題解決の決定版★ ★AI×データ時代の必携書★ 発売10年、支持され続けて45万部突破! やるべきことは、100分の1になる! コンサルタント、研究者、マーケター、プランナー...... 生み出す変化で稼ぐ、プロフェッショナルのための思考術 「脳科学×マッキンゼー×ヤフー」 トリプルキャリアが生み出した究極の問題設定&解決法 〈圧倒的に生産性の高い人〉に共通する問題設定&解決法 「イシュー」とは、「2つ以上の集団の間で決着のついていない問題」であり「根本に関わる、もしくは白黒がはっ

https://amzn.to/3lYdoFM

論点思考 内田和成の思考

Amazonで内田 和成の論点思考 内田和成の思考。アマゾンならポイント還元本が多数。一度購入いただいた電子書籍は、KindleおよびFire端末、スマートフォンやタブレットなど、様々な端末でもお楽しみいただけます。

https://amzn.to/33gLOwN

仮説思考 BCG流 問題発見・解決の発想法

仮説から始めれば作業量は激減する! BCGコンサルタントが3倍速で仕事を進められる秘訣は本書にある! ! 情報が多ければ多いほど、よい意思決定ができる。このように信じているビジネスパーソンは多い。そうであるがゆえに、できるだけ多くの情報を集め、それらを分析してから、経営課題の本質を見極め、解決策を出そうとする。 実際に起こることは何か? ...

https://amzn.to/31Xb7TV

文章の書き方

図解でわかる！理工系のためのよい文章の書き方 論文・レポートを自力で書けるようになる方法

Amazonで福地 健太郎, 園山 隆輔の図解でわかる！理工系のためのよい文章の書き方 論文・レポートを自力で書けるようになる方法。アマゾンならポイント還元本が多数。一度購入いただいた電子書籍は、KindleおよびFire端末、スマートフォンやタブレットなど、様々な端末でもお楽しみいただけます。

https://amzn.to/3lXgWIk

コミュニケーション技術 実用的文章の書き方 (中公新書)

Amazon.co.jp: コミュニケーション技術 実用的文章の書き方 (中公新書) eBook : 篠田義明: 本

https://amzn.to/3DLraRZ

クエリに関する記事

分析用SQLを書くときの思考回路について｜だみ〜｜note

本稿では、分析用のSQLを書くときに則っている思考回路について述べて行こうと思います。この言語化はあまりきちんとされている印象が無いので、自分がそこそこ初めての言語化だと思って頑張ってやってみようと思います。言い換えれば、私はこういう思考回路でSQLを書きますが、みなさんどうですか、という話でもあります。あとは、前提として、現代的な分析用の分散エンジンにSQLを投げるときを考えています。それ...

https://note.com/genuinedammy/n/n2f8fb3654413

BigQuery を使って分析する際の tips (part2)

part2 はスカラー関数・集計関数・分析関数、サブクエリ、型変換について書く BigQuery は便利な機能が色々備わってるので、それらの基本的な振る舞いを頭に入れておくと便利 本文と全然関係ないけど自分のブログはコードブロックの表示とかイマイチなので改善せねばか... part1 に続いて part2 として、分析する際によく使うことになる道具について理解しておくとよいことをいくつかピックアップしてまとめる。 ちなみに今回の tips シリーズではクエリのパフォーマンスは気にしない。 自分が現状仕事で

https://yoheikikuta.github.io/BigQuery_tips_part2/

スタースキーマ(基礎)

スタースキーマ wikipedia スタースキーマ または 星型スキーマ はデータウェアハウスに利用される最も単純なスキーマである。スタースキーマには唯1つもしくは少数のファクト表と複数のディメンション表が含まれる。スタースキーマはスノーフレークスキーマの一種であるが、多くの用途で利用されている。 スタースキーマは、ディメンションモデリングをリレーショナル・データベースで実装したものになる。

https://zenn.dev/pei0804/articles/star-schema-design

ディメンション・モデリング

VOYAGE GROUP Techlog Advent Calendar 2020 13日目 ディメンション・モデリング Wikipediaには以下のような説明がある。 Dimensional Modeling (DM) is a data structure technique optimized for data storage in a Data warehouse.

https://zenn.dev/pei0804/articles/dimensional-modeling