tracking eventの検証をするときのちょっとしたコツについて

はじめに

組み込み系のサービスのQAをやっている人はあまり馴染みがないかもしれませんが、Web系のアプリを運営していればなにかしらユーザーのアクションをtrackingしているのではないかと思います。そしてそのtrackingが期待通りかQAしたこともあるのではないかと思います。

この記事で扱わないこと

　どのようなツールを使うと良いか
　ユーザーの行動を計測する効果的なtracking eventの設計のしかた

この記事で扱うこと

　QA/テストエンジニアがtracking eventの検証をするときのちょっとしたコツについて

tracking eventとは？

　ユーザーがなんらかのアクションしたことに対してtracking eventを送信しデータを収集することによって、ユーザーによるアプリケーションの利用状況を確認することができます。
　色々なツールがありますが、Google analyticsのログをBigQuery等に取り込みそれを分析することが行われていたりします。

なぜtracking eventの検証が大切なのか？

　データ分析のためユーザーの行動を計測し、今後のキャンペーンや仕様変更を検討する際の判断に使われます。
　もしtracking eventが正しく送信されていなければそれらの判断を誤るリスクがあります。

　すべてのユーザーのアクションをtrackingできるのが理想かもしれないですが、現実には必要なeventのみ実装されることも現実的だと思います。

検証するときのちょっとしたコツ

　tracking eventにuser_idを送信するのであれば、こんなSQLでユーザーホゲホゲがチョメチョメしたeventを抽出することができます。そして多くの場合はこれで足りることが多いかもしれません。

SELECT *
 FROM テーブル名
WHERE
 user_id = ホゲホゲ AND event_id = チョメチョメ

　複雑なSQLを書く必要はないと思います。条件を絞りすぎることによってむしろ見落としてしまう可能性があります。なぜならeventが送られることの確認だけじゃなくて送られないことの確認も必要になるからです。
　データ分析のためなので送信される条件が統一されていることが必要になります。
　countしてしまうと例えば5回eventが送られたとしてどの5回なのかわからないのでselectで一覧を出して確認したほうが多分楽です。

具体例

　例えばあるECサイトでユーザーが商品を閲覧したeventをtrackingするとして、以下のような要件が与えられていたとします。

* 販売中の商品を閲覧した場合にeventを送信する。
* 品切れ中の商品を閲覧した場合はeventを送信しない。
* Topページのおすすめ商品から商品を閲覧した場合も、検索結果から商品を閲覧した場合もeventを送信する。
* 同じユーザーが複数回同じ商品を閲覧した場合も毎回tracking eventを送信する。ただし商品画面から購入画面に遷移して、購入せずに商品画面に戻った場合はeventを送信しない。

この場合、確認しないといけないことは最低でも以下のようになると思います。
1. Topページの販売中の商品Aを閲覧してeventが送られること
2. 検索結果から販売中の商品Bを閲覧してeventが送られること
3. Topページの品切れ中の商品Cを閲覧してeventが送られていないこと
4. 検索結果から品切れ中の商品Dを閲覧してeventが送られていないこと
5. Topページの販売中の商品Aを2回目閲覧してeventが送られること
6. 検索結果から販売中の商品Bを2回目閲覧してeventが送られること
7. 商品Aについて購入画面に遷移し、商品画面に戻った場合にeventが送られていないこと

この場合、商品Aについて送られるeventの数を数えてもどのケースで送られたeventかわかりませんし、最悪の場合、ケース5でeventが送られていなくて、送られるべきではないケース7で送られていても気が付かない可能性があります。
なのでたぶん良い方法があるとは思うのですが、特に思いつかなければケース1のアクションをしてSQL実行して確認、ケース2のアクションをしてSQLを実行して確認というのを地道にやらなければならないかもしれません。（私はそのようにやっちゃってます）

まとめというかポエム
　

  tracking eventを検証するための便利なSQL等の方法が書かれていると思ってこの記事を読もうとした人はすみません。
　tracking eventについてQAエンジニアが発信しているのを私はあまり見たことがないですし、検索してもあまり見つかりませんでした。なのでちょっと書いてみました。
　リファクタリング等によってtracking eventが正しく送信できなくなったことで、緊急リリース等を経験したことがあります。その割にQA界隈ではtracking eventについては軽視されがちではないかと思ってます。
　tracking eventというクライアント側から見えないものについて要件を充たしているかの確認は地味な作業になってしまうと思います。自動テストで逐一tracking eventのconfirmationをしているという話を私はあまり聞いたことがありません。ただ、リリース後はtracking eventが送られなかったらアラートを飛ばす等によって効率化できるかもしれません。皆様に置かれましてはどのように品質保証を行われているのでしょうか？
　SQLを使ってcountすることは、trackingの検証においてはあまり有用ではないと思っていますが、不具合の影響範囲を確認して優先度を判断する上では対象ユーザー数の抽出は必要になると思います。
　品質の定義を「誰かにとっての価値である」という場合のその誰かというのは、お客さまだけじゃなくて中の人のためでもあったりするのではないかと思います。ただ、trackingを内部品質というのとはまたちょっと違うのかなと思ったりもします。