Page MenuHomePhabricator

Investigation: Create Preference Center for donors to manage email subscription preferences
Open, NormalPublic

Description

New spec:
https://docs.google.com/document/d/1wKtGxJn06bs6OGAFV7DKUfVw2salKdU_NAUn5SMGks0/edit#

Definition of done for investigation:

  • take a look at the spec
  • Summarize approach and list rough tasks to be created on this phab (don't make them yet)
  • have a check in meeting with @DStrine and @CCogdill_WMF to review approach
  • Have a discussion with the team for an overall estimate

Extremely old information:

I met with the Mozilla team a couple of months ago and found out they built their own email subscription preference center. In the past, consultants had estimated building one of these would cost us upwards of $1m, but the Mozilla folks that was gross hyperbole.

One of Mozilla's devs sent me these awesome notes with github links included. He said we are free to email or bug him on IRC if needed, but I'm leaving his contact info out of phab. Can we scope this and see if it's doable? This could be huge for both me and @CaitVirtue:

NOTES FROM MOZILLA
The email preference center is in the bedrock codebase[0] on github (links below), which is built using the Django[1] framework. As written it requires our basket[2] service for the newsletters and subscription data, as well as updating user prefs. Basket is basically a proxy to our email marketing provider (currently Exact Target, a.k.a. SalesForce Marketing Cloud I think).

[0] https://github.com/mozilla/bedrock/
[1] https://www.djangoproject.com/
[2] https://github.com/mozilla/basket/

Email Pref Center Code:

View

https://github.com/mozilla/bedrock/blob/master/bedrock/newsletter/views.py#L247-L459

Forms

https://github.com/mozilla/bedrock/blob/master/bedrock/newsletter/forms.py#L119-L216

Note: The view imports "basket", which is our python client library for interacting with the basket.mozilla.org service. The source for that is here:

https://github.com/mozilla/basket-client

Event Timeline

CCogdill_WMF raised the priority of this task from to Low.
CCogdill_WMF updated the task description. (Show Details)
CCogdill_WMF added subscribers: CCogdill_WMF, CaitVirtue.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 30 2016, 12:11 AM

@CCogdill_WMF I just jumped up and down and clapped. Literally.

DStrine renamed this task from Create Preference Center for donors to manage email subscription preferences to [EPIC] Create Preference Center for donors to manage email subscription preferences.Feb 2 2016, 8:15 PM
DStrine added a project: Epic.
DStrine set Security to None.
DStrine moved this task from Triage to Sprint -- on the Fundraising-Backlog board.
DStrine moved this task from Sprint -- to Q1 (July-Sept) 2019-20 on the Fundraising-Backlog board.
MBeat33 added a subscriber: MBeat33.Jul 3 2019, 2:46 PM

@jrobell @Ppena @CCogdill_WMF This is a massive change that might not be doable in the foreseeable future. Depending on scope it might be more than an annual plan goal. We'd need a few meetings to understand your expectations here.

Cool, when would it make sense to discuss this further? Happy to outline
our expectations and see what might work within the constraints of our
system.

Ejegg added a subscriber: Ejegg.Jul 19 2019, 5:00 PM

So this is the form at https://www.mozilla.org/en-US/newsletter/ ?

That looks a lot like our opt-in form, plus HTML/text and country/language preferences. Would we want to add those to the opt-in form?

CCogdill_WMF added a comment.EditedJul 19 2019, 5:02 PM

Here it is! https://www.mozilla.org/en-US/newsletter/existing/8813b665-cfa8-495b-ada5-9c0a9c011522/. Feel free to play with my preferences if you want--I'm opted into this list with multiple email addresses 🤓

Spec doc for the preference center here: https://docs.google.com/document/d/1wKtGxJn06bs6OGAFV7DKUfVw2salKdU_NAUn5SMGks0/edit#

@DStrine can you update the task description accordingly? And feedback most welcome on the presentation of this info!

@NNichols @MBeat33 @kaythaney @LeanneS I'd love any of your thoughts on this as well. Any ideas of what could be missing here? Suggestions for preference types? Think it over! Please add in suggestion mode or make comments. Thanks!

DStrine renamed this task from [EPIC] Create Preference Center for donors to manage email subscription preferences to Investigation: Create Preference Center for donors to manage email subscription preferences.Tue, Aug 6, 7:36 PM
DStrine raised the priority of this task from Low to Normal.
DStrine updated the task description. (Show Details)
DStrine updated the task description. (Show Details)Tue, Aug 6, 7:55 PM

@XenoRyet are you taking a look at this? @Ejegg thought he remembered you saying you might.

mepps added a comment.EditedWed, Aug 14, 6:54 PM

Note definition of done, with Phab tasks listed, but not created.

@mepps Yea, this is on my list. Sick kids have kept me from getting too far yet, but I believe the plan for this sprint was to do enough investigation to scope it out, decide on an approach, and see where we'd want to slot it into the schedule.

Possible tasks:

Finish decommissioning old unsubscribe and move that functionality to the new system

  • Should really get this squared away before we start expanding the system.

Create the preferences center form

  • We can use opt-in as a start, but this one will obviously be more complex.
  • Seems like we're ok with the non-public link and contact ID plus hash being secure enough, can borrow that logic from opt-in as well.
  • Will need some front end design work.

Create the queue consumer to get the data to civi

  • This bit should be fairly straightforward as long as we nail down the form and the civi DB changes first.

Civi database changes

  • New fields will be needed to provide this level of granularity
  • Current functionality of the opt-in and unsub fields will probably need rethinking and reworking. Do those fields override fine grain preferences or not?

Civi UI changes

  • This data will need to be displayed in civi, and could pretty quickly get cluttered. We'll need UI changes if we want to do more than just cram this all in the communications section.

IBM export changes, possibly more IBM work

  • The export will need to accommodate the new data by having a seperate file for each kind of preference.
  • Also might require a seperate file for donors opting in to specific lists, rather than opting out if we go for that functionality. I think we should.
  • This might end up being a near total rewrite of the exporter.
  • Changes to the import process on the IBM side. This seems like the bit with the most unknowns.
  • Possible other IMB work to properly make use of these new fields.

Create a button in civi to generate links.

  • Nice to have, but shouldn't be too hard.

Create variants on the preferences form

  • Not necessary for minimum viable product, but probably necessary before too long.

Thanks for scoping this out, @XenoRyet, seems like a pretty thorough
approach to me!

For the front-end design work required, sh ok old we have our designers get
working on that, or wait until we have some sort of prototype to work with?
I could see it going either way and mostly want to prevent us designing
something that feels hard to implement. If that doesn't feel like a concern
to you, we can start putting something together soon.
Le mar. 20 août 2019 à 1:49 AM, XenoRyet <no-reply@phabricator.wikimedia.org>
a écrit :

XenoRyet added a comment. View Task
https://phabricator.wikimedia.org/T125272
Possible tasks:
Finish decommissioning old unsubscribe and move that functionality to the
new system

  • Should really get this squared away before we start expanding the system.

Create the preferences center form

  • We can use opt-in as a start, but this one will obviously be more complex.
  • Seems like we're ok with the non-public link and contact ID plus hash being secure enough, can borrow that logic from opt-in as well.
  • Will need some front end design work.

Create the queue consumer to get the data to civi

  • This bit should be fairly straightforward as long as we nail down the form and the civi DB changes first.

Civi database changes

  • New fields will be needed to provide this level of granularity
  • Current functionality of the opt-in and unsub fields will probably need rethinking and reworking. Do those fields override fine grain preferences or not?

Civi UI changes

  • This data will need to be displayed in civi, and could pretty quickly get cluttered. We'll need UI changes if we want to do more than just cram this all in the communications section.

IBM export changes, possibly more IBM work

  • The export will need to accommodate the new data by having a seperate file for each kind of preference.
  • Also might require a seperate file for donors opting in to specific lists, rather than opting out if we go for that functionality. I think we should.
  • This might end up being a near total rewrite of the exporter.
  • Changes to the import process on the IBM side. This seems like the bit with the most unknowns.
  • Possible other IMB work to properly make use of these new fields.

Create a button in civi to generate links.

  • Nice to have, but shouldn't be too hard.

Create variants on the preferences form

  • Not necessary for minimum viable product, but probably necessary before too long.

*TASK DETAIL*
https://phabricator.wikimedia.org/T125272
*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
*To: *XenoRyet
*Cc: *mepps, XenoRyet, LeanneS, NNichols, kaythaney, Ejegg, DStrine,
jrobell, Ppena, MBeat33, spatton, CaitVirtue, CCogdill_WMF, Aklapper,
EBjune, Dinoguy1000

DStrine moved this task from Current Sprint to Sprint -- on the Fundraising-Backlog board.

I pulled this out of the sprint due to availability of some people and the fact that we're not actually working on this right away. I'll schedule a meeting about this in September.