Page MenuHomePhabricator

Instrument empty state of search experiment
Closed, ResolvedPublic3 Estimated Story PointsDesign

Description

Background

See parent ticket

User story

  • As a product team, we want to know whether adding recommendations into search will benefit users so that we know whether to invest our time into this idea

Requirements

The experiment designed should allow us to track the following:
Quantitative metrics - high priority

  • Impressions - can be search sessions initiated (clicks within the search bar) OR some way that we've detected that we're showing a suggestion
  • Clicks on suggestions
  • Whether a given pageview is using the extension

The experiment should allow us to survey participants on the following:

The experiment should allow us to collect the data above also for the related pages feature.

Requirement

The search experiment should track the following metrics: impressions (when suggestions are shown), clicks on suggestions, and additional clicks. The system should ensure that only the first click fires the "click" event, and subsequent clicks fire the "clickAdditional" event. The experiment should allow verification via the Chrome DevTools Console.

BDD

Feature: Instrument Search Experiment with Event Tracking

  Scenario: Track impression events
    Given the user opens the search box
    When suggestions are shown
    Then an impression event should fire each time suggestions appear
    And the impression event should be logged as counter.MediaWiki.experiment.web.emptySearch.{dbname}.impression

  Scenario: Track click events on suggestions
    Given the user clicks on a suggestion in the search box
    When the first click occurs
    Then a click event should fire
    And the click event should be logged as counter.MediaWiki.experiment.web.emptySearch.{dbname}.click

  Scenario: Track additional clicks on suggestions
    Given the user clicks a suggestion multiple times
    When subsequent clicks occur
    Then a clickAdditional event should fire
    And the clickAdditional event should be logged as counter.MediaWiki.experiment.web.emptySearch.{dbname}.clickAdditional

  Scenario: First click triggers click event, additional clicks trigger clickAdditional
    Given the user clicks a suggestion in the search box
    When the first click occurs
    Then only the first click should fire a click event
    And subsequent clicks should fire clickAdditional events

Test Steps

Test Case 1: Verify Impression Events

  1. Open the search box and view the suggestions.
  2. Close the search box and reopen it.
  3. Open the Chrome DevTools Console and verify the event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.impression.
  4. AC1: Confirm that an impression event fires each time suggestions appear.

Test Case 2: Verify First Click Event

  1. Click a suggestion in the search box.
  2. Open the Chrome DevTools Console and verify the event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.click.
  3. AC2: Confirm that a click event fires on the first click.

Test Case 3: Verify Additional Click Events

  1. Click the same suggestion multiple times.
  2. Open the Chrome DevTools Console and verify the event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.clickAdditional.
  3. AC3: Confirm that the first click fires the click event and all subsequent clicks fire the clickAdditional event.

Test Case 4: First Click Fires Once

  1. Open the search box and click a suggestion.
  2. Confirm that any additional clicks on the same suggestion fire the clickAdditional event.
  3. AC4: Confirm that only the first click fires the click event.

Design

n/a

Acceptance criteria

Communication criteria - does this need an announcement or discussion?

n/a

Rollback plan

  • n/a

This task was created by Version 1.2.0 of the Web team task template using phabulous

QA Results - Prod

Event Timeline

Note: can we get session length ?

ovasileva renamed this task from Instrument empty state of search to Instrument empty state of search experiment.Aug 19 2024, 5:14 PM

@ovasileva Yes, there's existing fields already that we can extrapolate with sql queries.

@EBernhardson, I understand that search sessions are being tracked on desktop, but there might be limited to no tracking on mobile due to past optimizations. I could be wrong, but I'm assuming most readers usually stick to one platform during a session. If that's the case, could we just use the existing search data and instrumentation data to set a baseline for the search session initialization metric.

Also, would it be okay for us to re-enable mobile web/Minerva tracking for search sessions, or will that be too disruptive? I'm asking since we need consistent data collection across both desktop and mobile to create a baseline for our experiment. Otherwise, we can just proceed with our plan and add more data-event attributes to search.

Regarding

  • Impressions of search suggestion

