Home/Blog/Salesforce Marketing Cloud
Salesforce Marketing Cloud

A Subscriber Key Saga

8 min read

What happens when two teams inside the same company use different Subscriber Key strategies in Salesforce Marketing Cloud? Meet Jane — and Mega Marketing.

Mega Marketing

Mega Marketing sends a welcome email with an initial offer when individuals sign up for their mailing list and a monthly offer thereafter. Unfortunately, there are 2 different Data Extensions and processes used for the emails because there are different teams associated. The Welcome Email uses Data Extension A. This DE has the subscriber key relationship based upon Contact Id (Sales Cloud). The Offer Email uses Data Extension B. Data Extension B has the subscriber key relationship based upon Email Address.

Jane

Jane submits a form on the Mega Marketing website to join a new marketing program on January 1st with an email of [email protected]. She is assigned a ContactId of 12345. Attempts were made to welcome her using a DE that used ContactId as Subscriber Key. Her email address was misspelled so emails bounced repeatedly until her record in ALL SUBS went into a HELD state. A month later, Jane still hadn't received an email so goes back to the form to sign up again. She still didn't receive emails.

What Happened?

January 1 — Jane is added to Data Extension A

Data Extension A relates SubscriberKey to ContactId and the email is sent using the Email Send Flow.

Jane does not exist in ALL SUBS with a Subscriber Key of 12345 so an email is attempted and Record A is created in ALL SUBS on 1/1 with subscriber key as 12345 and email of [email protected].

Jane does not get an email because it bounces due to the incorrect email address.

After 3 times in 15 days, her status in ALL SUBS for Record A is HELD.

February 1 — Jane becomes eligible for Monthly promotions and is added to Data Extension B

Data Extension B relates SubscriberKey to Email Address and the emails are sent using Automation Studio Email Send Activities.

Jane does not exist in ALL SUBS with a subscriber key of [email protected] so an email is attempted and Record B is created with a subscriberkey of [email protected].

This email also bounces and Record B also eventually goes into a HELD state.

February 10 — Jane notices she never received emails and goes back to the form

This time she correctly spells her email address. Mega Marketing has a process in place that can properly update her existing Contact Id with the corrected email address. Alternatively, Jane may have also called into the call center who recognized the email address issue and corrected it in Sales Cloud.

February 11 — Jane is added to Data Extension A again

There is no process in place to update Jane's email to [email protected] in SFMC so her ALL SUBS (Record A) still shows an email of [email protected].

The email attempts to lookup her Subscriber Key based upon her Contact Id and finds a match in ALL SUBS (Record A).

The email is not attempted because Record A (Subscriber Key of 12345) is in a HELD state.

March 11 — Jane is added to Data Extension B for monthly promotions

Jane exists in ALL SUBS as a subscriber key of [email protected] (Record B) based on the attempted Monthly Offer send on 2/1.

The email is not attempted because Record B (Subscriber Key of [email protected]) is in a HELD state.

March 15 — Jane calls back. Mega Marketing reaches out to Salesforce support.

Salesforce instructed them to update the All Subscribers record with the correct email address.

They also suggested switching to a model based on ContactId instead of Email Address for Subscriber Key — better for Journey Builder and allows opens/clicks to pass back to Sales Cloud. However, Mega Marketing has been a customer for a long time and the majority of their subscribers have a subscriber key based upon email address. They are not prepared to suddenly switch everything over to Contact Id as this would require a Subscriber Key migration that can only be completed by Salesforce Professional Services.

Mega Marketing does not want to switch but doesn't know how to get emails out to Jane and others like her otherwise.

How Does This Saga End?

Well... for as long as there is inconsistency with regard to how Subscriber Key is related between different data extensions, not so well. But there are a few options to consider to stop the bleeding.

Option 1

Option 1 — Subscriber Key Migration

Request a subscriber key migration with Salesforce Services and begin setting up all Data Extensions to relate the subscriberkey relationship to Contact Id instead of Email Address. In addition, setup automations to sync email address updates in Sales Cloud to ALL SUBS in Marketing Cloud. While costly, it assures resolution before the same problem is inherited by others in the future.

Option 2

Option 2 — Adjust Data Extension A

Adjust Data Extension A to relate the Subscriber Key for Data Extension A to be based upon Email Address instead of Contact Id and add Jane back to Data Extension A with her correct email.

Add Jane back to Data Extension A with her Email Address of [email protected] and ContactId of 12345. There will not be a current record in ALL SUBS for this subscriber key of [email protected] yet.

The email will be sent to [email protected] and a new record will be added to ALL SUBS (Record C - Subscriber Key of [email protected]).

Jane now counts as 3 contacts against the overall contact counts. Record A and B will have a status of HELD. Record C will have a status of ACTIVE. Since the promo emails are also based upon Email Address, an additional record is not created — the system recognizes that there is a subscriber key of [email protected] that already exists and uses this.

⚠ Caution:AHEAD OF MAKING THE EDIT, Mega Marketing needs to look at ALL SUBS to determine if anyone that will go into Data Extension A already has a record in ALL SUBS that uses ContactId as subscriber key and that has an email that matches what is in Data Extension A. If those records are either UNSUBSCRIBED or HELD, you wouldn't want the system to create a new ALL SUBS record that is now based on Email Address instead because the status is reset to ACTIVE and those people may not want to be emailed (or are HELD).

Option 3

Option 3 — Update ALL SUBS Records Directly

Update Jane's record in ALL SUBS (and anyone else who has the same issue).

If updating a group, this can be accomplished by importing a list of SubscriberKey, email address, and status directly to ALL SUBS or via automation.

The status may also need to be reset but should also be done with caution by first checking to see if there are any records in ALL SUBS that use the most up to date email ([email protected]) and have a status of HELD or UNSUBSCRIBED. You wouldn't want to update a status to ACTIVE if the email address was associated with 1 or more other records that had a status of HELD or UNSUBSCRIBED.

Dealing with Subscriber Key Inconsistencies?

Subscriber key mismatches are one of the most common — and most painful — data problems in SFMC. Light Your Fires can help you audit your setup and build a path forward.

Let's Talk