Open Bug 1357439 Opened 8 years ago Updated 3 years ago

Expose Search Counts information in UITour.getConfiguration for snippets on about:home

Categories

(Firefox :: Tours, enhancement, P3)

Product:
Firefox
Component:
Tours
Platform:
All
Unspecified
Type:
enhancement

Tracking

()

People

(Reporter: pdol, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

User Story

As a Firefox Retention team member, I would like to be able to display snippets to users based on their total search count in the previous 28 days in order to provide useful information to users based on how heavily they search in Firefox.

Acceptance Criteria:
- Snippets are only displayed to users based on the total search count (in the last 28 days) targeting used
-- Examples:
---1. Display snippet to users whose total search count exceeded 100 in the previous 28 days
---2. Display snippet to users whose total search count was less than 20 in the previous 28 days
---3. Display snippet to users whose total search count was greater than 20 but less than 80 in the previous 28 days
No description provided.
Dave, you're much more familiar with our search count telemetry. Do we have a single search count we could use for the purpose of this bug? If so, are we able to fulfill the use cases I've listed out here?
Flags: needinfo?(dzeber)
See Also: → 1357455
Each subsession ping contains the SEARCH_COUNTS histogram listing search counts by engine and access point. However, you'd probably need some client-side code to add them up over the previous 28 days. Also, I'm not sure whether we automatically store pings ranging back that far on the client. If not, we'd have to store the running count somewhere. Georg, do you have a sense of what would be required here?
Flags: needinfo?(dzeber) → needinfo?(gfritzsche)
We store pings up to 60 days back, but don't give guarantees (they might be evicted for disk usage tresholds). Aggregating this for all the pings 28 days back means loading each individual ping in that timeframe from disk using TelemetryArchive.jsm. This might cause a significant amount of disk I/O, we should especially consider the impact on users with slow disk. Do we know yet: - how early in the session this needs to happen - how often that needs to happen - if this will happen only in response to a specific page view/open or in background too If we'd need to be more clever perf-wise we could think about storing aggregates elsewhere.
Flags: needinfo?(gfritzsche)
Depends on: 1361713
Blocks: photon-onboarding
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.