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

D7f27502ce4dfef29afae545df767b27?s=47 Hajime Sano
October 23, 2019

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

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

D7f27502ce4dfef29afae545df767b27?s=128

Hajime Sano

October 23, 2019
Tweet

Transcript

  1. 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. 3.

    3 自己紹介 • Digital Analytics & Data Marketing advocate •

    Ingestlyプロジェクトを仕切ってます • リアルタイムなマーケティングデータ分析とデータ活用を 組織的に取り組む文化を広めたい • エンジニアリングとビジネスのバランス • アナリティクス原理主義 ◦ SiteTracker ◦ Omniture SiteCatalyst / Adobe Analytics ◦ Atlas ◦ Ingestly / Polytrek Hajime Sano @hjmsano
  3. 7.

    パフォーマンス評価の手法 7 自分で測定 測定サービスを使う 全てのページビューで測定 各ブラウザの「タイムライン」タブ Google ChromeのAudit(Lighthouse) 古くはGomez、最近はSpeedCurve Real

    User Monitoring ◦ 誰でも手元でできる ◦ 一切コストはかからない × 自分の環境のことしか分からない × 手間がかかる ◦ デバイスや地理条件の選択肢有り ◦ 定期的に自動計測できる × ユーザー行動への影響は不明 × 有償 ◦ ユーザー行動と関連付けできる ◦ 多種多様な条件の実データ × アクセスが無いとデータが来ない × データ量が圧倒的に多い
  4. 8.

    RUM: 実データを集めよう 8 • データの多様性 ◦ 機種・ソフトウェアバージョンの違い ◦ 地理条件・回線・通信経路 ◦

    同じキャリアの同じ機種でも通信量が上限の人もいるし、デバイスのリソース状況も異なる • 行動との相関関係を評価できる ◦ 閲覧ページ数やコンバージョンへの到達状況 ◦ スクロール深度、読了率、動画視聴時間 ◦ Time-Spent、Time-to-Action
  5. 11.

    「速い」 と 「儲かる」 を繋ぐ 11 売上 コンバージョン 伝わる 速い 速いから閲覧ページ数が

    増え、訴求機会が増える 訴求できるからコンバー ジョン数が増える コンバージョンが増える から売上も増える
  6. 12.

    「期待する成果」を明確に 12 売上 客数 客単価 新規 リピート 直帰率 アクション率 Time

    to DOM Interactive キャッシュ ヒット率 … … 最上位・経営指標 事業部・部署の指標 施策ごとの指標 事業のパフォーマンス ← WEBパフォーマンス
  7. 14.

    Critical Rendering Path RUM / CRP計測についてはGoogle のWeb Fundamentals内で詳しく 紹介されている 14

    https://developers.google.com/web/fundamentals/performance/critical-rendering- path/measure-crp
  8. 16.

    16 様々な測定用API • Navigation Timing ◦ ブラウザ処理の大枠でタイムスタンプを得る ◦ ページ(ナビゲーション)全体 •

    Resource Timing ◦ ページ内の個々の要素レベルでブレークダウンしたタイミング情報 • User Timing ◦ クライアント側で任意の処理を「マーク」して測定するもの • Server Timing ◦ サーバー側で任意の処理の時間を測定しhttpヘッダーに入れて返し、フロントで取得 他にもある。ハイレゾやLevel2も…
  9. 17.

    データを送る先が難しい 17 既存のアナリティクスツール 新たにツール導入 Pros Cons • 既に導入済みであることが多い • マーケティングデータと統合できる

    • 従量課金、コスト効率悪い • データ構造の柔軟性が低い • 計測に特化できる • 二重投資 • 計測SDKの増加はパフォーマンスに 影響するので本末転倒 • Single Source of Truth にならない
  10. 19.

    既製のアナリティクスツールへの不満 • SDKがビミョー ◦ データ送信にdocument.write は論外、appendChild多用でReflow発生 ◦ メインスレッドで同期処理、ブロッキング、グローバル汚染 ◦ ちょっと凝った計測するのに実装が面倒

    • エンドポイントがビミョー ◦ ロケーションが限定的、エッジで完結しない、レスポンスが遅い ◦ 個々のツールが1つ以上のCookieをセット、容量圧迫し通信量も増える • データの柔軟性が低い ◦ 任意の変数を受け付けない、事前設定必須、制約がある、ネストした構造が扱えない • 断片化とコスト増 ◦ ツール間で一意なデバイス特定ができない、データが繋がらない ◦ 複数部署 x 複数ツール でコストもSDKも増大、CX/UXのためのツールがCX/UX阻害している 19
  11. 20.

    Ingestlyとは… • 既製のアナリティクスツールに代わるもの • FastlyとBigQuery and/or Elasticsearchを組み合わせる • 低コストで高性能(無料で始められる) •

    アプリケーションとしてはメンテナンスフリーを実現 • ニアリアルタイムな分析・データ利用が可能(1秒) • レポートUI無し、BI等を活用する前提 20
  12. 21.

    Ingestlyとは… 21 Ingestly Endpoint Ingestly Client JS エンドポイント用 カスタムVCL +

    ログストリーミング設定 テーブルスキーマ & Mapping Template JS用計測SDK + add-ons (Survey, O2O)
  13. 22.

    不満を一挙解決 • SDKがイケてる ◦ sendBeacon / Fetch で通信 ◦ iframeでも動くのでメインスレッドの外に出せる

    ◦ RUMも含め様々な自動計測を内包して16KB • エンドポイントがシンプル ◦ Fastlyのエッジで処理、バックエンドを必要としない ◦ Cookie 2つ、ドメインやフラグ等のコントロールが可能 • データの柔軟性が高い ◦ DBに次第で使い勝手は変わるがスキーマレス、ネストに対応、変数増減は自由 • ツールを集約でき、しかも低コスト ◦ 様々な計測を単体でこなせるので、ツールを組み合わせる必要性があまりない ◦ BigQueryを使う場合で100万件の計測あたり$1程度、1億件で$106(1000万PV≒1億件) 22
  14. 23.

    基本的な仕組み 23 JS SDK Custom VCL Logging Schema Mapping •

    sendBeaconでデータ送信 • Server-Side 1st Party Cookieをセット • HTTP 204 / No Contentを即答 • ログをJSON化 • BQまたはESにフィード • 適切な型で保存 • イベントから1秒程度で クエリー可能
  15. 26.

    SDKの特徴 • sendBeaconでデータ送信 ◦ データを送るためのモダンなAPI ◦ 非同期・unload中もキャセルされない(iOS Safari除く) ◦ FetchとXHRによるフォールバック有り

    • iframeに入れられる ◦ window[self|parent|top]を指定できるのでiframeの中から親フレームを計測できる • 自動計測が充実 ◦ スクロール深度、読了、クリック、メディア再生、time-spent、RUMを自動計測 ◦ 組織横断での計測標準化が可能 • ネストしたデータに対応 ◦ 変数の値が階層構造の場合、JSON文字列として送信する ◦ DBがBQであればJSON文字列、ESであれば展開して格納する 26
  16. 27.

    対応するDB • BigQuery ◦ カラムナー ◦ SQLで集計 ◦ Data Studioや各種BI・ダッシュボードツールに連携

    ◦ 集計の柔軟性が高い • Elasticsearch ◦ ドキュメントストア ◦ Luceneで集計 ◦ Elastic StackとしてKibanaを利用する・Re:dash等ES対応しているBIもあり ◦ データ構造と(Kibana前提で)可視化の柔軟性が高い • その他 ◦ 原理的にはFastlyのLoggingにリストされている宛先にデータを供給できる 27
  17. 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
  18. 29.

    IngestlyでRUM:実装 29 DOM Loading から… - Time to Interactiveまでの時差 -

    DOM Content Loadedまでの時差 - 現在までの経過時間 SDKの初期化時にRUMを有効化
  19. 30.

    IngestlyでRUM:計測結果 30 RUM専用ビーコン • onLoadで送信 • RUM用なのでデータが揃い次第 即時計測 その他のビーコンにもパフォーマンス情報が乗る •

    全てのビーコンに付帯 • スクロールや読了 x パフォーマンス情報 • Ingestly.trackAction() によるカスタムアクション 計測でも経過時間を測定
  20. 33.