Open Bug 1785840 Opened 2 years ago Updated 2 years ago

The follow-on searches generating ads have telemetry pings that are listed with unknown SAP

Categories

(Firefox :: Search, defect, P3)

Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr102 --- fix-optional
firefox103 --- wontfix
firefox104 --- wontfix
firefox105 --- fix-optional

People

(Reporter: cbaica, Unassigned)

Details

(Whiteboard: [search-telemetry-backlog])

Found in

  • Fx105.0a1

Affected versions

  • Fx 105.0a1
  • Fx 104.0 RC
  • Fx 102.2 ESR

Affected platforms

  • Windows 10
  • Ubuntu 20.04
  • macOS

Preconditions
Have the browser.search.region set to US.

Steps to reproduce

  1. Launch Firefox.
  2. Type in address bar 'iphone'.
  3. In the resulted search page, modify your search phrase by adding ' 13'. (doesn't really matter what you add as long as the resulting search contains adds).
  4. Click on a displayed add.
  5. Verify the 'withads' and 'adclicks' telemetry pings in the telemetry raw json.

Expected result

  • The SAP for the withads and adclicks telemetry pings are correctly recorded.

Actual result

  • The SAP for both withads and adclicks telemetry pings are recorded as unknown.
            "browser.search.withads.unknown": {
              "google:tagged-follow-on": 1
            "browser.search.adclicks.unknown": {
              "google:tagged-follow-on": 1

Regression range

  • This is not a regression. Have managed to reproduce it all the way back to the introduction of the new SAP telemetry pings for ads.

Additional notes

  • Same issue occurs for Bing.
  • For DDG, even though we don't have follow-on searches, the SAP on the edited search is listed as unknown.
            "browser.search.withads.unknown": {
              "duckduckgo:tagged": 1

Bugs in instrumentation should be filed against the component being instrumented. Looks like Search to me.

Component: Telemetry → Search
Product: Toolkit → Firefox
Has STR: --- → yes

We should probably take a look at this and see how easy it is to fix.

One issue is that we'd have to hold onto the source data for longer (e.g. until the user loaded a page that wasn't a search page), but that may then cause false positives in what was an address bar search. One such case would be having a search page that was a result of a search from the address bar, but then loading a different search page from the main browser history.

Group: mozilla-employee-confidential
Priority: -- → P3
Whiteboard: [search-telemetry-backlog]
You need to log in before you can comment on or make changes to this bug.