Now that the "core" ping is on Android beta 45 (via bug 1205835 et al), we need to validate the data we are receiving. This document lists basic criteria we should check for: https://docs.google.com/document/d/16ry3megND8ya-6feFQuHq3YFEl2_zyzO_vB3C3Ietrk/

The latest results can be found here: https://gist.github.com/Dexterp37/e5176ac397b5ea37ad17 Key highlights: - We are receiving duplicated core pings with the same document id (filed bug 1249308). - All the received pings look sane (the fields have the correct type and no field is missing). - A tiny fraction (0.0011%) of the clients have sent pings with an incoherent sequence number/timestamp/submission date (the submission date/timestamp was not increasing with the sequence number for some pings). - The average size of the core ping is 680 bytes. - The per-client core ping distribution suggests that most client are well-behaving (sending a modest amount of pings per day), with some of them sending up to 304 core pings per day. - It looks like individual client histories have "gaps" in the sequence numbers (an average of 3 gaps per client history), most of the gaps being 1-2 sequence numbers long.

(In reply to Alessio Placitelli [:Dexter] from comment #2) > - A tiny fraction (0.0011%) of the clients have sent pings with an > incoherent sequence number/timestamp/submission date (the submission > date/timestamp was not increasing with the sequence number for some pings). This seems small enough to file it as "strange issues" and pick it up if becomes bigger. > - The per-client core ping distribution suggests that most client are > well-behaving (sending a modest amount of pings per day), with some of them > sending up to 304 core pings per day. > - It looks like individual client histories have "gaps" in the sequence > numbers (an average of 3 gaps per client history), most of the gaps being > 1-2 sequence numbers long. Once we have persistence & later uploading with bug 1243585, this will be roughly the backlog we expect to be uploaded. Mark, does that sound like acceptable numbers or is fine-tuning required there?

(In reply to Alessio Placitelli [:Dexter] from comment #2) > - We are receiving duplicated core pings with the same document id (filed > bug 1249308). 0.11% dupe rate, if I read the gist right. Do these documents have the same client ID + document ID? Do these documents also have the same sequence ID? If those three things are the same, then we should simply drop the ping on the floor. If they're not -- same client ID, same sequence, different document ID -- then that might be explained by device backup/restore/clone, emulators, automated test systems. If only the document ID is the same, and the client ID is different, then there's a surprising lack of randomness in UUID generation. Can you give more details?

/me -> bug 1249308

ni?me for reviewing the notebook and then closing this bug. Re-running this later is bug 1251616.

(In reply to Georg Fritzsche [:gfritzsche] from comment #6) > ni?me for reviewing the notebook and then closing this bug. This looks good overall. I left some nits and feed back on IRC, but the only thing that really stood out was only looking at "max" values for ping volumes & ping sequence gap lengths.

Also, checking the contents of more fields for sanity would be good for future iterations.

This seems sufficiently good now.