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