
Conclusion
この記事の結論
10か所の遷移先を確認し、検証イベントを実利用の集計から除外しました。
リンクが正しい場所へ飛ぶこと、計測イベントが届くこと、実利用の集計に入ることは独立した動作です。本番で繰り返し導線をクリックして確かめると、最後の集計に試験者の操作が混ざります。今回は利用者の行動を計測する経路と、計測を検証する経路を分けて観測しました。
今回の対応
11月6日、公式サイトの10か所の導線で遷移先を確認しました。計測の動作は検証専用イベントで試し、APIの受付応答とCloudWatchに記録されたイベントを照合しました。通常の利用集計からは検証イベントを除外しました。
10導線と1イベントの関係
10か所について確認したのは遷移先です。計測経路については検証用イベントがAPIで受け付けられ、CloudWatchに残ったことを照合しました。導線を10回確認したことを、そのまま10件の利用実績や、10件の計測イベントすべての到達確認として扱うことはできません。
状況別の判断と次の対応
| 観察した状態 | そこから判断できること | 次に確認すること |
|---|---|---|
| リンクが目的ページを開く | 遷移先は確認済み | フォームや目的の内容に届いたかを見る |
| 検証イベントに受付応答とログがある | 試験の計測経路が動いた | 検証分の分類が保持されるかを見る |
| 通常集計がゼロ | 対象期間・条件で実績を数えていない | 試験分と実利用を混ぜず期間を付記する |
問い合わせに答えられる記録
検証の時刻、どの導線を試したか、受付応答、対応するログ、集計に含めたかを一列に並べます。クリックの目的や本文などの余分な利用者情報を送らなくても、試験イベントと実利用の集計は設計次第で区別できます。
- 0110導線の到達先を確認する
- 02専用イベントの受付とログを照合する
- 03通常集計から試験分を除いて読む
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認
