Page MenuHomePhabricator

Epic: Create Preference Center for donors to manage email subscription preferences
Open, MediumPublic

Description

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

CiviCrm email settings described:
https://m.mediawiki.org/wiki/Fundraising_tech/CiviCRM

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

Design

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
ResolvedNone
ResolvedNone
Resolvedjgleeson
OpenNone
ResolvedAndyRussG
ResolvedNone
ResolvedJgreen
ResolvedDwisehaupt
ResolvedAndyRussG
ResolvedAndyRussG
ResolvedDwisehaupt
Resolvedjgleeson
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedDwisehaupt
ResolvedDwisehaupt
ResolvedDwisehaupt
ResolvedDwisehaupt
ResolvedDwisehaupt

Event Timeline

CCogdill_WMF raised the priority of this task from to Low.
CCogdill_WMF updated the task description. (Show Details)

@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.

@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.

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?

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.Aug 6 2019, 7:36 PM
DStrine raised the priority of this task from Low to Medium.
DStrine updated the task description. (Show Details)

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

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

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.

I would also like to point out that we have mapped all the communication fields in civi here:
https://www.mediawiki.org/wiki/Fundraising_tech/CiviCRM

per: T227498

This should help us decide what to expose to a user on the preferences page.

One nice-to-have on a preferences page:

  • Do you prefer in emails to be addressed formally (Dear Mr. Smith), or by your first name (Dear John)?

Email sends pulling this data would be a nice customization to please the more formal of our donors.

The task list from @XenoRyet looks pretty good!

Regarding the way to store the mailing list subscriptions in Civi: the standard way to do it is to create groups, but for our DB those might have too much overhead.

Before we start doing a mountain of work, should we review the reasons we think it's impossible to show donors their existing subscriptions? I know I'd be a little frustrated to get to a form showing multiple email lists and not be shown which of them I'm actually on.

I added a current use case to the Preference Center spec document:

(donor 741442) “I will continue to support Wikipedia, which I admire very much. But I am NOT interested in making a legacy gift. Please would you correct your list of prospects for such gifts accordingly.” This is from a test email before April 2020’s 3MIL Planned Giving outreach send.

The big Planned Giving outreach email in April will likely generate many more cases where having this feature would be helpful.

@DStrine Is this phab the right one to get updates on the preference center status?

DStrine renamed this task from Investigation: Create Preference Center for donors to manage email subscription preferences to Epic: Create Preference Center for donors to manage email subscription preferences.Apr 29 2020, 8:38 PM

@MSuijkerbuijk_WMF yes, welcome! :)

@DStrine We had a call with MG&E team yesterday, and seems like we need to first clarify if the option of having a separate version of the preference center for Major Gifts would be doable or not. That'll guide their specs and briefing of preferences. Would you be able to let us know about that?
Thanks!

Checked in with David and Dylan today and bumped Mariana's question above
re: hosting multiple versions of the form for small dollar and major
donors. Dylan said fr-tech was aware this was a desired feature and are
hoping to be able to support it. fr-creative will proceed assuming we can
maintain multiple versions of the form, and fr-tech will let us know if
that changes.

Change 690053 had a related patch set uploaded (by Dwisehaupt; author: Dwisehaupt):

[operations/puppet@production] Monitor services for new donor_prefs flow

https://gerrit.wikimedia.org/r/690053

Change 690053 merged by Jgreen:

[operations/puppet@production] Monitor services for new donor_prefs flow

https://gerrit.wikimedia.org/r/690053