== Background
Based on {T287709} and subsequent discussion, we will be tracking clicks to links within the regular and sticky headers and looking at the ratio between the two. Since our A/B test will only run on logged-in users, we would like to increase the sampling to ensure we have enough data
== Acceptance criteria
[] Change sampling of DesktopWebUIActionsTracking for logged in users to 100%.
[] Add an off switch ( configuration option WMEDesktopWebUIActionsTrackingOversampleLoggedInUsers) to allow us to turn this behaviour off in case of too many events
[] For anons it should remain WMEDesktopWebUIActionsTracking
== QA steps
=== Setup
If QAing on Wed 27th October of after, move to QA in production and test on fr.wikipedia.org
If QAing before Wed 27th October:
- Grab an engineer. Ask them to set the following config:
```
$wgWMEDesktopWebUIActionsTracking = 0.5
$wgEventLoggingServiceUri = 'http://localhost:8192/v1/events';
// By default EventLogging waits 30 seconds before sending
// batches of queued events. That's annoying in a dev env.
$wgEventLoggingQueueLingerSeconds = 0;
$wgEventServiceDefault = 'eventgate';
$wgEventLoggingStreamNames = false;
$wgEventServices = [
'eventgate' => [ 'url' => 'http://0.0.0.0:8192/tests' ]
];
```
=== Tests
1) Check anon behaviour
In an incognito window, click the user menu button.
See whether an event is logged.
Repeat 10 times.
Expected: About 5 out of 10 times you should see an event.
2) Check login behaviour
For logged in users clicking the user menu should always send an event even after closing the browser and opening a new page
== Sign off steps
[] This behaviour should be documented so analysts are not confused by this. Ask Jennifer where makes sense.