フィード型コンテンツのトラッキング

ニュースアプリなどでよく見られる無限スクロールやフィード型のUIでは、ユーザーのスクロールに合わせてコンテンツが動的に読み込まれる。このような画面では、データの「送信内容」と「送信タイミング」を慎重に設計する必要がある。

計上すべきデータ項目

• fetch_count：読み込み回数（0は初期表示、1以上は追加読み込み）
• batch_id：読み込み単位の一意識別子（プルダウンまたは無限スクロールの各バッチ）
• load_type：読み込みトリガー（auto: 自動読み込み、manual: ユーザー操作による読み込み）
• local_position：同じ読み込みバッチ内におけるコンテンツの位置
• global_position：フィード全体におけるコンテンツの絶対位置
• session_token：ユーザーの連続閲覧セッションID（画面初期表示時に生成し、トップリフレッシュ時に更新）

送信タイミング

露出データは一旦ローカルキャッシュに格納し、キャッシュ数が一定量に達した時点か、その他の送信トリガー発生時にまとめて送信する。送信完了後はキャッシュをクリアし、新たな露出を待機状態にする。ユーザーが上下にスクロールして同じアイテムが再び画面に現れた場合、重複を排除せずそのままキャッシュに追加する。

リスト形式の露出計測

リストの露出イベントは、トラッキング設計において最も難易度が高い。特に送信タイミングとフォーマットの設計が重要となる。

送信タイミングの設計

基本原則として「ユーザーが視認可能になった瞬間」を捉える（画面外に外れてから再度視認された場合は2回目の露出として扱う）。

• 一括送信方式：画面離脱時にそれまでに露出した全アイテムを送信する。シンプルだが、無限スクロールなどで蓄積データ量が多すぎる場合、ペイロード制限によるデータ欠損が発生しうる。
• ハイブリッド方式：一括送信方式にキャッシュ上限の条件を加えたもの。キャッシュ内のアイテム数が閾値に達した時点で送信しキャッシュをクリアする。画面離脱時にも残りのキャッシュを送信する。

実務では以下の具体なシナリオを考慮してタイミングを調整する必要がある。

• 上下スクロールによる重複露出のキャッシュ追加可否
• 高速スクロール時の取り扱い
• タブ切り替え、ハードキー/ソフトキーによるバック、画面のオフ/オン、折りたたみの展開/收纳
• モーダルやポップアップによる一時的な隠蔽
• 下位画面への遷移

送信フォーマットの設計

リストの露出は複数アイテムをまとめて送信するのが一般的で、共通属性と個別属性に分けて設計する。

# 共通属性
view_id: main_feed
source_ref: home_icon

# 個別属性: アイテム間は '|' で分割、同一アイテム内の属性は ',' で分割
items_list: "pos=1,type=travel,ref=C100|pos=2,type=tech,ref=C101"

個別属性の具体的なシリアライズ手法としては、以下の2つがよく用いられる。

• JSONネスト方式

{
  "view_id": "discovery",
  "exposed_items": [
    {"genre": "music", "author_ref": "A1", "pos": 1, "content_ref": "C1"},
    {"genre": "news", "author_ref": "A2", "pos": 2, "content_ref": "C2"}
  ]
}

• 区切り文字方式

# 共通属性
view_id: discovery

# 個別属性
items_list: "pos=1,content_ref=C1,genre=music,author_ref=A1|pos=2,content_ref=C2,genre=news,author_ref=A2"

留意点

• 重複露出を許容するかどうか（Setによる一意化か、Listによる重複許容か）。
• 権限要求ダイアログの裏側での露出は、ダイアログが閉じられた後に送信を実行する。

クリックイベントの高度な設計

遅延送信（バッチ操作）

通常、クリックイベントは操作の直後に送信されるが、単一画面での複数選択操作などではあえて送信を遅延させるとデータ処理が容易になる。

• 複数選択後に一括で「削除」「フォロー」等を実行するケース
• 個別に状態が変化し、画面遷移を伴わないケース

これらの場合、画面離脱時に最終的な状態、あるいは変化の差分（追加・削除・保留）をまとめて送信することで、イベントの粒度を整理できる。

メタデータの付与

クリック対象によって付帯情報が異なる場合、無理に単一のクリックイベントに統合せず、付帯情報を持つイベントとして独立させるべきである。

• 「コメント」クリックには、コメントIDや投稿者IDが付与されるが、「戻る」ボタンにはそれらが存在しない。
• リンク遷移を伴うクリックには、遷移元URLと遷移先URLの情報が必要。
• バッジや未読カウントを持つコントロールのクリックには、その時点の表示状態（未読数など）を付与する。
• 「フォロー」など結果を伴うアクションは、その結果の成否を付与する。

ルーティングマッピングテーブル

動的なディープリンクや多様なコンテンツ形态を持つアプリでは、同一のUI要素でもバックエンド設定により遷移先が変わりうる。このような複雑なルーティングでは、プロパティの単なるキーバリューの羅列ではなく、マッピングテーブル形式で設計するとテストや集計が容易になる。

状態の連動と経時的変化

連動（状態の伝播）

ある操作がトリガーとなり、別の要素の状態が連動して変化する場合、変化の「要因」を明確にトラッキングする必要がある。例えば、サブカテゴリのフォローを全て外した際に親カテゴリのフォローが自動で外れる仕様の場合、親カテゴリの「フォロー解除」イベントは「直接操作されたのか」「子要素の操作による連動か」を区別しなければならない。また、同種の操作結果を生むイベントは、下位レイヤーで一つのイベントにマッピングしておくことで、トラッキング漏れや後続の集計バグを防ぐことができる。

経時的変化（セッション内の変遷）

一連の行動中に付帯属性が変化するケースである。例えば、動画視聴中の解像度変更、一時停止/再生、ミニプレイヤー/フルスクリーンの切替などが該当する。これらの変遷を追跡するには、play_session_id のような一意の識別子で一連の行動を紐付ける。要件の粒度が粗い場合は、各状態変化を細かくイベント化するのではなく、セッションの特定フェーズ（終了時など）にまとめて報告する方式でも有効である。