@ovasileva / @jwang
Just to double-check, are you looking to collect data on exactly what suggestions a user sees in the search dropdown when they type a letter like “f” in the search input? I want to make sure we’re on the same page about what data we need to capture at that moment.

Like so (on keydown, fire event, payload should include the list of articles pictured):

Screenshot 2024-08-21 at 4.46.55 PM.png (712×1 px, 184 KB)

ty!

@EBernhardson, I understand that search sessions are being tracked on desktop, but there might be limited to no tracking on mobile due to past optimizations. I could be wrong, but I'm assuming most readers usually stick to one platform during a session. If that's the case, could we just use the existing search data and instrumentation data to set a baseline for the search session initialization metric.

I agree that seems like a reasonable assumption. There are probably some users that switch (there is a link in the footer), but it's certainly a small number. Using the existing data as a baseline seems perfectly acceptable to me.

Also, would it be okay for us to re-enable mobile web/Minerva tracking for search sessions, or will that be too disruptive? I'm asking since we need consistent data collection across both desktop and mobile to create a baseline for our experiment. Otherwise, we can just proceed with our plan and add more data-event attributes to search.

It doesn't look like simply delivering the tracking code will be sufficient to enable tracking in minerva. The instrumentation depends on the autocomplete javascript to call mw.track(...) with appropriate arguments in appropriate places, but a quick grep through the skin code shows minimal usage of mw.track and those parts are unrelated to search. I'm not super familiar with how minerva is implemented so there might be bits somewhere, but we would probably need to involve mobile developers that are more familiar.

Just to double-check, are you looking to collect data on exactly what suggestions a user sees in the search dropdown when they type a letter like “f” in the search input? I want to make sure we’re on the same page about what data we need to capture at that moment.

Is this instrumentation for the existing search feature or the planned feature with the default recommendation in the search box?

I explored the schema a little bit. It seems the instrumentation has already been enabled for the event of typing a letter in the search input in searchsatisfaction schema on desktop. But I did not see the event for showing the search box after a click of the search icon. It is the "Impressions of search box" for existing feature. It will be "Impressions of the search box with suggestions" for the future feature. We will need it for the analysis. Depending on how we define Search sessions initiated, the two might be same.

@ovasileva, please clarify the measurement questions, so that we can design the instrumentation accordingly.

Screenshot 2024-08-22 at 11.00.03 AM.png (124×1 px, 30 KB)

Screenshot 2024-08-22 at 10.59.52 AM.png (128×1 px, 17 KB)

Change #1065288 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[mediawiki/extensions/MobileFrontend@master] Adds event attributes

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

Change #1066947 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[mediawiki/skins/Vector@master] Adds event attributes to search

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

ovasileva updated the task description. (Show Details)

