Page MenuHomePhabricator

Sticky header: Change sampling of DesktopWebUIActionsTracking for logged in users
Closed, ResolvedPublic3 Estimated Story Points

Description

Background

Based on T287709: [SPIKE] Explore instrumentation for sticky header work 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.

  1. 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.

QA Results - Prod

ACStatusDetails
1T292588#7467116
2T292588#7467116

Event Timeline

ovasileva renamed this task from Change sampling of DesktopWebUIActionsTracking for logged in users to Sticky header: Change sampling of DesktopWebUIActionsTracking for logged in users.Oct 5 2021, 9:15 PM
ovasileva triaged this task as High priority.
ovasileva created this task.

Change 731827 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[operations/mediawiki-config@master] Bump DesktopWebUIActionsTracking sampling rate to 100%

https://gerrit.wikimedia.org/r/731827

Change 731829 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/extensions/WikimediaEvents@master] Add config option to turn off DesktopWebUIActionsTracking events for logged in users

https://gerrit.wikimedia.org/r/731829

bwang removed bwang as the assignee of this task.Oct 18 2021, 7:57 PM
bwang moved this task from Doing to Code Review on the Web-Team-Backlog (Kanbanana-FY-2021-22) board.
bwang subscribed.

Change 731827 abandoned by Bernard Wang:

[operations/mediawiki-config@master] Add WMEDesktopWebUIActionsTrackingOversampleLoggedInUsers config

Reason:

No need for config change

https://gerrit.wikimedia.org/r/731827

Jdlrobson claimed this task.

Change 732396 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/WikimediaEvents@master] Patch demo do not merge: Test T292588

https://gerrit.wikimedia.org/r/732396

Change 732396 abandoned by Jdlrobson:

[mediawiki/extensions/WikimediaEvents@master] Patch demo do not merge: Test T292588

Reason:

https://gerrit.wikimedia.org/r/732396

Change 731829 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Use config option to over sample DesktopWebUIActionsTracking events for logged in users

https://gerrit.wikimedia.org/r/731829

Edtadros subscribed.

Test Result - Prod

Status:
Environment: frwiki
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

Check anon behaviour
In an incognito window, click the user menu button.
See whether an event is logged.
Repeat 10 times.
❓ AC1: Expected: About 5 out of 10 times you should see an event.

IterationEvent Triggered
1Yes
2No
3No
4No
5Yes
6Yes
7No
8No
9No
10No

@Jdlrobson, 10 attempts is a small sample. I think these kinds of sampling tests are better validated by looking at production logs. Thoughts?

Check login behaviour
✅ AC2: For logged in users clicking the user menu should always send an event even after closing the browser and opening a new page

{
  "action": "click",
  "isAnon": false,
  "skinVersion": 2,
  "skin": "vector",
  "editCountBucket": "0 edits",
  "isSidebarCollapsed": false,
  "token": "4e7908e24e694d436d9f",
  "name": "ui.dropdown-p-personal"
}

The event above fires each time I click the user menu.

@Jdlrobson, 10 attempts is a small sample. I think these kinds of sampling tests are better validated by looking at production logs. Thoughts?

Exactly. I think the fact you got a mixture of yes and no here is enough to pass this for now.

@jwang could you perhaps QA this further, by looking at production logs and checking that we are seeing an increase in events from logged in users but a similar amount for anons?

@Jdlrobson, @jwang - I think we can close this and track further QA under T294639: Schema QA sticky header instrumentation - would that makes sense?

Yes, the schema QA for sampling rate can be tracked at T294639.

jwang removed jwang as the assignee of this task.Nov 1 2021, 6:10 PM