We have over 1 million people in our DB - How do we implement an email preference center now? | Community
Skip to main content
Itay-2
Itay-2
New Participant
April 13, 2020
Solved

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

  • April 13, 2020
  • 1 reply
  • 3791 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

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.

1 reply

SanfordWhiteman
SanfordWhitemanAccepted solution
New Participant
April 13, 2020

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.

    Itay-2
    Itay-2Author
    New Participant
    April 22, 2020

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

     

    Terms & ConditionsAccessibility statement

    Loading footer...