We've started to plan how we'll calculate the [Audiences 2018–19 annual plan metrics](https://docs.google.com/spreadsheets/d/1SivevFV9IBhzhXQkgzPYf1Od2FIXf1yLJdLKfRK4BBg/edit?ts=5b1e475a#gid=909203420), and we've identified some infrastructural needs.
= Initial thoughts =
* Need some type of aggregated and/or denormalized table of edits that contains data about edit tags (to be used for mobile retention, mobile edits and editor counts, or anything else that relies on tagging edits)
* Timing - if datalake is only source and it isn't available till 10th after month's end, that is not tenable
* Lag - if we have to wait 2 months to see impact on retention metric, we have some real practical challenges that arise. We probably need a 2, day, 2 week metric as directional proxies for making product decisions.
* Needs to be updated daily
* Needs to have edit tags
* How to calculate mobile reverts? —Data Lake has a nice is_reverted field
* How do we do a/b testing?
* @JKatzWMF's post meeting thought: "for editors the easiest would be if we could use last digit of user id for metrics (0-9) since that sits in mediawiki tables, instead of creating an independently generated variable, but I'm not sure if we can or should use that for bucketing."