Granular opting in/out of email communication from Webmaker

RESOLVED FIXED

Status

Webmaker
Login
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: sedge, Unassigned)

Tracking

Details

(Whiteboard: see comment 9 and comment 14 for decisions)

(Reporter)

Description

5 years ago
How granular do we need permissions to be about emails to Webmaker users from the Webmaker services?
I liked the idea of having a flags object that we could add a number of things to personally but there were problems with updating that I remember you mentioning?
Ryan/Erica: we need to understand the *required* granularity for Webmaker emails. Broadly speaking, there are two categories of email we plan on sending:

 - notifications direct from the Webmaker site & tools to users (ex: claim this make, badge related notifications, etc)

 - engagement emails sent from Blue State Digital (ex: campaigns, re-engagement, etc)

The question is: do we want separate opt-out options for these types of email, do we need even finer grained opt-outs (ie: multiple opt out types for BSD notifications) or is a single "never send me mail, ever" good enough?

Also including cassiemc as this has a UX impact.
(Reporter)

Comment 3

5 years ago
:booze - I fixed that by removing the nesting of all flags under one attribute.

Here's a better description of this bug:

The Webmaker Login SSO will require (to some degree) granular dependancies for all email communications to users.  Perhaps an opt-out system?

Comment 4

5 years ago
I'm not sure I understand the question. On sign-up, are we adding people to the general Mozilla mailing list and tagging them, or are we adding them to a user mailing list and tagging them?
Ryan: on sign up, we are collecting email addresses.

What we're asking is: what granularity of email opt-out do we want (or need, for regulatory or privacy policy or values compliance) to be offering?

What I'm providing as context is that we have various reasons to email users, but broadly they fall into notification purposes (as regards the activities and tools available) and engagement purposes (segmentable by user metrics, but not 1:1 correlated with a specific action or event in the tools and system)

Helpful?

Comment 6

5 years ago
Users should be told what they're being signed up for, and they should be able to opt-out completely or in part. Ideally, they can decide to keep their account but not be on the Mozilla mailing list, etc., and do that from a single opt-out dialogue.
Oh, erg, that's another question I hadn't thought of; should we be prompting them to join the Mozillians email list? I'd suggest that be opt-*in* instead of opt-*out* ...

Comment 8

5 years ago
Yes, we'd like to offer them the chance to get on our updates list. I also want to balance that against  the amount of things we ask for up front to minimize the drop-out.
In the interests of moving things forward, here's my proposal:

 * allow users to opt-out of engagement email
 * do not allow users to opt-out of notification email

This implies:

 * from a UI perspective, it's a single "Do not send me email about the Webmaker program" opt-out checkbox when creating an account - when a user opts-out, we won't pass their email address through to Blue State Digital on any future export actions

 * we can, however continue to send re-activation emails as a system notification task with whatever solution we end up using for system notification emails

 * we can optionally prompt users to join the Mozillians email list as a separate task anywhere along the sign-up or user engagement flow, as an opt-in request

Ryan, Cassie, Brett: so say we all?
Flags: needinfo?(ryan)
Flags: needinfo?(cassie)
Flags: needinfo?(brett)

Comment 10

5 years ago
This plan is fine with me. 

For terminology's sake, there is only the Mozilla E-mail List - no separate Webmaker list.
Flags: needinfo?(ryan)
Ryan: help me understand that; are you saying that whenever you pull information for Blue State Digital to use, that would be branded/presented as a "Mozilla List" mail out as opposed to a "Webmaker" mail out? Additionally, would you plan on sending those users (who only signed up via Webmaker) email about non-Webmaker activities?
works for me
Flags: needinfo?(brett)
Going to add Ben Simon - who knows BSD and the legal policy on emails to this thread.

From my understanding if we're proposing adding a user to our BSD list when they sign up:

* we can add them to an additional webmaker group - this provides us the granularity between the all-mozilla list and an additional webmaker list
* we are legally *required* to include the text "Yes, I'd like to receive updates about Maker Party 2013, and I’m okay with you handling this info as you explain in your privacy policy" next to a checkbox

:bsimon - can you confirm those two things for us?

Normally not clicking the checkbox would mean the form can't be submitted but I think in this case we can just not sign the users up to the BSD list we choose.

In addition - just want to confirm that we can't directly enter people into the Mozillians emailer as it requires users to be vouched Mozillian in the Mozillians DB, so yeah, suggesting people join, I believe :beltzner is suggesting is the way to go.
Flags: needinfo?(bsimon)

Comment 14

5 years ago
Beltzner: There is no "Webmaker" list. We manage the Mozilla list, where we talk about all things Mozilla, including (and to be honest, predominantly) Webmaker and fundraising. That is separate from Mozillians and their list. It's a consumer/supporter list. 

The text for sign-up is something like "Get Mozilla Updates. We will only send you Mozilla-related information." On sign-up, we could segment them as Webmaker users in BSD, but starting a separate "webmaker mailing list" is a can of worms I'd rather not open.

We never do auto-opt-in. Ben is fluent in our procedures, but the basic principle is people know what they're getting into, and we declare what we'll use their information for up front.
Cool; Kate - please see comment 14 here and keep it in your brain case for when you're designing the sign up flow. Looks like the proposal in comment 9 is going forward, and from a UI perspective this will be an opt-*in* request at the point that we create a Webmaker account for someone, expressed as indicated in comment 14
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(cassie)
Flags: needinfo?(bsimon)
Resolution: --- → FIXED
Whiteboard: u=dev c=login p=1 → see comment 9 and comment 14 for decisions

Comment 16

5 years ago
Seems to be well-covered already, but what I think will likely make the most sense is 2 checkboxes (both unchecked):

1) 1, required, the says you agree to privacy policy and will get some webmaker system notifications
2) 1, not required, opting you in to receive Mozilla email updates (what Ryan describes in comment 14).
You need to log in before you can comment on or make changes to this bug.