Bugzilla

I'm wondering if we should keep these separate, since they have separate concerns:

1. Crashes - if we want to track crashes, we will probably use the crash ping. We should not use sequence numbers to determine if or when an app crashed; since there are other reasons for missing pings. If we want to track number of crashes, we could additionally make it a `counter`.

2. Foreground Sessions - Since this is an important metric, we should track it separately, as _exactly_ the number of times we went to foreground. I like having this be a ping-lifetime, so that we can look at a period of time and easily `SUM` the number of foreground sessions.

3. Sequence Numbers - Given we're not tracking crashes or sessions, sequence numbers should be mostly relevant to us in determining "Did we miss a piece of data?". My assumption here is that if a user is using the application, there should be _a_ baseline ping representing that activity in some way. I think then that we should attempt to send pings that we see were missed for some reason, especially if we separate out Foreground Sessions into a separate metric. Alessio's approach might then look like:


1. app starts;
  1a. seq=2 is loaded off the disk;
  1b. seq++ so `seq=3;
2. baseline ping gets generated;
  2a. we send the ping with seq=3
  2b. seq++ so seq=4 now;
3. app crashes;
4. app restarts;
  4a. seq=4 is loaded off the disk;
  *4b.* The previous ping was unsent, send;
  4c. seq++ so `seq=5;
5. baseline ping gets generated;
  5a. we send the ping with seq=5
  5b. seq++ so seq=6 now;

That gives a more complete history of the user. Then if we see missing sequence numbers they should mean something more serious to us, and hopefully provide a valuable signal.

Thoughts, Alessio?

I'm wondering if we should keep these separate, since they have separate concerns:

* Crashes - if we want to track crashes, we will probably use the crash ping. We should not use sequence numbers to determine if or when an app crashed; since there are other reasons for missing pings. If we want to track number of crashes, we could additionally make it a `counter`.

* Foreground Sessions - Since this is an important metric, we should track it separately, as _exactly_ the number of times we went to foreground. I like having this be a ping-lifetime, so that we can look at a period of time and easily `SUM` the number of foreground sessions.

* Sequence Numbers - Given we're not tracking crashes or sessions, sequence numbers should be mostly relevant to us in determining "Did we miss a piece of data?". My assumption here is that if a user is using the application, there should be _a_ baseline ping representing that activity in some way. I think then that we should attempt to send pings that we see were missed for some reason, especially if we separate out Foreground Sessions into a separate metric. Alessio's approach might then look like:


1. app starts;
  1a. seq=2 is loaded off the disk;
  1b. seq++ so `seq=3;
2. baseline ping gets generated;
  2a. we send the ping with seq=3
  2b. seq++ so seq=4 now;
3. app crashes;
4. app restarts;
  4a. seq=4 is loaded off the disk;
  *4b.* The previous ping was unsent, send;
  4c. seq++ so `seq=5;
5. baseline ping gets generated;
  5a. we send the ping with seq=5
  5b. seq++ so seq=6 now;

That gives a more complete history of the user. Then if we see missing sequence numbers they should mean something more serious to us, and hopefully provide a valuable signal.

Thoughts, Alessio?