Measuring the performance. Let’s own your analytics tool.

Fastlyを活用したリアルタイムアナリティクスツール「Ingestly」と、RUMを中心にWebパフォーマンス計測についてFastly YAMAGOYA Meetupでお話しした際の発表資料です。

Transcript

1. Measuring the performance. Let’s own your analytics tool. Hajime Sano, Project Lead at Ingestly A maintanance free open-source real-time web analytics tool.
2. 2 本日はご参加ありがとうございます。
3. 3 自己紹介 • Digital Analytics & Data Marketing advocate • Ingestlyプロジェクトを仕切ってます • リアルタイムなマーケティングデータ分析とデータ活用を 組織的に取り組む文化を広めたい • エンジニアリングとビジネスのバランス • アナリティクス原理主義 ◦ SiteTracker ◦ Omniture SiteCatalyst / Adobe Analytics ◦ Atlas ◦ Ingestly / Polytrek Hajime Sano @hjmsano
4. 4 お話しするポイント 1. UXにWebパフォーマンスは重要 2. 広い視野でパフォーマンスを捉える 3. IngestlyとRUMについて
5. 5 ページロード時間、計ってますか？
6. なぜWebパフォーマンスが重要？ 6 • FTによる実験結果 • ページ表示速度を遅らせた場合の閲覧ペ ージ数の減少量をコントロールグループ と比較した • 3秒以上遅くした場合、2ページ以上閲覧 するユーザーが減少する • 速いは正義 https://medium.com/ft-product- technology/a-faster-ft-com- 10e7c077dc1c
7. パフォーマンス評価の手法 7 自分で測定 測定サービスを使う 全てのページビューで測定 各ブラウザの「タイムライン」タブ Google ChromeのAudit(Lighthouse) 古くはGomez、最近はSpeedCurve Real User Monitoring ◦ 誰でも手元でできる ◦ 一切コストはかからない × 自分の環境のことしか分からない × 手間がかかる ◦ デバイスや地理条件の選択肢有り ◦ 定期的に自動計測できる × ユーザー行動への影響は不明 × 有償 ◦ ユーザー行動と関連付けできる ◦ 多種多様な条件の実データ × アクセスが無いとデータが来ない × データ量が圧倒的に多い
8. RUM: 実データを集めよう 8 • データの多様性 ◦ 機種・ソフトウェアバージョンの違い ◦ 地理条件・回線・通信経路 ◦ 同じキャリアの同じ機種でも通信量が上限の人もいるし、デバイスのリソース状況も異なる • 行動との相関関係を評価できる ◦ 閲覧ページ数やコンバージョンへの到達状況 ◦ スクロール深度、読了率、動画視聴時間 ◦ Time-Spent、Time-to-Action
9. 9 Fastly入れて速くなった… so what?
10. 10 インフラや環境 ユーザー行動 ビジネス上の成果 RUMとその先の効果測定 コスト効率のような視点 従来のウェブアナリティクス
11. 「速い」 と 「儲かる」 を繋ぐ 11 売上 コンバージョン 伝わる 速い 速いから閲覧ページ数が 増え、訴求機会が増える 訴求できるからコンバー ジョン数が増える コンバージョンが増える から売上も増える
12. 「期待する成果」を明確に 12 売上 客数 客単価 新規 リピート 直帰率 アクション率 Time to DOM Interactive キャッシュ ヒット率 … … 最上位・経営指標 事業部・部署の指標 施策ごとの指標 事業のパフォーマンス ← WEBパフォーマンス
13. 13 何をどう計測する？
14. Critical Rendering Path RUM / CRP計測についてはGoogle のWeb Fundamentals内で詳しく 紹介されている 14 https://developers.google.com/web/fundamentals/performance/critical-rendering- path/measure-crp
15. 15 日経電子版の例 https://hack.nikkei.com/blog/tech_book_fest04_performa nce_monitoring_rum/ キャッシュ設定の変更による 改善効果を、ABテストで評価 した事例が公開されている
16. 16 様々な測定用API • Navigation Timing ◦ ブラウザ処理の大枠でタイムスタンプを得る ◦ ページ（ナビゲーション）全体 • Resource Timing ◦ ページ内の個々の要素レベルでブレークダウンしたタイミング情報 • User Timing ◦ クライアント側で任意の処理を「マーク」して測定するもの • Server Timing ◦ サーバー側で任意の処理の時間を測定しhttpヘッダーに入れて返し、フロントで取得 他にもある。ハイレゾやLevel2も…
17. データを送る先が難しい 17 既存のアナリティクスツール 新たにツール導入 Pros Cons • 既に導入済みであることが多い • マーケティングデータと統合できる • 従量課金、コスト効率悪い • データ構造の柔軟性が低い • 計測に特化できる • 二重投資 • 計測SDKの増加はパフォーマンスに 影響するので本末転倒 • Single Source of Truth にならない
18. 18 そこで、Ingestly
19. 既製のアナリティクスツールへの不満 • SDKがビミョー ◦ データ送信にdocument.write は論外、appendChild多用でReflow発生 ◦ メインスレッドで同期処理、ブロッキング、グローバル汚染 ◦ ちょっと凝った計測するのに実装が面倒 • エンドポイントがビミョー ◦ ロケーションが限定的、エッジで完結しない、レスポンスが遅い ◦ 個々のツールが1つ以上のCookieをセット、容量圧迫し通信量も増える • データの柔軟性が低い ◦ 任意の変数を受け付けない、事前設定必須、制約がある、ネストした構造が扱えない • 断片化とコスト増 ◦ ツール間で一意なデバイス特定ができない、データが繋がらない ◦ 複数部署 x 複数ツール でコストもSDKも増大、CX/UXのためのツールがCX/UX阻害している 19
20. Ingestlyとは… • 既製のアナリティクスツールに代わるもの • FastlyとBigQuery and/or Elasticsearchを組み合わせる • 低コストで高性能（無料で始められる） • アプリケーションとしてはメンテナンスフリーを実現 • ニアリアルタイムな分析・データ利用が可能（1秒） • レポートUI無し、BI等を活用する前提 20
21. Ingestlyとは… 21 Ingestly Endpoint Ingestly Client JS エンドポイント用 カスタムVCL + ログストリーミング設定 テーブルスキーマ & Mapping Template JS用計測SDK + add-ons (Survey, O2O)
22. 不満を一挙解決 • SDKがイケてる ◦ sendBeacon / Fetch で通信 ◦ iframeでも動くのでメインスレッドの外に出せる ◦ RUMも含め様々な自動計測を内包して16KB • エンドポイントがシンプル ◦ Fastlyのエッジで処理、バックエンドを必要としない ◦ Cookie 2つ、ドメインやフラグ等のコントロールが可能 • データの柔軟性が高い ◦ DBに次第で使い勝手は変わるがスキーマレス、ネストに対応、変数増減は自由 • ツールを集約でき、しかも低コスト ◦ 様々な計測を単体でこなせるので、ツールを組み合わせる必要性があまりない ◦ BigQueryを使う場合で100万件の計測あたり$1程度、1億件で$106（1000万PV≒1億件） 22
23. 基本的な仕組み 23 JS SDK Custom VCL Logging Schema Mapping • sendBeaconでデータ送信 • Server-Side 1st Party Cookieをセット • HTTP 204 / No Contentを即答 • ログをJSON化 • BQまたはESにフィード • 適切な型で保存 • イベントから1秒程度で クエリー可能
24. 24 重要なところはFastlyがやってくれる （私が書いたのSDKくらい…）
25. 詳細はQiitaをご参照ください 25 https://qiita.com/hsano/items/dcb4be5bd210b54390be
26. SDKの特徴 • sendBeaconでデータ送信 ◦ データを送るためのモダンなAPI ◦ 非同期・unload中もキャセルされない（iOS Safari除く） ◦ FetchとXHRによるフォールバック有り • iframeに入れられる ◦ window[self|parent|top]を指定できるのでiframeの中から親フレームを計測できる • 自動計測が充実 ◦ スクロール深度、読了、クリック、メディア再生、time-spent、RUMを自動計測 ◦ 組織横断での計測標準化が可能 • ネストしたデータに対応 ◦ 変数の値が階層構造の場合、JSON文字列として送信する ◦ DBがBQであればJSON文字列、ESであれば展開して格納する 26
27. 対応するDB • BigQuery ◦ カラムナー ◦ SQLで集計 ◦ Data Studioや各種BI・ダッシュボードツールに連携 ◦ 集計の柔軟性が高い • Elasticsearch ◦ ドキュメントストア ◦ Luceneで集計 ◦ Elastic StackとしてKibanaを利用する・Re:dash等ES対応しているBIもあり ◦ データ構造と（Kibana前提で）可視化の柔軟性が高い • その他 ◦ 原理的にはFastlyのLoggingにリストされている宛先にデータを供給できる 27
28. ITP2.3でも大丈夫 • 追跡期間が24時間または7日では短すぎる ◦ Safariのプライバシー機能「Intelligent Tracking Prevention」 ◦ 一定の条件下で1st Party Cookieの有効期限が24時間にまで短くなる ◦ ユーザー行動の分析においては短すぎる • Server-Side 1st Party Cookieとして2年間有効 ◦ ITPはサードパーティツールによる追跡をブロックするもの ◦ サイトと同じFastlyでエンドポイントを構成し、1st Partyとなる ◦ FastlyをAレコードで自ドメインとすることで、DNS LookupをCNAMEより速くできる • LocalStorageによる一時保存 ◦ レスポンス処理の頻度を減らすため、期限が短いLocalStorageに値を保持する 28
29. IngestlyでRUM：実装 29 DOM Loading から… - Time to Interactiveまでの時差 - DOM Content Loadedまでの時差 - 現在までの経過時間 SDKの初期化時にRUMを有効化
30. IngestlyでRUM：計測結果 30 RUM専用ビーコン • onLoadで送信 • RUM用なのでデータが揃い次第 即時計測 その他のビーコンにもパフォーマンス情報が乗る • 全てのビーコンに付帯 • スクロールや読了 x パフォーマンス情報 • Ingestly.trackAction() によるカスタムアクション 計測でも経過時間を測定
31. IngestlyでRUM：分析（Kibana） 31 RUM計測のビーコンをカウント 時間軸の粒度は自動 1秒未満、1〜2秒、2〜5秒… とレンジごとに集計
32. 32 導入、難しいんでしょ？
33. 33 導入はほぼコピー＆ペースト 1. Fastlyでドメイン設定 2. カスタムVCLをコピー＆ペースト 3. BigQueryにテーブル作成 4. BigQuery接続情報を指定 5. ログフォーマットをコピー＆ペースト 6. SDKの設定を調整 7. SDKをサイトに導入 20分 10分
34. 34 Custom VCL リポジトリからコピー＆ペース ト 2行目のドメインを変更
35. 35 Logging リポジトリからコピー＆ペース ト
36. 36 JS SDK jsを2つをページに組み込む page_code.js でエンドポイントや 自動計測の有効/無効を設定
37. 37 Qiita と GitHubのREADMEをご参照ください https://qiita.com/hsano/items/7764583899e8 112782fc https://qiita.com/hsano/items/9e1684a211 9cd87313f6
38. 今後やっていくこと • スクロール深度・読了の可視化をChrome拡張で実現 • BigQueryに入れたデータをCloud DataflowでEnrichment • クエリースニペットと分析に関するドキュメント整備 • SDK側処理の一部をカスタムVCLに置き換え 38
39. 39 Thank you !