1664847 - Log the search access point for ad clicks and searches with ads

Status: VERIFIED FIXED

(Firefox :: Search, task, P2)

Description

[Ben Miroglio [:bmiroglio]]

SAP searches log the “source”, or access-point, of the search in the SEARCH_COUNTS histogram, i.e urlbar, searchbar, newtab, etc. Ad clicks and ad impressions do not have a source logged with them, since they technically don’t happen in the urlbar, for instance.

Proposal: Carry-over the search source to the subsequent ad impression and/or click, which could be interpreted as “an ad impression/click that resulted from a search that occurred in the urlbar.” This will likely involve a new keyed histogram, that reflects the existing collection in the current keyed scalars below + an additional source field.

• browser.search.ad_clicks
• browser.search.with_ads

This will help us get at the following: Are certain access points more valuable than others? In other words: Are certain access points more likely to result in a monetizable search?

Comment 1

[Mark Banner (:standard8)]

This is going to be difficult to do reliably. We don't have any tie between where a SERP page is loaded and the SAP access point it is loaded from.

Whilst most loads are probably going to be "simple" and we could record the last used source and assume that, there are things like refreshes/session restore/going back, where we're not going to have the correct information available, and I'm not sure we'll easily be able to get it.

Comment 3

[Ben Miroglio [:bmiroglio]]

I think some level error (those cases mentioned) is OK here. The idea is really get an idea of how ad click density differs depending on the SAP used. Those cases mentioned are probably OK to get wrong at times.

CC'ing MDB and connor since we discussed these last week.

Comment 4

[Mark Banner (:standard8)]

Attachment: Bug 1664847 - Change BrowserSearchTelemetry.recordSearch to take a browser rather than tabbrowser as that is more accurate. r?daleharvey!

Comment 5

[Mark Banner (:standard8)]

Attachment: Bug 1664847 - Use a map for the search source translation in BrowserSearchTelemetry to make the code simpler. r?daleharvey!

Depends on D102440

Comment 6

[Mark Banner (:standard8)]

Attachment: Bug 1664847 - Log the search access point for searches with ads and ad clicks. r?daleharvey!

Depends on D102441

Comment 7

[Mark Banner (:standard8)]

Try push: https://treeherder.mozilla.org/jobs?repo=try&revision=163870629f6a97e4ddd25ba511dad409804a6ced

Comment 8

[Mark Banner (:standard8)]

Attachment: Data Collection Review

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e0ad6f5a2074
Change BrowserSearchTelemetry.recordSearch to take a browser rather than tabbrowser as that is more accurate. r=daleharvey
https://hg.mozilla.org/integration/autoland/rev/7ba06b4a5993
Use a map for the search source translation in BrowserSearchTelemetry to make the code simpler. r=daleharvey
https://hg.mozilla.org/integration/autoland/rev/7875c93319c5
Log the search access point for searches with ads and ad clicks. r=daleharvey

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/e0ad6f5a2074
https://hg.mozilla.org/mozilla-central/rev/7ba06b4a5993
https://hg.mozilla.org/mozilla-central/rev/7875c93319c5

Comment 11

[Teon Brooks [:teon]]

Comment on attachment 9198201 [details]
Data Collection Review

:standard8, could you update to have the Revenue DS team as the permanent monitor of this feature ([e-mail])

Comment 12

[Mark Banner (:standard8)]

Attachment: NewAdProbesDataCollection.md

Updated who will monitor. Sorry for pushing the patches early, I got a bit trigger happy with the merges happening.

Will post a separate patch to update the scalars.yaml.

Comment 13

[Mark Banner (:standard8)]

Attachment: Bug 1664847 - Update notification emails for SERP related probes. r?daleharvey!

Comment 14

[Teon Brooks [:teon]]

Comment on attachment 9198964 [details]
NewAdProbesDataCollection.md

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is Telemetry so is documented in its definitions file Scalars.yaml and the Probe Dictionary.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Revenue DS is responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction.

Is the data collection request for default-on or default-off?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does there need to be a check-in in the future to determine whether to renew the data?

No. This collection is permanent.

---

Result: datareview+

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/477df49e2b6a
Update notification emails for SERP related probes. r=daleharvey

Comment 16

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/477df49e2b6a

Comment 17

[Cristian Baica [:cbaica], Release Desktop QA]

Tested the new implementation using Fx86.0b5 on Windows 10, Ubuntu 18.04 and macOS 10.13. Tested on Fx87.0a1 on Windows 10.
The browser.search.withads.{location} and browser.search.adclicks.{location} record the values for ads for Google, DuckDuckGo and Bing. The following SAP are attached to add clicks: urlbar, searchbar, contextmenu and newtab.