1197326 - [FxA] Only send FxA's who opt in to email comms to Master_Subscribers

Status: RESOLVED WORKSFORME

(Websites :: Basket, defect)

Description

[Jessilyn Davis]

Goals: 

1) Keep Master_Subscribers in ExactTarget as clean and lean as possible as it's primary purpose is to keep up with email subscription opt-ins and outs.

2) Store Confirmed FxAccounts holders' email addresses so that we can email them Transactional/Relationship content if needed.


Problem: 
*All* Confirmed FxAccounts, whether or not they opt-into email, are added to Master_Subscribers. This is adding a lot of rows of data daily that are not email subscribers. More rows of data in Master_Subscribers = a bigger table = longer times to complete queries and filters = timeouts in ET = timeouts for web properties that rely on information to be available in ET (ie Email signup forms, Email Preference Center). (A la Bug 1179496)

Potential Solution:
* For confirmed FxA's that do NOT opt into email - add to new "Firefox_Account_Holders" Data Extension.
* For confirmed FxA's that opt-into email - keep handling as we do at present - and - add them to "Firefox_Account_Holders" Data Extension.


This solution would achieve the goals; however, one consideration is that Basket will need to check Firefox_Account_Holders data extension (after checking Master_Subscribers) to see if a new email subscriber exists there *before* creating a new TOKEN and adding the contact to Double_Opt_In (or Master_Subscribers if Double_Opt_In is turned off for the particular email subscription). This will avoid having the same email address, with 2 different tokens.

Another way to solve for this could be to *not* assign a TOKEN to FxAs who confirm their account, but have not opt-ed into email.

This needs to be spec'ed out and talked through a bit more - especially as we try to expand the ability for FxA holders to opt-into email from their Accounts Setting page (which means a token may need to be present in Master_Subscribers)

Comment 1

[Ryan Kelly [:rfkelly]]

> Another way to solve for this could be to *not* assign a TOKEN to FxAs who confirm their account,
> but have not opt-ed into email.

This sounds like the simplest option, and IIUC we can implement it entirely from the FxA side - just stop sending over new FxA users unless they've explicitly opted in.  We have everything in place to bootstrap them into existence in basket if/when they decide to opt in at a later date.  What do you think?

Comment 2

[Jessilyn Davis]

(In reply to Ryan Kelly [:rfkelly] from comment #1)
> > Another way to solve for this could be to *not* assign a TOKEN to FxAs who confirm their account,
> > but have not opt-ed into email.
> 
> This sounds like the simplest option, and IIUC we can implement it entirely
> from the FxA side - just stop sending over new FxA users unless they've
> explicitly opted in.  We have everything in place to bootstrap them into
> existence in basket if/when they decide to opt in at a later date.  What do
> you think?

Thanks Ryan! I think that this proposal solves one part of the equation, but one gap that it would create is the ability to see if any/all of our email subscribers have a Firefox Account (outside of the FxA email opt-in; ie, if they signed up to get Foundation news, Firefox Student Ambassadors, etc.).

Comment 3

[Ryan Kelly [:rfkelly]]

> one gap that it would create is the ability to see if any/all of our email subscribers have a Firefox Account

Do we use that ability in practice?

I'm happy to keep sending over all new FxA accounts if it's providing value, but if not then I'd be keen to stop doing it and save both FxA and Basket the hassle.

Comment 4

[Jessilyn Davis]

At present, no; but in the not-so-distant-future, yes.

I'm going to be doing a data audit and account deep-dive with our ExactTarget (er SalesForce Marketing Cloud) Reps in the next week to talk current setup and how to set up for scale and success. I have this on the list of items to talk through with them. More to come soon.

Comment 5

[Jessilyn Davis]

Handling this a different way as part of Bug 1259483