Currently, we use Subscriber key= Email Address = Contact Key;
We are planning to use Salesforce Contact ID as Subscriber key/ContactKey. Is there a way to mass update Subscriber key value for all our current Subscribers (we have around 250k subscribers)? Also, will we lose all the tracking data about our subscribers? We are mostly concerned about Einstein Optimization data, but we are not sure if Einstein tracks and stores the data based on the Subscriber Key or email address?
[SalesForce] Updating Subscriber(Contact) key in Marketing Cloud
Related Solutions
It depends on what data is contained in your SubscriberKey. The SubscriberKey is how SFMC keeps track of a Subscriber's status. In most cases it's the email address, but if you have any kind of integration (e.g. Marketing Cloud Connect), the SubscriberKeys are typically not email addresses.
To configure a sendable DE, you'll have to define the relationship of the DE data to All Subscribers so the status can be maintained. You don't need both email address and SubscriberKey if your SubscriberKey is email addresses. If they're different, I recommend having both.
Primary Key is to define uniqueness of a row, so no two rows can have the Email Address + SubscriberKey combination, then those two fields should be set as Primary Key.
If you want to use a Query Activity to update a Data Extension, you'll need to define the Primary Key fields.
Yes this is frustrating but "expected behavior".
It's not unique to importing Salesforce records either. If you have a Sendable Data Extension and complete a Guided Send Email, then repeat this again at a later date with updated email addresses in the in the Sendable DE, the emails will be sent to the previous Subscriber. The email address in the Sendable DE is only used when the Subscriber Record is initially created.
Salesforce assume all subscribers are using the built-in profile centre to update their email address. But this is often not the case.
The solution isn't great, but its really the only way around this. You will need to create a Scheduled Automation in Automation Studio that runs at a regular interval (e.g. daily) and performs the following tasks:
- SQL Query Activity to identify updated email addresses from your Salesforce DE
- Export Target DE from Query Activity to Enhanced FTP Account using File Transfer Activity
- Import the file exported in step 2 to the All Subscribers list using Import File Activity (refer to screenshot below)
Best Answer
What you are looking into is a so-called Subscriber Key migration. A task which can't be done within the UI, and requires a paid services engagement by Salesforce. It will basically update the database, replacing the old Subscriber Keys with new ones, based on a SubscriberKey Data Extension containing the following fields:
The data MUST be validated
So you will want to have your email addresses in the OldSubKey column and your Salesforce IDs in NewSubKey column.
All OldSubkey values should exist in the Subscriber table. If any OldSubkey is not in the Subscriber table, then those OldSubkey values will not be included in the migration.
If a subscriber is NOT included in the mapping DE, there will be no update applied to the subscriber. The process will migrate only what exists in the mapping DE.
This is relatively easy. What makes the task more complex is the fact that you CANNOT send during the migration process. Sending includes both Batch Sends and Triggered Sends. You must ensure your API calls are halted and that the Triggered Send queue is cleared and then paused on the Marketing Cloud side.
Once all of the above has been completed SFMC Services in the US will need to be engaged to carry out and oversee the actual migration.
To avoid having legacy Subscriber Keys appear in Marketing Cloud, it is essential to ensure the Sales Cloud becomes single source of consumer identity and other systems should no longer provide data which in any way reference the legacy Subscriber Key, being the email address.
Subscriber Key migration will indeed carry engagement over from the old Sub Key to the new ones, which applies to both clicks/opens, and Einstein engagement. Most of the clients I work with accept the fact of the engagement data being lost, as the impact of the Subscriber Key migration on their business continuity is seen as too significant - as downtime of approx 24 hours should be expected. They just create new subscribers with new Subscriber Key value, and perform contact deletion on the old records.