Hi @KSarabia-WMF , @ovasileva, I have drafted an instrumentation spec for search recommendations on extension (T371236#10103720) . Let me know if you have any questions.

Impressions - can be search sessions initiated (clicks within the search bar) OR some way that we've detected that we're showing a suggestion

Regarding the impressions, based on the discussion with Olga, we only want to implement light instrument, and we don't plan to log whether the user has installed the extension or not. The clicks into the empty search bar cannot be interpreted as impressions, as users without the extension won't see the search suggestions, and we cannot filter them in data. Therefore, I suggest that an impression is counted when the list of the search recommendations appears (before enter a letter).

@jwang if we just logged total numbers of impressions for the following would that be sufficient, or do you need session Ids and additional information e.g. browser resolution?

  • Number of impressions of when a user visits a page using the browser extension.
  • Number of impressions of when a user using browser extension sees the empty search result state
  • Number of impressions of when a user using browser extension clicks one of the results in the empty search result state.

if we just logged total numbers of impressions for the following would that be sufficient, or do you need session Ids and additional information e.g. browser resolution?

Number of impressions of when a user visits a page using the browser extension.
Number of impressions of when a user using browser extension sees the empty search result state
Number of impressions of when a user using browser extension clicks one of the results in the empty search result state.

If each impression of an empty search result can only leads to 1 click, not multiple clicks, they should be sufficient for an overall click through rate. @ovasileva, do we need average CTR per page or per session?

Key Questions

  • Is session information necessary for this task? If not, can we use a more lightweight method, such as statsv, to collect the required data? This would simplify the implementation and remove the need for patching WikimediaEvents.
  • How will we filter the collected data to ensure it only applies to users of the browser extension, as specified by Jennifer? The current patch might not adequately address this requirement.
  • How can we guarantee that all relevant events within the browser extension are logged to achieve 100% coverage?
  • Given that Jan’s investigations suggest we might not be able to access the mw object in the browser extension, how does this limitation impact our approach to logging data?

if we just logged total numbers of impressions for the following would that be sufficient, or do you need session Ids and additional information e.g. browser resolution?

Number of impressions of when a user visits a page using the browser extension.
Number of impressions of when a user using browser extension sees the empty search result state
Number of impressions of when a user using browser extension clicks one of the results in the empty search result state.

If each impression of an empty search result can only leads to 1 click, not multiple clicks, they should be sufficient for an overall click through rate. @ovasileva, do we need average CTR per page or per session?

Per page would be okay. I don't think we need session data (cc @KSarabia-WMF)

We added some low level instrumentation using statsv. Talking to Olga it sounds like that should be sufficient for testing our hypothesis and doesn't require modifications to our click tracking schema. I'll sync today with Kim on where we are and what's left.

QA INSTRUCTIONS

  1. Impression Event
    • Test Case: Open the search box, see suggestions, close it, and reopen.
    • Expected: An impression event fires each time suggestions appear.
    • Verify:
      • Event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.impression.
      • Impressions match the number of times suggestions are shown.
  1. Click Event
    • Test Case: Click a suggestion.
    • Expected: The first click fires a click event.
    • Verify:
      • Event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.click.
  1. Additional Click Event
    • Test Case: Click a suggestion multiple times.
    • Expected: First click fires click, subsequent clicks fire clickAdditional.
    • Verify:
      • Event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.clickAdditional.
  1. First Click Fires Once
    • Ensure only the first click triggers click, and all others trigger clickAdditional.

Actions to Test:

  • Open/close the search box multiple times: Impressions should track each time.
  • Click a suggestion multiple times: First click should fire click, additional clicks fire clickAdditional.
  • Check both left and right clicks (focus on left clicks).

How to Check Events:

  1. In Chrome DevTools Console:
    • Look for:
      • counter.MediaWiki.experiment.web.emptySearch.{dbname}.click
      • counter.MediaWiki.experiment.web.emptySearch.{dbname}.clickAdditional
      • counter.MediaWiki.experiment.web.emptySearch.{dbname}.impression
Edtadros removed Edtadros as the assignee of this task.EditedSep 8 2024, 12:02 AM
Edtadros subscribed.

Test Result - Prod

Status: ✅ PASS
Environment: enwiki (extension not enabled for beta)
OS: macOS
Browser: Chrome
Device: MS MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Test Case 1: Verify Impression Events

  1. Open the search box and view the suggestions.
  2. Close the search box and reopen it.
  3. Open the Chrome DevTools Console and verify the event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.impression.
  4. AC1: Confirm that an impression event fires each time suggestions appear.

screenshot 12.mov.gif (932×1 px, 804 KB)

Test Case 2: Verify First Click Event

  1. Click a suggestion in the search box.
  2. Open the Chrome DevTools Console and verify the event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.click.
  3. AC2: Confirm that a click event fires on the first click.

screenshot.mov.gif (932×1 px, 641 KB)

Test Case 3: Verify Additional Click Events

  1. Click the same suggestion multiple times.
  2. Open the Chrome DevTools Console and verify the event: counter.MediaWiki.experiment.web.emptySearch.{dbname}.clickAdditional.

screenshot 2.mov.gif (1×1 px, 1 MB)

  1. AC3: Confirm that the first click fires the click event and all subsequent clicks fire the clickAdditional event.

Test Case 4: First Click Fires Once

  1. Open the search box and click a suggestion.
  2. Confirm that any additional clicks on the same suggestion fire the clickAdditional event.
  3. AC4: Confirm that only the first click fires the click event.

See AC3 above

Change #1066947 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] Adds data-event-names to search input and button

Reason:

(Shouldn't be needed any more)

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