What's the absolute minimal amount of data needed to send in a Flurry report, would it be just a unique user ID? So then would the device type be auto-collected or is that also a manual event? And if so then why doesn't the SDK decide on an ID just giving us an option to have a basic local ID (1, 2, 3...). Maybe it does? It's suggested that the ID should be made of a username and pass, but most games don't ask for that so I'm guessing that they might base the ID on the unique device ID? That suggests privacy issues, so would using a simple encryption on the string to generate a single (untracable) 64bit number, be a good way to generate a user ID? This of course leads on to: would 'encrypting' such a number pass through Apple's review process? Apart from that, I would find Events interesting to see which areas of the game are popular etc. Lots of question marks! Thanks for any thoughts. Edit: I'm going with a 128 bit random number for UUID. While it has it's downsides, it does avoid the issues mentioned above, plus UDID will soon be gone. Still interested in minimal Flurry, can't I just start the API alone? Surely Flurry know where reports come from.
My plan to use a random 128 bit ID is flawed in testing, when used in combination with iPhone Configuration Utility, which deletes the app (and saved data) rather than update it. Seems I would have to hard code for each tester, or use UDID for testing and random for release.
I think it just automatically uses the UDID, I don't even remember having seen an option to disable using it.
Thanks baris. After your suggestion I tried with only a session start, and sure enough there are no new users and lots of new sessions. I've gone full circle, and now realise that user ID is for personal database usage, same as gender etc. I guess they're just hard coded event names. I had the impression that unique users would go up each session if I didn't send an ID. That was wrong, though I do wonder what Flurry will do when we are restricted from the UUID soon.
