作成者: Patrick Riley
特に、Diane Tang、Rehan Khan、Elizabeth Tucker、Amir Najmi、Hilary Hutchinson、Joel Darnauer、Dale Neal、Aner Ben-Artzi、Sanders Kleinfeld、David Westbrook、Barry Rosenberg に感謝いたします。
履歴
- 最終更新: 2019 年 6 月
- この資料の一部は、Google 非公式の公式データ サイエンス ブログ（2016 年 10 月）に掲載されています。
概要
膨大なデータから事実と分析情報を導き出すのは、強力ですがエラーが起こりやすいジョブです。優れたデータ アナリストやデータマインド エンジニアは、データから信頼できる発音を行うという評判を確立します。信頼関係を築くために何が行われているか「気配り」や「方法論」などの形容詞を聞いたことはよくありますが、最も慎重で手順に従ったアナリストは実際にどんなことをするのでしょうか。
これは特に簡単な問題ではありません。特に、Google で定期的に収集しているデータの種類を考えると、難しい問題です。通常、Google では非常に大規模なデータセットの処理だけではなく、多くのデータセットを利用できます。つまり、データの各行には通常、多くの属性があります。特定のユーザーのイベントの一時的なシーケンスと組み合わせると、データをさまざまな方法で参照できます。これとは対照的に、典型的な学術心理学の実験では、研究者が個々のデータポイントをすべて参照するのが容易です。Google の大規模で高次元のデータセットがもたらす問題は、科学的研究の歴史の大半に見られる問題とは大きく異なります。
このドキュメントでは、精巧で方法論的なアナリストが大規模な高次元データセットで使用するアイデアと手法をまとめています。このドキュメントではログと試験運用版分析のデータに焦点を当てていますが、これらの手法の多くはより広く適用できます。
このドキュメントの残りの部分は、データ分析のさまざまな側面を網羅する 3 つのセクションで構成されています。
技術
データを検査する方法をいくつか見てみましょう。
分布を確認する
ほとんどの技術者は、分布指標の要約に指標（中央値、標準偏差など）を使用します。ただし、通常はヒストグラム、累積分布関数（CDF）、分位数 / 分位数（Q-Q）プロットなどを生成することで、かなり充実した分布表現を調べる必要があります。これらの表現が豊富なため、マルチモーダル動作や著しい外れ値など、データの重要な特徴を検出できます。
外れ値を考慮する
外れ値は、分析のより基本的な問題を示す採炭場のカナリアの可能性があるため、慎重に調べます。データから外れ値を除外したり、「異常」カテゴリにまとめたりしても問題ありませんが、データがそのカテゴリに分類される理由を確認する必要があります。
たとえば、クリック数が最も少ないクエリを調べると、カウントされていない要素のクリックが表示される場合があります。クリック数の最も多いクエリを調べると、カウントされません。一方、説明できない異常値が存在する可能性があるため、このタスクにどの程度の時間をかけるかに注意する必要があります。
ノイズの検討
ランダム性はあるので、私たちをだまします。「Google には大量のデータがあり、雑音がなくなる」と考える人もいますが、これは真実ではありません。生成するすべてのデータまたは要約には、信頼区間や p 値などの測定値を用いて、この推定値の信頼度を付随させる必要があります。
例を見る
新しい分析コードを作成するときは常に、基盤となるデータの例と、それらの例でコードがどのように解釈しているかを確認する必要があります。このステップを行わないと、実用的なコードを生成されることはほぼ不可能です。分析では、基になるデータから多くの詳細を抽象化して、有用な要約が生成されます。個々の例の複雑さをすべて調べることで、要約が妥当であるという確信を得られます。
これらの例をサンプリングする方法は重要です。
- 基盤となるデータを分類する場合は、各クラスに属するサンプルをご覧ください。
- クラスの規模が大きい場合は、他のサンプルをご利用ください。
- 数値（ページの読み込み時間など）を計算する場合は、極端な例（最速と最遅 5% であること、分布がどのようなものか把握できているか）と、測定空間内のあらゆるポイントを確認します。
データをスライスする
スライスとは、データをサブグループに分割し、各サブグループの指標値を個別に確認することを意味します。通常は、ブラウザ、言語 / 地域、ドメイン、デバイスの種類などのディメンションに基づいてスライスします。根本的な現象がサブグループ間で異なる動作をする可能性がある場合は、データをスライスして、実際に該当するかどうかを確認する必要があります。スライスによって異なる結果が生成されることは想定されていなくても、いくつかのスライスで内部整合性を確認することで、正しい結果を確実に測定できます。場合によっては、特定のスライスに不適切なデータが含まれていることや、ユーザー インタラクションが壊れたり、根本的に異なったりすることがあります。
データをスライスして 2 つのグループを比較する場合（たとえば、テストグループとコントロール グループの比較、さらには「時間 A」と「時間 B」を比較する場合）は、ミックス シフトに注意する必要があります。ミックス シフトは、各グループのスライスに含まれるデータの量が異なるときに行われます。Simpson's paradox とその他の混乱が生じる場合があります。一般に、1 つのスライス内のデータの相対的な量が 2 つのグループ間で同じであれば、安全に比較できます。
重要性の検討
大量のデータがある場合は、統計的有意性を重視したり、あらゆるデータの詳細を求めたりしがちです。しかし、値 X が値 Y より 0.1% 大きいという事実が真実でさえ、自問する必要があります。これは、データの一部を理解/分類できない場合に特に重要です。ログ内に User-Agent 文字列の一部を認識できない場合、データの 0.1% と 10% のどちらを表すかが、ケースを調査する対象を大きく左右します。
あるいは、少量のデータが生じることもあります。多くの変化は統計的に有意ではありませんが、「変化は中立」と主張するのとは異なります。「まだ実質的な変化がどれくらいあるか」と自問する必要があります。
時間の経過に伴う整合性の確認
システムが時間の経過とともに進化するにつれて、基になるデータに対する多くの障害が発生するため、ほとんどの場合、単位時間ごとにデータをスライスする必要があります。（多くの場合、日数が使用されますが、その他の時間単位も使用できます）。 多くの場合、実務担当者は、特徴や新しいデータ収集機能を初めてリリースするとき、すべてが期待どおりに動作しているかを慎重にチェックします。ただし、時間の経過とともに、多くの互換性の問題や予期しない動作が発生することがあります。
特定の日や日付のセットが外れ値であるからといって、対応するデータを破棄する必要はありません。データはフックとして使用し、破棄する日がその日によって異なる原因を特定します。
また、日ごとのデータを確認すると、データにばらつきがあり、それによって信頼区間や統計的有意性が生じることがわかる場合もあります。一般に、厳格な信頼区間の計算に代わるものではありませんが、大きな変更に伴って、日々のグラフのみから統計的に有意な結果が得られることがよくあります。
フィルタの確認とカウント
ほぼすべての大規模なデータ分析は、さまざまな段階でデータをフィルタすることから始まります。たとえば、米国のユーザー、ウェブ検索、広告のある検索のみを検討できます。いずれの場合も、次のことを行う必要があります。
- 確認して、実行しているフィルタを明確に指定します。
- 各ステップでフィルタされるデータ量をカウントします。
後者を行う場合、最良の方法は、除外している母集団の場合でも、すべての指標を計算することです。その後、このデータを確認して、「スパム フィルタで削除されたクエリの割合」といった疑問に対する答えを得ることができます。（フィルタリングの理由によっては、このような分析が常に可能であるとは限りません）。
比率には明確な分子と分母が必要です
最も興味深い指標は、基礎となるメジャーの比率です。多くの場合、分子と分母の正確な定義には、目的のフィルタリングやその他のデータの選択項目がありません。たとえば、「クエリ / ユーザー」が実際に意味するのは次のうちどれですか。
- クエリ / クエリを持つユーザー
- クエリ / 本日 Google にアクセスしたユーザー数
- クエリ / アクティブなアカウントを持つユーザー（はい。active を定義する必要があります）
ここに明確に記載することで、自分自身や他者の混乱を防ぐことができます。
もう 1 つの特殊なケースは、一部のデータに対してのみ計算される指標です。たとえば、「クリックまでの時間」は、通常、クリックがあったことを意味し、「クリックまでの時間」を意味します。このような指標を確認する場合は、フィルタリングを認識して、比較するグループ間でのフィルタリングの変化を確認する必要があります。
プロセス
このセクションでは、データへのアプローチ方法、データについて尋ねるべき質問、確認すべき内容に関する推奨事項を示します。
個別の検証、説明、評価
データ分析は、互いに関連する 3 つのステージがあると考えています。
- 検証1: データは自己整合性があるか、正しく収集されたか、そのデータで機能していると考えられるものだと思いますか。
- 説明: このデータの客観的な解釈は何ですか。 たとえば、「X」に分類されるクエリの数が減ります。""テストグループでは、X と Y の間の時間の方が 1% 長く、「&」が結果の次のページに進む回数が少なくなります。
- 評価: 説明から判断すると、データからユーザー、Google、世界のいずれかに何か良いことが起こっていることがわかります。
ステージを分けることで、他の人と合意に達することが簡単になります。説明には、そのデータについて誰もが同意できる項目を指定します。 評価を行うと、議論がさらに活発化する可能性があります。説明と評価を分離しない場合、確認したいデータの解釈のみが表示される可能性が高くなります。さらに、他の特徴や指標との厳密な比較を通じて指標の標準値を確立するには、多大な投資が必要なため、評価はさらに難しくなります。
これらの段階は直線的に進行しません。データを調べるときは、ステージ間を行き来することもできますが、どのステージにいるかは、いつでもわかります。
テストとデータ収集の設定を確認する
データを確認する前に、データが収集されたコンテキストを理解しておいてください。データがテストから得られた場合は、テストの構成を確認します。新しいインストルメンテーションで行われる場合は、データの収集方法に関する大まかな把握が必要です。通常と異なる構成や不適切な構成、Chrome の有効な制限などの問題が発生することがあります。ここで重要な点があれば、後で理論を構築して検証するときに役立ちます。注意事項:
- テストが実施されている場合は、ご自身でお試しください。できない場合は、少なくとも動作のスクリーンショット/説明を確認してください。
- テスト期間（ホリデー シーズン、大規模なリリースなど）に関して、通常と異なる点がないかどうかを確認します。
- テストの対象となったユーザー グループを特定します。
変更すべきでないものを確認する
「検証」段階の一環として、関心のある質問に実際に回答する前に（たとえば、「顔写真の追加やクリック数の減少は行ったか？」の確認など）、テストに影響を与える可能性のあるデータの変動を除外します。例:
- ユーザー数に変化はありましたか？
- 影響を受けた全クエリの数が、すべてのサブグループに反映されたか？
- エラー率は変化しましたか？
これらの質問は、テスト/コントロールの比較と、時間の経過に伴う傾向の調査の両方に適しています。
標準、カスタム セカンド
新しい機能や新規データを検討する際に、特にこの新機能の新たな指標や特殊指標に目を向けたくなるものです。ただし、指標が変更されることが予想される場合でも、常に標準の指標を確認しておく必要があります。たとえば、新しいユニバーサル ブロックをページに追加する場合は、この新しい結果に関するカスタム指標を使う前に、「ウェブでの検索結果のクリック」などの標準指標への影響を確認してください。
カスタム指標は標準指標よりはるかに検証しやすく、カスタム指標よりも正確である可能性が高くなります。カスタム指標が標準指標と合わない場合は、カスタム指標が間違っている可能性があります。
2 回以上測定する
特に、新しい現象を把握する場合、同じことを複数の方法で測定してみてください。次に、これらの複数の測定結果が一致しているかどうかを判断します。複数の測定を使用することで、測定やロギングのコードのバグ、元になるデータの予期しない機能、重要なフィルタリング手順を特定できます。測定に別のデータソースを使用できる場合は、さらに効果的です。
再現性の確認
スライスと整合性のどちらも、再現性の確認の具体例です。ある現象が重要で意味のあるものである場合は、さまざまな人口と時間にわたってその現象が発生します。ただし、再現性を検証するには、これら 2 つのチェックを行うだけでなく、データのモデルを構築する場合、基盤となるデータの小さな摂動に対してそれらのモデルが安定するようにします。異なる期間またはデータのランダムなサブサンプルを使用すると、このモデルの信頼性、再現性も把握できます。
モデルを再現できない場合は、データを生成した基盤となるプロセスの基本構造を理解していない可能性があります。
過去の測定結果との整合性を確認する
多くの場合、過去にカウントされたものと類似した指標が計算されます。ユーザー グループ別の測定値であっても、過去に報告された指標と比較する必要があります。
たとえば、特定のユーザー層のクエリ トラフィックの平均ページ読み込み時間が 5 秒で、すべてのユーザーの分析結果で平均ページ読み込み時間が 2 秒と測定された場合は、調査が必要です。この数値は母集団に合っているかもしれませんが、さらに検証するためにさらなる作業が必要です。
正確な同意がある必要はありませんが、同じ球場にいる必要があります。そうでなければ、完全に納得できるまで間違った答えを思い浮かべるでしょう。予想外のデータのほとんどはエラーであり、新たな分析情報ではありません。
まず、古いデータまたは特徴に新しい指標を適用する必要があります。
新しい指標を作成して（新しいデータソースを収集するなどして）新しいことを学習しようとすると、新しい指標が正しいかどうかわかりません。新しい指標では、まずそれを既知の特徴またはデータに適用する必要があります。たとえば、ユーザー満足度の新しい指標がある場合は、最適な特徴が満足度の向上に役立つことを示せるようにする必要があります。ユーザーの関心を引くページに誘導するための新しい指標がある場合は、視線追跡や評価担当者による調査から得られた情報と、画像がページの注意力に及ぼす影響に関する調査結果とが一致していることを確認してください。これにより、新しいことを学ぶときに検証できます。
仮説を立て、証拠を探す
通常、複雑な問題のデータ分析は反復的です2。データの異常、傾向、その他の特徴を検出します。当然、このデータを説明するための理論を開発します。理論を立てて、それを真実と主張しない。データの内部または外部でエビデンスを探し、この理論を確認または拒否します。例:
- 学習トレンドに似たものを見つけた場合は、頻度の高いユーザーにとって最も顕著であるかどうかを確認します。
- 異常が一部の機能のリリースに起因すると思われる場合は、その機能が起動された母集団が、異常の影響を受ける唯一のユーザー層であることを確認します。または、変更の大きさがリリースの予想と一致するようにしてください。
- ロケールでユーザー数の増加率が変化している場合は、ユーザー人口の変化率を検証する外部ソースを探してください。
効果的なデータ分析には説得力のあるメッセージが必要です。ストーリーが適切かどうか確認するには、ストーリーを自分自身に伝え、誤りである証拠を見つける必要があります。その方法の一つは、「話している内容を検証 / 検証するために、どのようなテストを実行するか？」と自問することです。このテストを行わなくても、自分のデータを使って検証する方法が見つかります。
幸いなことに、これらの理論や可能な実験が、特定の機能やデータについて学ぶよりも新しい調査に導く可能性があります。その後、このデータだけでなく、あらゆる種類の将来の分析のための新しい指標と手法を導出します。
エンドツーエンドで反復処理を行う探索的分析のメリット
探索的分析を行う場合は、分析全体をできるだけ多く実施します。通常、シグナルの収集、処理、モデリングなどには複数のステップがあります。最初のシグナルの最初のステージを完成させるのに時間がかかりすぎる場合は、同じ時間でより多くの反復処理を行う機会を見逃します。さらに、最後にデータを見たとき、方向性が変わっていくこともあります。したがって、最初から完全に完璧ではなく、全体として相応の何かを得ることに焦点を絞る必要があります。メモを残し、フィルタリング ステップや解析不能なリクエスト、通常とは異なるリクエストなどは承認します。ただし、探索的分析の開始時には、これらをすべて消去するために時間を無駄にしないようにします。
フィードバックにご注意ください
Google では通常、ユーザーの成功に関するさまざまな指標を定義します。たとえば、ユーザーが検索結果をクリックしましたか？そして、そのデータをシステムにフィードバックすることで（実際に多くの場所で実施されます）、評価に関する混乱が生じる可能性が高くなります。
システムにフィードバックされた指標を、変更の評価基準として使用することはできません。クリック数の多い広告が多く表示される場合、ユーザーの満足度を判断する基準として「クリック数を増やす」は使用できません。ただし、クリック数を増やすと「幸せになる」ということも多いのですが、フィードバックや操作を行った変数をスライスすることは避けるべきです。その場合、ミックス シフトがわかりづらい、または不可能になるからです。
マインドセット
このセクションでは、他のユーザーと協力してインサイトを伝える方法について説明します。
データ分析はデータや手法ではなく、質問から始まる
データ分析にはやる気が必ずあります。ニーズを仮説または仮説として定式化すると、収集すべきデータを収集し、データ内のギャップの可能性について検討できるようになります。もちろん、データを見るたびに質問は進化するはずです。ただし、質問なしでの分析は目的を果たさなくなります。
お気に入りの手法を見つけ、この手法がうまく機能する部分だけを見つけるという事態を避ける必要があります。繰り返しになりますが、明確な質問を作成することで、このトラップを回避できます。
懐疑的で擁護者になる
データを操作するときは、得られる分析情報のチャンピオンである必要があり、さらにその懐疑者でもある必要があります。データから面白い現象が見つかるかもしれません。興味深い現象が発生したときは、次の質問を自問します。
- これだけの成果を示すために、他にどのようなデータを収集できますか？
- どうすれば無効になるのでしょうか？
特に、特定の回答を本当に必要とするユーザーについて分析を行っている場合（例: 「私の機能は素晴らしい！」）、エラーを避けるために懐疑的な態度を取らなければなりません。
相関 == 因果関係
データについて理論を立てるときは、多くの場合、「X が Y につながる」というアサーションを行います。たとえば、「ページの速度が遅くなると、ユーザーのクリック数が減ります」xkcd でさえも、相関があるため単純に因果関係を確立できないことを認識しています。因果関係の理論がどのように検証されるかを考慮することで、通常、因果関係の理論の信頼性を判断することができます。
人々は、A と B の間に因果関係がなくとも、一方のシグナルが他方のインジケーターまたはプロキシとして適するように、一致がなんらかの意味を持つものであるとアサーションを行うことで、意味のあるほど相関関係を保つことができます。この領域は、複数の仮説のテスト問題には危険です。xkcd でも認識しており、十分なテストと十分なディメンションがあるため、一部のシグナルは特定のテストに合わせて調整されます。これは、将来、同じシグナルが整合することを意味するわけではありません。したがって、「A と B の両方を引き起こす隠れた効果 C がある」などの因果理論を考慮する同じ義務を負っており、これがどれほど現実的であるかを検証できます。
データ アナリストは、多くの場合、データを利用する人々に対してこうした因果関係のある質問に対処する必要があります。因果関係については、何ができても言えないということを明確にする必要があります。
最初に同僚と情報を共有し、次に外部の消費者と共有
これまでのポイントは、適切な種類のチェックと検証を行うための適切な方法を提案していました。ただし、ピアとの共有は、これらすべてを強制的に行う最善の方法の 1 つです。熟練のピアは、特に情報の受け手が議題を持っていることが多いため、データの利用者と質的に異なるフィードバックを提供できます。ピアは分析を通じて複数の場所で役に立ちます。同僚が知っておくべきこと、測定すべき提案、この分野での過去の研究などについて、早い段階で知ることができます。仲間は最終的に、奇妙さや不整合といった点をうまく指摘できます。
理想的なのは、閲覧しているデータについて熟知している同僚からフィードバックが得られることですが、一般的なデータ分析の経験がある同僚だけでも非常に価値があります。
知識やミスを予想して受け入れる
データから学べることには多くの制限があります。Nate Silver は、シグナルとノイズに関して、確実性の限界を認めない限りより良い予測の進歩を遂げることができるという強力な事例を示しています。知名度なしの承諾は、通常はすぐに助けられるわけではない強みです。当時は評判が悪いのですが、長期的にもエージェントにとってもチームにとっても大きなメリットです。間違えて後で発見したり、遅すぎたりすると、さらにひどい感じになります。しかし、ミスを積極的に備えることで、尊敬の念を持つことができます。それを尊重することで、信頼性とインパクトが生まれます。
最後に
適切なデータ分析を行うための作業の多くが、分析の利用者にとってすぐには理解できません。母集団の大きさを注意深くチェックし、ブラウザ間で効果が一貫していることを確認することによって、このデータから意思決定しようとしている人々の認知度は向上しない可能性があります。また、良質なデータ分析時間がほとんどのユーザーにとって必要であるよりも長い時間がかかる理由も示しています（特に最終出力のみが確認される場合）。アナリストの仕事の一端は、これらのユーザーが何をするのか、なぜそれが重要なのか、データに基づいた分析情報を消費者に徐々に提供することです。
データのさまざまな操作と探索の必要性も、適切なデータ分析言語と環境の要件を定めています。Google では、データを調査するためのツールを数多くご用意しています。前述のさまざまな手法には、さまざまなツールと言語がより適しています。アナリストにとって適切なツールの選択は、重要なスキルです。なじみのあるツールの機能に制限されるべきではありません。それは、特定のツールを適用するのではなく、真の分析情報を提供することです。
-
これは、「初期データ分析」と呼ばれることもあります。データ分析に関する Wikipedia の記事 ↩ をご覧ください
-
技術的には、探索的分析を行い、確認的分析は行わないでください。 ↩