1891614 - Featurecallout in content should save ASRouter impressions once when persistant across tabs

Status: NEW

(Firefox :: Messaging System, task, P2)

Description

[Shane Hughes [:aminomancer]]

One of the problems in our implementation of newtab micro-surveys (which use the newtabFeatureCalloutCheck pseudo-trigger) is that we can't use frequency caps of any kind. Impressions are both read and saved when the message is displayed, and that includes when switching between tabs. So if you had a 1-per-day frequency cap on a message, and you did the following steps:

1. Open new tab page
2. The message displays
3. Switch to a different tab
4. Switch back to the new tab page

The message would not display again. This is because the message isn't actually part of the page content, it's rendered on top of the page, in the browser chrome. In order to make it look like it's part of the page, the message is removed when you switch away from the new tab page, and retriggered when you switch back to it. You can kinda see this in how the callout fades in when you switch back to the new tab page.

The reason this happens is because at step 2, an impression is recorded, and after step 4, when newtabFeatureCalloutCheck triggers for the 2nd time, that impression is read, the frequency caps are checked, and that prevents the message from showing again until enough time has passed.

This has so far prevented the adoption of the micro-surveys message group, which was intended to limit the number of surveys a user sees to just 1 per 6 months. Because we can't use frequency caps or message groups, our surveys run the risk of showing more often than intended.

---

Whoever picks this up can explore different ways of avoiding this issue. The first idea that came to my mind is to add a message property that prevents ASRouter impressions from being automatically recorded. Impression telemetry is entirely separate from ASRouter impressions, so it's possible to record telemetry events without saving ASRouter impressions.

Of course, we still need to save impressions, but this message property would be used so that the message itself can control when to save impressions. An ADD_IMPRESSION SpecialMessageAction could be created, allowing a message to directly create an impression for the message and its groups. Right now, we're using BLOCK_MESSAGE in microsurveys (see here for example) for a similar purpose. Since we couldn't use frequency caps, we had to block the message manually. So this would work very similarly, and it would replace BLOCK_MESSAGE wherever we're currently using it. For example, when hitting the dismiss button, instead of blocking the message manually, we'd add an impression manually.

There could be other approaches but, at a glance, this seems like the simplest solution that fully does what we want. Let me know if you have other ideas though.

Comment 1

[Punam Dahiya [:pdahiya]]

Product agreed to discussed direction of recording impression once per session for microsurvey thanks