The property field has fairly high cardinality, with about 2000 different values as of last month. Otherwise the dataset would be very simple, with the sole measure being the number of actions (events), aggregated by (say) hour.
We'll also need the following standard event capsule fields, in order to monitor the rate of preference changes on particular projects or from particular kinds of clients:
- Browser Family
- Browser Major
- Browser Minor
- Device Family
- OS Family
- OS Major
- OS Minor
The following event fields should be left out:
- version (apparently not in use anyway)
- value (not consistent between properties, probably large cardinality, partly redundant to isDefault for the use cases motivating this ticket)
A current use case would be for the web team to easily monitor the rate of opt-ins and opt-outs to the new (first deployment yesterday) Advanced Mobile Contributions mode, per project, see e.g T211197#4951773 ff. But there are many other use cases , considering the multitude of user preferences where the rate of users switching from/to the default state can be of interest.