Reading/Web/EventLogging best practices

Also see Reading/Web/Quantitative Testing and WMF-wide EventLogging best practices: Extension:EventLogging/Guide

Schemas

 * Schemas in MobileFrontend should be prefixed with
 * The talk page should be edited with the  template. For example Schema_talk:MobileWebSearch

Privacy
When building a schema, there is always a risk of exposing information to an attacker about users. It's thus important to think about the questions your schema would like answered and be careful about the sort of data you log.

The analytics team have provided best privacy practices for when writing schemas.

We advise that for new schemas we avoid trying to capture everything possible. We also advise talking to an analytics team member prior to deploying a schema to production. Fixing privacy problems can be expensive and it's worth the investment up front!

More than one schema?
It's possible that privacy issues can be avoided by splitting schemas into multiple schemas. For example if you plan to answer questions such as "What is the most popular page printed on Wikipedia?" as well as "How many people print in the Vector skin on mobile?" it might be necessary to use 2 schemas to capture this information without sacrificing our user's privacy. Probably, both schemas would need to be sampled, otherwise, the timestamp field could be used to re-link them (if the schema is sampling user sessions instead of events, the sessions should also be sampled independently in both schemas).

Sampling rate

 * When logging events that occur on every page view a sampling rate of 0.01%
 * If that schema is likely to track more than 1 event on a given page a more conservative measure of 0.005% is advised. When running the meta:SchemaMobileWebSectionUsage schema for example 1% was too high.
 * Be sure to check events for any newly deployed schema in the the Grafana dashboard - above 40 events per second is typically a warning flag
 * When click tracking events on prominently used features, 1% is usually enough e.g. clicks to menu items or search usage (given that not all page views result in an event).

Consideration for experimental features in beta
If wanted you may want to consider a 100% sampling rate in beta. If so, please put this in the acceptance criteria for the task which implements the schema.

Use of session ids

 * Some events need to be linkable to other events, for example Schema:MobileWebSectionUsage records clicks to section headings in a given user session. This is usually done via a unique token that is generated once and used until the user closes the browser.
 * In some situations where workflows span multiple pages it may be necessary to persist such a token a little longer. When this is the case please ensure you minimise the duration the session is stored for.

Testing
We test EventLogging code by applying the following code in our console: This will show all events in the console and as a mediawiki notification.