私のアプリは通常、フォアグラウンド アプリとして、またはバックグラウンド オーディオを実行しながら、ベビー モニターとして一晩実行されます。
目標:
- アプリの起動総数を追跡します。アクティブ ユーザー数。
- フォアグラウンドとバックグラウンドでの合計使用時間と合計セッション時間を追跡します。
- 設定画面をナビゲートする場合、さまざまなページビューを追跡します。
推奨どおり、トラッカーを で開始し、最初の「ページビュー」として最初のdidFinishLaunchingWithOptionsトラッキングを行います。ViewController私のアプリは、次の 8 時間、このページにとどまる可能性があります...
次に、いくつかの問題が表示されます。
いつ電話をかけ
stopTracker、何をしますか? 追跡セッションが終了することを願っています。しかし、Google は親切にもコードを静的ライブラリに隠してしまったので、裏で何が起こっているのかわかりません。ただし、最初の本能はstopTracker、applicationWillResignActiveユーザーがバックグラウンドオーディオを有効にすることを決定した場合、アプリがまだ実行されていることです...次に、新しいページビューがない場合、または真夜中にセッションが 30 分後にタイムアウトする可能性があることを読みました。同じページビューを 20 分ごとに送信するように繰り返しタイマーを設定できます。これにより、少なくとも深夜までセッションが維持されますが、ページビューははるかに大きくなりますか? 私がすべての呼び出しで同じページにいることを知るほど賢い場合を除きます。 Google アナリティクス ブログ
[更新: 各呼び出しは新しいページビューとしてカウントされるようで、数値が歪んでいるため、これを処理する方法がまだ問題です]
上記のタイマーが午前 0 時を過ぎてセッションが期限切れになった場合、新しいセッションが開始され、実際のアクティブ ユーザー数が 2 倍になりますか?
を呼び出し
stopTrackerた場合applicationWillResignActive、ページビューを追跡するための次の呼び出しでトラッカーが再起動されますか?startTrackerWithAccountIDそれとももう一度電話する必要がありますか？代わりに でトラッカーを開始する
applicationDidBecomeActiveと、バックグラウンドで実行されていた可能性のあるセッションが失われます。
[更新: これはこれまでのところ最良のアプローチのようですが、分析レポートのタイムラグによりテストが非常に遅くなります。すぐに報告します]
PS EasyTracker はこれをうまく処理していないようです。