SOLVED

We have over 1 million people in our DB - How do we implement an email preference center now?

Go to solution
Highlighted
Level 1

We have over 1 million people in our DB - How do we implement an email preference center now?

Hello!

We are implementing a Marketo Subscriber Preference Center - We created custom consent fields (type boolean), which are, by Marketo default, unchecked. Only when a person fills out the preference center form, these fields are checked (depends on the person's preferences). 

So we have 1 million existing people in our database with unchecked preferences that we can't segment by these preferences until they fill out this form. This means:

1. We can't differentiate between people that did not visit the preference center and those who did and opt-out of "Event Emails", for example.

2. We don't think it's a good idea to run a smart campaign to change the custom consent fields values to "true" since we have so many people in our DB. 

3. Using "not filled out preference center form" filter in every campaign can cause a long audience loading time, considering our database size.

 

What are your suggestions and how do you think we should go about it?

 

Thanks!

Itay

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Level 10 - Community Moderator

Re: We have over 1 million people in our DB - How do we implement an email preference center now?

The problem is you decided on an implementation that could never fit this need.

 

A Boolean is, as you know, a two-state field. You need a tri-state field: the equivalent in the raw database world of a nullable Boolean, where null represents "not populated" and true and false are both driven by end-user activity.  

 

Marketo doesn't have such a datatype. You would 2 Boolean fields to make this work: eventEmailOptIn for the value itself and hasEventEmailChoice to indicate whether the value was chosen by the end user, or whether it's still at the default. Or a single Integer field, where -1 is opted-out, 0 is unanswered, and 1 is opted-in.

 

But really such simple datatypes are wrong here to begin with, you'd be better off with DateTime. which can represent a far richer value: it represents not only the current value, but also when they last set that value, which is superior for reporting.  Two DateTimes can answer the complex question "Are they opted-in or opted-out, and when did they do so?".

 

2. We don't think it's a good idea to run a smart campaign to change the custom consent fields values to "true" since we have so many people in our DB. 

 It's fine to run a batch like that once (or better yet, split it into smaller batches, by letter of the alphabet is good enough). But it doesn't solve the underlying problem of having a non-representative datatype.

View solution in original post

2 REPLIES 2
Highlighted
Level 10 - Community Moderator

Re: We have over 1 million people in our DB - How do we implement an email preference center now?

The problem is you decided on an implementation that could never fit this need.

 

A Boolean is, as you know, a two-state field. You need a tri-state field: the equivalent in the raw database world of a nullable Boolean, where null represents "not populated" and true and false are both driven by end-user activity.  

 

Marketo doesn't have such a datatype. You would 2 Boolean fields to make this work: eventEmailOptIn for the value itself and hasEventEmailChoice to indicate whether the value was chosen by the end user, or whether it's still at the default. Or a single Integer field, where -1 is opted-out, 0 is unanswered, and 1 is opted-in.

 

But really such simple datatypes are wrong here to begin with, you'd be better off with DateTime. which can represent a far richer value: it represents not only the current value, but also when they last set that value, which is superior for reporting.  Two DateTimes can answer the complex question "Are they opted-in or opted-out, and when did they do so?".

 

2. We don't think it's a good idea to run a smart campaign to change the custom consent fields values to "true" since we have so many people in our DB. 

 It's fine to run a batch like that once (or better yet, split it into smaller batches, by letter of the alphabet is good enough). But it doesn't solve the underlying problem of having a non-representative datatype.

View solution in original post

Level 1

Re: We have over 1 million people in our DB - How do we implement an email preference center now?

@SanfordWhiteman Thank you so much! We eventually decided to use an "Opt-out {prefernce type name} DateTime is Empty" field. That way we don't have to worry about who is a subscriber but rather who did not opt-out (using DateTime field):

 Visited - Opt-OutVisited - Opt-InNot Visited - "Opt-In"
Subscription - EventsFALSEYesFALSE
Opt-In - Events [DateTime]EmptyYesEmpty
Opt-Out Events [DateTime]YesEmptyEmpty

 

We are, however, facing 2 other issues:

1. When a person chooses to fully unsubscribe from all emails and checks that designated checkbox, we would like the other checkboxes (of Events, Newsletter, etc) to be unchecked as well - What is the best way to do it?

2. After refreshing the page, it resets itself, meaning all preferences fields are checked as if the user did not change anything - Is there a way to fix that? We assumed the form's pre-fill takes care of that but it did not.

Here is the landing page - https://go.uopeople.edu/communication-preferences.html 

 

Thanks!