この記事は Todd Kerpelman による The Firebase Blog の記事 "New Changes Coming to Sessions and User Engagement in Analytics " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
セッションに関わる変更
これまでセッションは、以下の基準に基づいて測定されていました。
現在のセッションがなくても、アプリがフォアグラウンドに移って 10 秒経過すると、Firebase 向け Google アナリティクスが session_start
イベントをトリガーします。
アプリがフォアグラウンドに移って 30 分経過すると、セッションが終了したものと見なされます。
つまり、ユーザーがしばらくアプリを使用していて、少しの間だけ別のアプリに切り替えてから元のアプリに戻った場合でも、1 回のセッションとしてカウントされていました。
これらの時間値は両方とも、クライアントにローカルで設定できました。
BigQuery でイベントをセッション別にグループ化する場合は、手動で行うしかありませんでした。つまり、session_started
イベントの 10 秒前に発生した pseudo_user_id
に対してsession_started
と同一のイベントをすべて選択し、それをセッションが終了するまで（つまり30分経過後まで）継続する必要があったのです。BigQuery でイベントをグループ化するのは非常に面倒な作業でした。
アプリがフォアグラウンドに移るとすぐに、Firebase 向け Google アナリティクスが session_start
フォアグランドに移ってから session_start
をトリガーするのに10秒待つ必要はなくなりました。
これまでと同様、アプリがフォアグラウンドに移って 30 分経過するとセッションは終了したものと見なされます。
上記以外の変更点として、イベントに extend_session
パラメータを追加できるようになります。このパラメータを追加したイベントは、バックグラウンドでトリガーされた場合でもアクティブなセッションの一部と見なされます。バックグラウンドで使用することが多いアプリ（音楽アプリ、ナビゲーション アプリなど）に便利です。
ほぼすべてのイベントに新しいプロパティを追加し、どのセッションのイベントかを識別できるようにします。具体的には、セッション固有の識別子となる ga_session_id
イベントが追加され、単調増加する ga_session_number
パラメータを使ってユーザーのセッション数をカウントできるようになります。
これらの変更の影響
Firebase コンソールでみなさまが気づかれるであろう最も大きな変化は、アプリのセッション数が増えることでしょう。これは、ユーザーによるアプリの利用が 10 秒未満でもカウントされるようになるためです。セッション数が増えるということは、結果として統計情報の「セッションあたりの平均 xxx」は減ることになります。level_complete_quickplay
SELECT AVG(total_quickplays) as average_quickplays_per_session FROM (
SELECT COUNT(event_name) as total_quickplays,
(SELECT value.string_value FROM UNNEST (event_params) WHERE key =
"ga_session_id") as session_id
FROM `firebase-public-project.analytics_153293282.events_xxxxxxxx`
WHERE event_name = "level_complete_quickplay"
GROUP BY session_id
HAVING session_id IS NOT NULL
)
また、たとえばユーザーが購入に至るまでにかかった平均セッション数を知りたい場合も、ga_session_number
パラメータを分析することで簡単に計算できます。user_engagement
イベントとして送信していました。このイベントで送信された engagement_time_msec
パラメータの値を集計することで、ユーザーがアプリを利用した時間の合計を計算していました。user_engagement
イベントが送信されるタイミングとして一般的なのは、a）アプリがバックグラウンドに移行したとき、b）画面を切り替えたとき、c）クラッシュしたとき、d）アプリを 1 時間利用したときなどです。つまり、user_engagement
イベントは、app_exception
や screen_view
などのイベントと一緒に送信される可能性が非常に高いということです。そこで、イベントを余分に送信する代わりに、もともと送信していたイベントのパラメータとしてエンゲージメント時間を送信することにしました。user_engagement
イベントが単独で送信されることはありますが、基本的には engagement_time_msec
パラメータが追加されたイベントが Firebase 向け Google アナリティクスで自動的に生成されるようになります。まずは screen_view
first_open
app_exception
の 3 つのイベントから開始し、将来的にはその他のイベントにも追加していく予定です。user_engagement
イベントが少なくなるため、アプリのデータが若干減少する可能性があります。それ以外に、目に見える変更は特にありません。user_engagement
イベントをフィルタしている場合は、engagement_time_msec
パラメータが追加されたイベントが照会されるようにクエリを修正する必要があります。user_engagement
イベントの engagement_time_msec
パラメータを集計し、ユーザーごとに user_engagement
の合計時間を計算しています。このクエリは、今回の変更前は正常に動作しますが、変更後は不正確な値が算出されるようになります。SELECT SUM(engagement_time) AS total_user_engagement
FROM (
SELECT user_pseudo_id,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key =
"engagement_time_msec") AS engagement_time
FROM `firebase-public-project.analytics_153293282.events_20181003`
WHERE event_name = "user_engagement"
)
GROUP BY user_pseudo_id
このクエリを、engagement_time_msec
パラメータが含まれているすべてのイベントを照会するように修正すると次のようになります。SELECT SUM(engagement_time) AS total_user_engagement
FROM (
SELECT user_pseudo_id,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key =
"engagement_time_msec") AS engagement_time
FROM `firebase-public-project.analytics_153293282.events_20181003`
)
WHERE engagement_time > 0
GROUP BY user_pseudo_id
修正後のクエリの利点は、ユーザー エンゲージメントの変更前と変更後の両方の測定方法に対応できることです。つまり、BigQuery クエリを今すぐ修正しても問題なく機能し、変更が実施された後もそのまま使用できるということです。
Reviewed by Yusuke Fujita - モバイルアプリスペシャリスト