Closed Bug 1140528 Opened 6 years ago Closed 4 years ago

Add an email opt-in for Firefox Accounts signups

Categories

(Websites :: Basket, defect)

Product:
Websites
Component:
Basket
Version:
Production
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bniolet, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

A suggestion for where to insert the email opt-in checkbox.
74.32 KB, image/png
Details 
This bug will track the "frontend" work of adding an email opt-in to the flow for users who signup for a Firefox Account. 

We want new Firefox Account creators to opt in to an email stream that we will use to onboard the users to their new account and nurture them through our relationship funnel. 

The back-end work related to this is being handled through bug 1051808.

The UI should have a single check box for the opt-in. the check should NOT be pre-populated. The text (per bug 1055692 https://bugzilla.mozilla.org/show_bug.cgi?id=1055692 ) should be: 

"Signup for news on Mozilla and our products and services"

Additionally users should have access to the Websites, Communications  & Cookies Privacy Notice (the URL is: https://www.mozilla.org/privacy/websites/). 

- A separate checkbox is not required.  For example, below the opt-in checkbox, you can have a line that says "By proceeding you agree to our Privacy Notice" or "Questions? See our Privacy Notice"

Ideally I would like to see the opt in checkbox appear as part of the initial Account creation process. (suggestion in attached screen).
Adding Shane Tomlinson, who IIRC worked on a previous iteration of this idea.
Thanks Ben.  What is your required/desired timeline for getting this out?
Flags: needinfo?(bniolet)
Hi Ryan. The sooner the better, but I'd like to have the opt in live and collecting emails by the end of March. That doable?
Flags: needinfo?(bniolet)
> I'd like to have the opt in live and collecting emails by the end of March.

This is a very aggressive schedule, esp if it involves any new strings that must be translated.

A few questions:

* Have :rfeeley and :johngruen been consulted??
Sorry, as I thought of Ryan and John, I CC'd them and submitted the half-finished comment.

Continuing the questions:

* How much work on the auth server has been done to hand off email addresses to Basket?
* Has legal given the sign-off?
* Does either the TOS or PP need to be updated?
* Has the "delete account" path been decided upon, if a user deletes the Firefox Account, is their name removed from Basket as well?

---------------------

Basic sketch of work that will need to be done (assuming the auth server is already set up to speak to Basket):

* UX needs to approve of the designs.
* UI needs to be added, email address must be handed off to auth server. 
* Tests need to be updated.
* The fxa-js-client will need to be updated to accept additional information on sign up.
* The auth server must hand off the email address to Basket.
It is an admittedly aggressive schedule, to be sure. Obviously all we can do is all we can do. 

I can answer some of your questions: 

Legal has given prelimiary sign-off and PP does not need to be updated. (TOS for accounts should be fine since the email relationship is separate from the FxA relationship). More on legal's advice here: https://bugzilla.mozilla.org/show_bug.cgi?id=1055692

There hasn't been specific discussion of the "delete account path," but again since we're treating the email relationship and FxA relationship as two different things it makes a lot of sense to me to let the user manually end the email relationship.
For additional context, I think we did some preliminary work on this over in:

  https://github.com/mozilla/fxa-content-server/issues/992

Sorry Shane, I should have added that context when I cc'd you into this.

> * How much work on the auth server has been done to hand off email addresses to Basket?

This is currently in-place already, when the user creates an account they automatically get a record in basket.  What we don't do is opt them into any subscriptions by default.

The other back-end part of this is Bug 1051808, which exposes an OAuth-authenticated API for manipulating the user's subscriptions in basket.  IIUC, the proposal is for the content-server or related code to make a call into this API after account creation, to adjust the user's subscription preferences.

I'm open to other flows that might work better, but so far that seems like the cleanest approach overall.

> * Has the "delete account" path been decided upon, if a user deletes the Firefox Account,
> is their name removed from Basket as well?

Broadly yes, the details of this (such as they are) will be tracked in Bug 1066384.

> * UX needs to approve of the designs.

ISTM this depends strongly on how useful the previous work in https://github.com/mozilla/fxa-content-server/issues/992 still is.

I'm very hesitant to commit to anything in a March timeframe given our existing Q1 deliverables, but we'll do what we can do.
Fair enough, on the timing.
Hi Ben: I think our monthly community meeting was a casualty of the Google Apps migration. Should be resume it? As John and I see it, there are three potential options for this newsletter sign-up checkbox.

We could put it on the registration form (but we would want to measure the bounce rate to make sure that it was not increasing), on the subsequent "email sent" screen, or on the "email verified" screen (which could open in a different browser).

For every option we would want to measure engagement with the checkbox and put it where it’s most often checked.

I'm sure the implementations to these options vary and I'm not sure there are the resources to explore all three options. Perhaps rfkelly can chime in?
Flags: needinfo?(rfkelly)
Hi Ryan. I added you to the next meeting invite. It was a casualty but Chris resurrected it. 

I totally understand and agree on wanting to make sure we don't interfere with account acquisition. So I completely support monitoring bounce rate and being ready to adapt if something comes up.

I'm personally a fan of starting with it on the registration form. The check box would not be pre-checked. But I'll allow others to weigh in, of course if they have strong feelings.
Sadly there will be limited resources to explore this before end of Q1.  But we can try to lay the groundwork as Shane is doing in the PR above, and early-ish Q2 doesn't seem an unreasonable timeframe to start experimenting and measuring this.  It's potentially a good opportunity try to out our new A/B testing infrastructure.

I'd expect most of the implementation details to be common among different checkbox placements, with the exception of users who click through the verification link in a different browser.
Flags: needinfo?(rfkelly)
Understood on the timing. Thanks Ryan and team.
Wording for the opt-in prompt, via Ben and courtesy of legal:

  "Signup for news on Mozilla and our products and services."
As avatars are now ready for prime time, and display name is soon to follow, we should discuss optimizing the placement of these settings in the flow.

https://www.lucidchart.com/documents/view/b9161199-e94f-4a1b-8af0-2f8756038605

Should we go with the path of least resistance and just choose a space and implement or is this a good opportunity for an experiment? We could deploy in all these spaces and see which performs best.

Also relevant, all the variations of auth (some users may not see the account verified screen in some contexts) https://drive.google.com/open?id=16Uhb8vtGB_-krMbzaq0b3XYvTWePi_xgIElL7dquohA&authuser=1

Shane, where do you imagine is the easiest spot to put email optin? Same with avatar and display name?
Flags: needinfo?(stomlinson)
> Shane, where do you imagine is the easiest spot to put email optin? Same with
avatar and display name?

The current WIP [1] was created from the design passed to me last year. In those designs, the opt-in is on the "signup_complete" screen, if the user verifies in the same browser they signed up in. I believe this was chosen because the user needs to be authenticated to Firefox Accounts so they can interact with the Basket API.

We could do something as part of the post-verification process for all three of these. When the user opens the verification link, show a screen that allows a user to opt-in to the newsletter, set a display name and an avatar. If the user opens the verification link in a different browser, force them to enter their password first so we have a session token and can safely update their information. Of course, the user should be able to skip this screen if they wish.

If a post-verification screen results in a low uptake, we can try to move the newsletter opt-in earlier in the flow.

[1] - https://github.com/mozilla/fxa-content-server/pull/2203
Flags: needinfo?(stomlinson)
/cc Zach, who has has offered to free up some cycles to help with pushing this forward.  Zach, please take a look at the above and sync up with Shane for extra context.  IIUC we're tentatively aiming for late April to get the opt-in up and running.
After chatting with Ben and Shane, I think we should tease apart two UI aspects here.

On the one hand, we need to solicit user opt-in to the engagement stream as part of the signin process.  It seems that the most effective place for this would be a checkbox on the initial screen as Ben suggested in Comment 0.  Shane assures me we can make this work from a technical standpoint despite having to wait until after verification to actually effect the opt-in.

On the other hand, we need a way for users to manage their opt-in preference after initial signup.  I assume typically this would be someone who wants to opt out of the stream, but I guess some enterprising souls might be convinced to opt-in after the fact.  This part seems to make sense as part of a broader "settings" page with avatar etc.

:rfeeley, thoughts on the above?  Let's try to get a prototype implementation of this up and running in the next week or so.

Both of these will depend on the ability modify basket account settings with an oauth token, per Bug 1051808.
ni? :rfeeley for my comments above
Flags: needinfo?(rfeeley)
I would prefer to keep the email opt-in paired with the avatar and display name preferences, and even allow the user to specify a different email for bacn [1] (something they couldn't do easily from our spare registration screen). Therefore the verification screen makes sense, as well a mgt screen in /settings.

I will create some opt-in email mgt screens and post shortly.

[1] http://en.wikipedia.org/wiki/Email_spam#Related_vocabulary
Flags: needinfo?(rfeeley)
Holly provided me this example, which I'd like to fit to the snippet. We would need to be able to submit the form inline without changing the page. http://cl.ly/image/3M0e2Z1P303U
> I would prefer to keep the email opt-in paired with the avatar and display name preferences

Fair enough.  BTW I am working on a scheme that might let you put this before the email verification rather than after it...

> even allow the user to specify a different email for bacn 

Hmm, interesting.  Will we then have to do a second verification loop for this additional email?
> Holly provided me this example, which I'd like to fit to the snippet.

There are major drawbacks to using the snippet space for this purpose - if we want to show actual marketing, the email signup snippet will presumably not be presented to the user, leaving many users w/o an easy option to opt-in.
This has been in production for multiple years now. Closing as fixed.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.