Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hajime Sano
October 23, 2019

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

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

Hajime Sano

October 23, 2019
Tweet

More Decks by Hajime Sano

Other Decks in Technology

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.

    View Slide

  2. 2
    本日はご参加ありがとうございます。

    View Slide

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

    View Slide

  4. 4
    お話しするポイント
    1. UXにWebパフォーマンスは重要
    2. 広い視野でパフォーマンスを捉える
    3. IngestlyとRUMについて

    View Slide

  5. 5
    ページロード時間、計ってますか?

    View Slide

  6. なぜWebパフォーマンスが重要?
    6
    ● FTによる実験結果
    ● ページ表示速度を遅らせた場合の閲覧ペ
    ージ数の減少量をコントロールグループ
    と比較した
    ● 3秒以上遅くした場合、2ページ以上閲覧
    するユーザーが減少する
    ● 速いは正義
    https://medium.com/ft-product-
    technology/a-faster-ft-com-
    10e7c077dc1c

    View Slide

  7. パフォーマンス評価の手法
    7
    自分で測定 測定サービスを使う 全てのページビューで測定
    各ブラウザの「タイムライン」タブ
    Google ChromeのAudit(Lighthouse)
    古くはGomez、最近はSpeedCurve Real User Monitoring
    ○ 誰でも手元でできる
    ○ 一切コストはかからない
    × 自分の環境のことしか分からない
    × 手間がかかる
    ○ デバイスや地理条件の選択肢有り
    ○ 定期的に自動計測できる
    × ユーザー行動への影響は不明
    × 有償
    ○ ユーザー行動と関連付けできる
    ○ 多種多様な条件の実データ
    × アクセスが無いとデータが来ない
    × データ量が圧倒的に多い

    View Slide

  8. RUM: 実データを集めよう
    8
    ● データの多様性
    ○ 機種・ソフトウェアバージョンの違い
    ○ 地理条件・回線・通信経路
    ○ 同じキャリアの同じ機種でも通信量が上限の人もいるし、デバイスのリソース状況も異なる
    ● 行動との相関関係を評価できる
    ○ 閲覧ページ数やコンバージョンへの到達状況
    ○ スクロール深度、読了率、動画視聴時間
    ○ Time-Spent、Time-to-Action

    View Slide

  9. 9
    Fastly入れて速くなった… so what?

    View Slide

  10. 10
    インフラや環境 ユーザー行動
    ビジネス上の成果
    RUMとその先の効果測定
    コスト効率のような視点 従来のウェブアナリティクス

    View Slide

  11. 「速い」 と 「儲かる」 を繋ぐ
    11
    売上
    コンバージョン
    伝わる
    速い
    速いから閲覧ページ数が
    増え、訴求機会が増える
    訴求できるからコンバー
    ジョン数が増える
    コンバージョンが増える
    から売上も増える

    View Slide

  12. 「期待する成果」を明確に
    12
    売上
    客数
    客単価
    新規
    リピート
    直帰率
    アクション率
    Time to DOM
    Interactive
    キャッシュ
    ヒット率
    … …
    最上位・経営指標 事業部・部署の指標 施策ごとの指標
    事業のパフォーマンス ← WEBパフォーマンス

    View Slide

  13. 13
    何をどう計測する?

    View Slide

  14. Critical Rendering Path
    RUM / CRP計測についてはGoogle
    のWeb Fundamentals内で詳しく
    紹介されている
    14
    https://developers.google.com/web/fundamentals/performance/critical-rendering-
    path/measure-crp

    View Slide

  15. 15
    日経電子版の例
    https://hack.nikkei.com/blog/tech_book_fest04_performa
    nce_monitoring_rum/
    キャッシュ設定の変更による
    改善効果を、ABテストで評価
    した事例が公開されている

    View Slide

  16. 16
    様々な測定用API
    ● Navigation Timing
    ○ ブラウザ処理の大枠でタイムスタンプを得る
    ○ ページ(ナビゲーション)全体
    ● Resource Timing
    ○ ページ内の個々の要素レベルでブレークダウンしたタイミング情報
    ● User Timing
    ○ クライアント側で任意の処理を「マーク」して測定するもの
    ● Server Timing
    ○ サーバー側で任意の処理の時間を測定しhttpヘッダーに入れて返し、フロントで取得
    他にもある。ハイレゾやLevel2も…

    View Slide

  17. データを送る先が難しい
    17
    既存のアナリティクスツール 新たにツール導入
    Pros
    Cons
    ● 既に導入済みであることが多い
    ● マーケティングデータと統合できる
    ● 従量課金、コスト効率悪い
    ● データ構造の柔軟性が低い
    ● 計測に特化できる
    ● 二重投資
    ● 計測SDKの増加はパフォーマンスに
    影響するので本末転倒
    ● Single Source of Truth にならない

    View Slide

  18. 18
    そこで、Ingestly

    View Slide

  19. 既製のアナリティクスツールへの不満
    ● SDKがビミョー
    ○ データ送信にdocument.write は論外、appendChild多用でReflow発生
    ○ メインスレッドで同期処理、ブロッキング、グローバル汚染
    ○ ちょっと凝った計測するのに実装が面倒
    ● エンドポイントがビミョー
    ○ ロケーションが限定的、エッジで完結しない、レスポンスが遅い
    ○ 個々のツールが1つ以上のCookieをセット、容量圧迫し通信量も増える
    ● データの柔軟性が低い
    ○ 任意の変数を受け付けない、事前設定必須、制約がある、ネストした構造が扱えない
    ● 断片化とコスト増
    ○ ツール間で一意なデバイス特定ができない、データが繋がらない
    ○ 複数部署 x 複数ツール でコストもSDKも増大、CX/UXのためのツールがCX/UX阻害している
    19

    View Slide

  20. Ingestlyとは…
    ● 既製のアナリティクスツールに代わるもの
    ● FastlyとBigQuery and/or Elasticsearchを組み合わせる
    ● 低コストで高性能(無料で始められる)
    ● アプリケーションとしてはメンテナンスフリーを実現
    ● ニアリアルタイムな分析・データ利用が可能(1秒)
    ● レポートUI無し、BI等を活用する前提
    20

    View Slide

  21. Ingestlyとは…
    21
    Ingestly Endpoint
    Ingestly Client JS
    エンドポイント用
    カスタムVCL
    +
    ログストリーミング設定
    テーブルスキーマ
    &
    Mapping Template
    JS用計測SDK
    +
    add-ons (Survey, O2O)

    View Slide

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

    View Slide

  23. 基本的な仕組み
    23
    JS SDK Custom VCL Logging
    Schema
    Mapping
    ● sendBeaconでデータ送信
    ● Server-Side 1st Party Cookieをセット
    ● HTTP 204 / No Contentを即答
    ● ログをJSON化
    ● BQまたはESにフィード
    ● 適切な型で保存
    ● イベントから1秒程度で
    クエリー可能

    View Slide

  24. 24
    重要なところはFastlyがやってくれる
    (私が書いたのSDKくらい…)

    View Slide

  25. 詳細はQiitaをご参照ください
    25
    https://qiita.com/hsano/items/dcb4be5bd210b54390be

    View Slide

  26. SDKの特徴
    ● sendBeaconでデータ送信
    ○ データを送るためのモダンなAPI
    ○ 非同期・unload中もキャセルされない(iOS Safari除く)
    ○ FetchとXHRによるフォールバック有り
    ● iframeに入れられる
    ○ window[self|parent|top]を指定できるのでiframeの中から親フレームを計測できる
    ● 自動計測が充実
    ○ スクロール深度、読了、クリック、メディア再生、time-spent、RUMを自動計測
    ○ 組織横断での計測標準化が可能
    ● ネストしたデータに対応
    ○ 変数の値が階層構造の場合、JSON文字列として送信する
    ○ DBがBQであればJSON文字列、ESであれば展開して格納する
    26

    View Slide

  27. 対応するDB
    ● BigQuery
    ○ カラムナー
    ○ SQLで集計
    ○ Data Studioや各種BI・ダッシュボードツールに連携
    ○ 集計の柔軟性が高い
    ● Elasticsearch
    ○ ドキュメントストア
    ○ Luceneで集計
    ○ Elastic StackとしてKibanaを利用する・Re:dash等ES対応しているBIもあり
    ○ データ構造と(Kibana前提で)可視化の柔軟性が高い
    ● その他
    ○ 原理的にはFastlyのLoggingにリストされている宛先にデータを供給できる
    27

    View Slide

  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

    View Slide

  29. IngestlyでRUM:実装
    29
    DOM Loading から…
    - Time to Interactiveまでの時差
    - DOM Content Loadedまでの時差
    - 現在までの経過時間
    SDKの初期化時にRUMを有効化

    View Slide

  30. IngestlyでRUM:計測結果
    30
    RUM専用ビーコン
    ● onLoadで送信
    ● RUM用なのでデータが揃い次第
    即時計測
    その他のビーコンにもパフォーマンス情報が乗る
    ● 全てのビーコンに付帯
    ● スクロールや読了 x パフォーマンス情報
    ● Ingestly.trackAction() によるカスタムアクション
    計測でも経過時間を測定

    View Slide

  31. IngestlyでRUM:分析(Kibana)
    31
    RUM計測のビーコンをカウント
    時間軸の粒度は自動
    1秒未満、1〜2秒、2〜5秒… とレンジごとに集計

    View Slide

  32. 32
    導入、難しいんでしょ?

    View Slide

  33. 33
    導入はほぼコピー&ペースト
    1. Fastlyでドメイン設定
    2. カスタムVCLをコピー&ペースト
    3. BigQueryにテーブル作成
    4. BigQuery接続情報を指定
    5. ログフォーマットをコピー&ペースト
    6. SDKの設定を調整
    7. SDKをサイトに導入
    20分
    10分

    View Slide

  34. 34
    Custom VCL
    リポジトリからコピー&ペース

    2行目のドメインを変更

    View Slide

  35. 35
    Logging
    リポジトリからコピー&ペース

    View Slide

  36. 36
    JS SDK
    jsを2つをページに組み込む
    page_code.js でエンドポイントや
    自動計測の有効/無効を設定

    View Slide

  37. 37
    Qiita と GitHubのREADMEをご参照ください
    https://qiita.com/hsano/items/7764583899e8
    112782fc
    https://qiita.com/hsano/items/9e1684a211
    9cd87313f6

    View Slide

  38. 今後やっていくこと
    ● スクロール深度・読了の可視化をChrome拡張で実現
    ● BigQueryに入れたデータをCloud DataflowでEnrichment
    ● クエリースニペットと分析に関するドキュメント整備
    ● SDK側処理の一部をカスタムVCLに置き換え
    38

    View Slide

  39. 39
    Thank you !

    View Slide