利用状況の指標と収集目的

店舗の詳細を読むことと実際に訪れることは、同じ行動ではない。例えば旅行先の候補を比較する人は、開いた文書のすべての店舗へ行くわけではない。詳細閲覧は関心、経路検索は移動の意図、訪問認証は現地で行った操作を示す。

flowchart TD
    accTitle: 目的別の指標と訪問ドメインの分離
    accDescr: 閲覧と経路案内のイベントは個人を識別せず集計し、訪問認証は別のドメイン記録から集計する。
    E[閲覧と経路案内] --> A[目的別の分析イベント]
    A --> S[サーバーでの集計]
    V[訪問認証の記録] --> T[訪問指標の集計]
    S --> R[権限に応じた結果]
    T --> R

サービス改善にはこの違いを知る指標が必要だが、一人ずつの移動履歴まで集める必要はないと考えた。目的別の分析イベントにはIP、ユーザーエージェント、利用者IDを保存せず、結果を公開の基本指標と運営用の詳細指標に分ける。

分析イベントと訪問統計

詳細閲覧と経路検索は、定めた種類の追記型イベントとして保存しサーバーで集計する。APIで種類と対象店舗を制限し、内部コレクションを直接公開しないことで、ブラウザーが任意の分析項目を作ることを防ぐ。

sequenceDiagram
    accTitle: 詳細の閲覧と指標の記録
    accDescr: 詳細APIは公開ゲームセンターのデータを読み、閲覧イベントの記録を試みてから詳細を返す。
    participant W as 利用者のリクエスト
    participant A as 詳細API
    participant D as ストレージ
    W->>A: ゲームセンター詳細を読む
    A->>D: 公開ゲームセンターを取得
    D-->>A: 詳細データ
    A->>D: 閲覧イベントの記録を試行
    A-->>W: 詳細の結果

訪問回数と異なる訪問者数には、訪問認証の既存データを許可された条件で使う。匿名の閲覧イベントに利用者IDを追加して計算するわけではない。訪問機能にアカウントが必要でも、目的の異なる閲覧イベントまで個人を識別する必要はないためである。

公開統計と運営者向け指標

基本指標は公開し、経路検索、訪問認証、異なる訪問者数などの詳細は担当店舗アカウントと許可された運営者へ提供する。画面で隠すだけでなく、取得APIで現在のアカウントがその店舗を管理できるか確認する。

flowchart TD
    accTitle: 指標のレスポンスのアクセス境界
    accDescr: 現在公開できる場所か確認し、基本指標と権限が必要な運営指標を区別して返す。
    Q[指標の取得] --> P[場所の公開ポリシーを確認]
    P --> B[公開する基本指標]
    P --> O[対象の運営権限を確認]
    O --> D[保護された詳細指標]

集計対象にも店舗の公開条件を適用する。詳細から閲覧できない場所が統計経由で分かることを防ぐためである。訪問とランキングは保存先を分けても、公開できる対象の条件は共通して守る。

指標の解釈と集計の失敗

目的別に集計することで、個人の追跡履歴を作らず利用状況を把握できる。分析の保存に失敗しても正しい詳細レスポンスは返す。指標の収集が、利用者の読みたい文書を妨げないようにするためである。

閲覧数は利用者の実人数ではなく、繰り返しの要求や保存失敗の影響を受ける。訪問認証数も、その機能の検証条件を踏まえて解釈する必要がある。各数値がどの行動と範囲から生まれたものかを合わせて提供する。

関連する記事と資料：エンジニアリングの記録