Closed Bug 1649524 Opened 8 months ago Closed 6 months ago

Add Moments Page Trigger for Nth Restart


(Firefox :: Messaging System, enhancement, P1)




81 Branch
81.2 - Aug 10 - Aug 23
Tracking Status
firefox80 --- wontfix
firefox81 --- fixed


(Reporter: lwright, Assigned: andreio)



(1 file)

After discussing with @jimt, we don't currently have the capability to trigger Moments Pages on numbered restarts. However, we have experimentation plans in the works to prepare for our September Moment campaigns that rely on it, so we'd like to implement this ability as soon as possible.

Is there existing telemetry properties we could expose to FMS targeting for this?

Example approach to portray what we'd like to be able to test (not official):

  • Treatment 1: Show to users on 2nd restart
  • Treatment 2: Show to users on 2nd restart + 4th restart
  • Treatment 3: Show to users on 2nd restart + 4th restart + 6th restart
  • Control: Show to users based on existing distribution strategy (targets profile age)

We want to be able to let user action help inform when the ideal time and frequency might be for future automating of Moments Pages (e.g. a mobile cross-sell CTA), since we can’t predict that a user will actually restart their browser during certain profile age timeframes.

Andrei, could you dig into this one and come up with a plan and LOE?

Flags: needinfo?(andrei.br92)

I've looked into this and there is existing Telemetry we can use making it easier to implement.
There might be some limitations around the "Treatment 1"-style scenario. Just to make sure I understand it: 2nd restart means after 2 restarts? If were counting the Firefox install separately does this mean the 3rd time that profile sees Firefox?
To give some context: as the browser starts up (regardless if brand new profile or a simple restart) that restart counter is 1.

  • If we're dealing with a new profile it will stay at 1
  • If it's an existing profile, after "a bit" that counter will jump to the correct value for that profile

If we want to rely on this existing telemetry we should only consider this counter when the value is > 1. We could check if the counter value is 2 and set the Moments Page for the next browser start.
If this approach is not ok then the technical solution might be more complicated.

Flags: needinfo?(andrei.br92) → needinfo?(lwright)

What's the order of magnitude of the counter updating in "a bit"? Is that something like <5 minutes?

I'd suggest that since this is initially an experiment, the limitation of not supporting very "early" triggers (install and first restart) would be an acceptable tradeoff to get this work scheduled/completed quickly.

(In reply to Jim T from comment #3)

What's the order of magnitude of the counter updating in "a bit"? Is that something like <5 minutes?


There is another limitation around how the targeting attribute is meant to be used right now.
Our experiments infrastructure can only deliver 1 message per branch and (in the case of moments pages) that message is blocked after successfully executing. This would prevent us from acting on the 4th, 6th etc restarts. We might have to find some workarounds here.

Hi Andrei, I think I'm following what you're saying - i.e. someone's 4th overall startup could technically be understood as their 3rd "restart" since install is the first run experience, is that right?

The ultimate goal of getting this triggering capability is for us to be able to target Moments Pages to users upon a specific startup in their desktop experience, i.e. on their 2nd overall startup (knowing their first is the about:welcome onboarding experience), or their 4th overall startup, etc. Does that help clarify things?

This will allow us to build a "journey" strategy around showing some Moments Pages to users in a certain sequence based on something other than profile age that better ensures they'll actually be shown it, since we can't dictate that someone will restart during a certain lifecycle window.

Flags: needinfo?(lwright)
Iteration: --- → 81.1 - July 27 - Aug 09
Priority: -- → P2
Assignee: nobody → andrei.br92
Severity: -- → S3
Priority: P2 → P1

Bumping to 81.2 since Andrei's on PTO.

Iteration: 81.1 - July 27 - Aug 09 → 81.2 - Aug 10 - Aug 23
Pushed by
Add targeting attribute for total session count r=k88hudson
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
You need to log in before you can comment on or make changes to this bug.