We keep coming back sometimes to the environment being too heavy-weight for some use-cases. The critical set of dimensions that we repeatedly use should be more limited though. If we can define a smaller set, we could implement this as a common ping feature (as an option on submitExternalPing()) instead of multiple pings copying this around.

One possibility: Allow callers to specify what kind of environment data they need (e.g. OS data, addons data, ...).

What are the specific problems? Size? Compressed, I don't think the environment's large enough to be troublesome for "normal" ping frequencies (once per install, once per profile, once per subsession) Complexity? The environment _is_ a highly-nested structure. -- If we are going to provide a minimal environment, the choice of fields is key. I think the best way to determine this is to see which ones have been added to downstream derived datasets. For everything we remove we can replace with "summarized" stats. Don't send active_addons? Send num_active_addons and num_system_addons instead so we can still answer the "has addons" question. Replace plugins with flash_version. And so on.

There are two main concerns that drive this: - size, the environment data presumably gets expensive at scale - complexity, keeping structures more simple/comprehensible We seem to come back to some common dimensions, like basic OS data in bug 1373093 & for the health ping. The addons ping also dropped the environment. While this is a bit vague so far, we already have recurring needs for that and should see how to solve this more generically. I believe the next steps here are to: - collect the use-cases - look at common analysis needs (e.g. through the dataset usage) - extrapolate from these - make a decision about further steps from there