Groupon: アナリティクスシステム改善の取組み

http://vimeo.com/96931912

2 comments | 1 point | by WazanovaNews 3年以上前 edited


Jshiike 3年以上前 edited | ▲upvoteする | link

GrouponのEngineering ManagerであるChris Powersが、同社のGeekfest Chicago Eventで、アナリティクスシステム改善の取り組みを紹介しています。

2年半前に改善の取り組みを開始

  • 事業の拡大に伴ってアナリティクスの需要は、CEOへの報告から、マーケ/開発の現場の利用、データサイエンティストの分析まで様々。しかし、各チームがバラバラに複数のアナリティクスシステムを運用していて、オーナーシップを取るチームはなし。
  • トラッキング用にページあたり20-30ピクセルを仕込んでいて、つまりユーザ当たり 20-30 GETリクエスト / ページとなり、サーバ負荷が過大。
  • 「全てをトラックする。」を目標に内製のアナリティクスシステムの整備にとりかかる。

システム構成

web/アプリとバックエンドの関係図(ビデオ 10:20〜

アナリティクスデータの収集ルート図(ビデオ 12:00〜

システム設計で考慮すべきポイント

  • 中央集中と分散アプローチの併用
    • 中央集中方式での処理は、主にCEOやマーケティング用データのように、分析内容がそれほど変化しないもの。
    • プロダクトマネジャなどが機能ごとのデータを欲しがるケースなどは分散型の処理になる。
  • 取得するメッセージサイズのバランス
    • サイズの小さいメッセージは、メッセージ単体に何を分析しているかわかる情報はないが、それらを関連づけることによって分析結果を得る。データウェアハウスへの効率的な保管や、オーバーヘッドを気にするモバイル分析にはよい。
    • リアルタイム分析では、10万-12万メッセージ/秒を処理している。このケースで複数のデータを都度joinするのはコストがかかる。メッセージあたりのペイロードを増やして、サーバの処理件数を減らせる。一方、データ保管の効率が落ちるなどトレードオフあり。
  • クライアントとサーバどちらでデータを解釈するか
    • 例えば、OS/ブラウザの種別/バージョンを取得するのに、ユーザエージェントをサーバに送って分析する手法と、クライアントで判別してサーバには結果データを送るだけという方法がとれる。
    • サーバの情報は信頼できるが、セキュリティの観点からクライアントからのデータは完全には信用できないという点もある。
    • オリジナルのデータをもっていれば、将来そのデータを違ったアプローチで遡って分析することができる。しかし、クライアント側でデータの解釈を終え、結果データだけを保存すると、後から別のアプローチでの分析ができなくなるケースがでてくる。
    • クライアントだと、デバイスにデータをオフロードして処理できるところはよい。一方、複数のバックエンドサーバがメッセージを受取って処理する方法だと、分析ロジックをうまく同期しないと正しい解釈ができない。
    • Grouponでは併用している。つまり、クライアントで解釈済のデータをバックエンドがリアルタイムで処理しつつ、オリジナルのローデータも後で遡って処理するためにとっておいている。

取得メッセージ

  • クライアント/サーバ イベントID
    • 全てのメッセージにユニークなIDを付与。信頼できるサーバ側で生成するとよいが、クライアント側にも持たせると、バリデーション/ベリフィケーションや、クライアントから発信されたデータがどうなるか計測する場合などに便利。
  • クライアント/サーバ タイムスタンプ
    • これも両方でもつ。ユーザセッションにおいて、クライアントでのタイムスタンプがそのユーザにとって、デバイスでのリアルの時間を示す。一方、サーバ時間は信頼できる点があるが、クライアント側で3秒メッセージを溜めてからサーバにバッチで送ることをよくやっているので、正確な時間ではない。
  • クライアントメッセージインデックス
    • そのセッション内にクライアントが何件メッセージを送ったかカウントしている。メッセージがどこかで欠落したかどうか調べる際に便利。
  • スキーマID
    • スキーマは変えない方がよいが、過去に変更したこともある。どのスキーマを使っているか、バージョン情報などによりどのスキーマかわかれば、バックエンドがそれにあわせた適切な解釈をしてくれる。
  • アプリID
    • これがあるとデバッグしやすい。
  • メッセージのエンコーディング
    • 素直にJSONを選択しているが、実はリアルタイム分析で一番時間がかかっているのは、JSONのデコード処理。バックエンドの効率化には何が最適か、他の選択肢も検討中。

ユーザ/デバイスデータ

  • ユーザ識別子
    • ログイン必須アプリならユーザIDがあるので簡単。Grouponの場合はユーザはログインしてたりしてなかったり、メール購読ユーザであったりなかったりなので、ユーザIDと必ずしも紐づくわけでない識別子を発行している。
  • ユーザエージェンド
    • 解析済のもの、もしくはローデータ
  • メタデータ
    • ユーザの訪問回数、ユーザ種別など持っておくと便利な情報。
  • ログイン/ログアウト
    • ログアウト後にトラッキング用のクッキーを残すか?例えば、同じ端末をその後家族が利用してしまうケースもありうる。

セッションデータ

  • セッションID
    • 必須。タイムスタンプ + ユーザIDの組み合わせで簡単につくれる。
  • 有効期限ロジック
    • ページごとに30分と決めている。ユーザがページを移動したら、次の30分をカウント開始。
  • クッキーをセットする対象はワイルドカードに
    • 現在はサブドメインを使ってないくても、将来は使うかもしれないし、その際にクッキーが大変になるので、ワイルドカードの範囲で対応できるようにする。
  • セッションIDをキーとして利用
    • セッションIDをキーとしてローカルストレージを利用している。ユーザはセッションの終了を明示してはくれない。ブラウザを閉じるだけ。次にアクセスした際に、ローカルストレージを確認し、セッションIDをキーに名前空間の違いを認識できる。
  • リファラ情報
    • セッション内で共有する。

ページビュー

  • ページビューの定義
    • AJAX、モバイルアプリのときの定義をどうするか?
  • ページID
    • セッションID + タイムスタンプで作成。
  • ページタイプ
    • ユーザがページ全体を再読込みしてページIDが変わっても、同じページにいる場合もあるので、どのような種類のページにいるかの情報は必要。
  • URL
    • 解析済のもの、もしくはローデータ。取得するメッセージがどこから来ているかの分析に必要。
  • 国/Locale
    • 今は一カ国でも、将来に備えて情報をいれておけばよい。セッション内で変更するかどうかは、この情報がページレベルのものかセッションレベルのものかで判断する。例えば、Grouponカナダのページには、英語/フランス語切替のボタンがあり、この場合はセッションでなく、localeだけが変わるとしている。
  • アプリごとに管理すべきメタデータ
    • どのようなページか、どうようなステートかなど。分析処理に有益な情報を追加。
  • リファラページID/クリックID
    • セッションごとだけでなく、セッション内でのページ遷移の情報も管理。
  • アプリごとの固有のロジック
    • どうやってそのページに来たのか。
  • トラッキングソフトのバージョン
    • Grouponのシステムは30個のアプリで構成されているが、同じタイミングでデプロイされるとは限らない。ユーザが遷移するページごとにソフトのバージョンが変わってくるケースがありうる。
  • バックボタン/再読込み/ブラウザキャッシュの挙動の確認
    • バックボタンはブラウザごとにどのようなキャッシュ設定をしているかで変わってくる。再読込みして最新のページを取得するともあるし、キャッシュから従前のページを表示することもある。

ライブラリ

  • TrackingHub
    • どのデータをどう分析するかあらかじめわかっているケースに利用。
    • ユーザ、セッション、ページレベルのデータを取りまとめる。
  • Bloodhound
    • データサイエンティスト用。データを集めてみて、何が読み取れるか考える。
    • ユーザがクリックしたらメッセージを送信
    • デモ 42:10〜
    • 画面を色分けして、ユーザの閲覧/クリックを可視化。ユーザのアクションごとにメッセージが送付される。
    • ビジュアル化のメリットは、ビジネスサイドの人が理解しやすくなるだけでなく、エンジニアの関心も高くなる。大会社で組織横断でのイニシアチブが必要な場合、可視化により社内の認知が高まるので、強力にサポートしてくれるツールとなる。

クライアント側からのメッセージ送付

  • バッチの利用
    • クライアント側で3秒ごとにまとめてバッチでメッセージを送信しているが、その間にユーザがページを遷移する場合がある。ローカルストレージに情報を保管しておき、従前のページの情報として、移動後の情報と合わせて送る仕組みにしている。
  • 適切なリトライロジック
    • 頻度/期限は、どれだけその情報が重要かで決める。それほど重要でなければ、すぐに諦めるという判断もあり。
  • オリジンの変更
    • http/https間の移動やサブドメインから別のサブドメインへの移動でオリジンが変わってしまうと、ローカルストレージがオリジンに紐づいていて、データが取り出せない。解決策を模索中。当座の対応としては、クレイジーに聞こえるかもしれないが、新しいオリジンに移動する直前に、情報を詰め込んで同期 (?) AJAXコールで処理していて、今のところうまくいってる。

クライアントのデータに整合性をもたせる

  • メッセージにバージョン情報をもたせる。いつデータが取り出されるか、利用されるかはわからないので。
  • データを最新のバージョンにマイグレーションできる仕組みを用意しておく。
  • ローカルストレージでのキーへのアクセスを制限し、たくさんのコードがアクセスして悪影響を与えるのを避ける。
  • クッキー、ローカルストレージ、CouchDBなどもろもろ使っているので、ストレージエンジンの抽象化
  • ストレージの利用状況を監視し、限界が近ければアラートメッセージを発行
  • ローカルストレージから突然古いデータが送られてくるケースはある。24時間よりも古いデータを受取ったら、単純に削除している。

データのベリフィケーション

  • 正確さの担保は相当難しい
  • 状況が悪化していく中、基準がないと判断が難しい。あらかじめ、データが98%あればよいのか95%あればよいのか閾値を決めておき、それ以上の欠損がでたらどうするか準備しておく。
  • データはなくなるもの。どう計測するかが重要。
  • メッセージが送られるパイプの中で、バリデーションができる箇所(nginxのログデータとかHadoopクラスタにチェックポイントを仕込むとか。)を用意しておく。
  • 追跡ピクセルを1件は仕込んでおき、比較検証できるデータを取得する。JavaScriptで追加するようにすると、多くのbotはexecuteしない。Goolgeのbotはexecuteするけど。
  • 欠落したメッセージを見つけるためにインデックスを利用する。

テスト

  • 中央集中型処理の単体 & 結合テストの実施。
  • クローラーをトリガーにメッセージを送信し、それがデータストアに存在することで、確認をする。
  • ユーザキー/メッセージキー/ページキーなどの必須情報が欠落したら、すぐにアラートをだすようにしておく。
  • 大組織なら多くの人がデータを分析/利用していて、何かまずいことがあれば各人が気づくケースがよくある。システム全体のプロセスがどうなっているのかしっかり把握して対処できる準備をしておかないと、組織内に不満はすぐに広がってしまう。

セキュリティ

  • クライアントからの情報は完全には信用しない。
  • BotはJavaScriptを実行し、変なことする。日付データを上書きしたり。ユーザの通常パターンの範囲を把握しておくと、botの判別に役立つ。
  • セッション/ユーザ/IPごとにデータを破棄できるようにしておくこと。
  • エンドポイント単位でIPをブロックできるようにしておく。

#groupon #analytics

Jshiike 3年以上前 edited | ▲upvoteする | link

Search Engine Landで紹介されている、GrouponのGene McKennaの実験結果も興味深いです。直トラフィックの60%が実はオーガニックサーチ経由だったという話。

検証方法

  • 6時間Googleのインデックスから外して、ルート別のトラフィックの変化を確認。
  • トップページなどの主要ページはそもそも直のトラフィックが多いので、差分を検証しやすいように、長めのURL(例えば、www.groupon.com/local/san-francisco/restaurants)をブラウザごとに時間単位で分析。
  • 同じURLの前週の同じ曜日の同じ時間帯に取得したデータと比較。
  • Grouponの長めのURLをユーザが直打ちする可能性は低いし、短期間で無効になる仕組みなのでブックマーク経由の可能性もほぼない。

結果

  • このグラフによると
    • オーガニックサーチ経由がほぼゼロになるのは自然だが、直トラフィックも60%下落している。
    • デスクトップFirefox/Chrome/Safariで直トラフィックされているものの10%-20%はオーガニックサーチ。
    • IEにおける直トラフィックの75%はオーガニックサーチ
  • モバイルだけに絞れば50%の下落
  • ちなみに、主要ページであるディールページだと直トラフィックの下落はほとんどない。トラックできなくて直トラフィックに分類される、ソーシャルネットワーク/個人メール経由などが多いと推測される。

#groupon #sec

Back