It's very hard to make decisions about which events (or stateful properties within a given event) are likely to become meaningful in the future.

One option is to be pretty minimalist, recording only the events & properties that you know you need to record. The strictest interpretation of this would be as follows: After (and only after) I become curious about what percentage of users send my app to the background, I will instrument a sent to background event.

This extreme minimalism can lead to very slow iteration times, because every time you have a new hypothesis or experiment, you would need to change how your app is instrumented, then wait for users to update it, then wait for new data to stream in in sufficient quantities to perform the analysis.

Disk is cheap. The opportunity cost of missed knowledge is expensive, sometimes lethally so.

In my experiences so far, erring on the side of collecting more events & more states has often led to unexpected, sometimes super impactful outcomes.

On the other hand, Josh Dzielak's answer makes points about the dangers of a "track everything" mentality, and those points are certainly valid, especially if it gets to the point where your team is overwhelmed by the complexity of it all, or your analysis infrastructure is overwhelmed by the scale of it all -- and your team begins to ignore the data entirely. This is more common than one would think.

But if the best answer is neither to simply record everything we can imagine (optimistic), nor to record only the events & properties with a clear and present scientific use case (pessimistic), then how do I find the "best" middle ground?

Good freaking question.

Suffice it to say, there is a lot of art to doing this right, and in fact a lot of our work at my company, Keen IO, is about distilling this art into method.

So far, this is the best summary of our findings is this:

Step 1 of event modeling is always getting the granularity right. Collecting every touch/tap/swipe or every hover event is probably too granular, and the standard set of events & properties auto-captured by a service like Flurry aren't nearly granular enough. You have to be very intentional about what granularity of event you're recording. My heuristic: err on the side of recording more events instead of fewer, but make sure you have at least some theories for how each event collection might be used one day to drive the business.

Also, within each event, try to include as much state as possible. If you're recording fewer than 20 properties per event, you could be doing a lot more.

Nothing beats talking to an expert who's seen hundreds of analytics implementations (the good, the bad, the ugly). Our community of experts is always standing by on Slack.