Subscriber Key: An Email Studio attribute that is used as a unique identifier for contacts records. Has a one to one relationship with subcribers and is immutable (cannot be changed once set). This is a user defined property
Subscriber ID: Similar to Subscriber Key, it is a used in the backend and is not visible unless through queries or APIs. This is set by the system
Contact Key : A Contact Builder attribute that is used as a unique identifier for the contact model, and other models (Journey Builder) except Email Studio. **This is a user defined **.
Contact ID: Analogous to Subscriber ID
So it is possible to have a different contact key and subscriber key as they are unique identifiers for different modules.
I would see subscribers as contact details of in email studio, and "person" as contacts.
Therefore Subscriber IS A MEMBER OF Person.
Primary Key: Used within data extension as a unique identifier WITHIN THE DATA EXTENSION. Data extension as used to store data within marketing cloud (regardless of which application), and enforce Relationship Database rules, like any traditional SQL based database.
Example Scenario:
You have a new contact (John) added to your SFMC instance. You want to communicate with John through a lifecycle campaign that includes email with journey builder.
To do this , John will have to be added to Contact Builder. When you add him as a contact , you set the "Contact Key". As the same time the system generates a "Contact ID" for him. Now the system can view him as a contact through the data model, and through this contact key relate him to other applications / attributes within Marketing cloud. But we are unable to send him email as he doesnt exist as an email studio "subscriber". To this this, he has to be added to email studio. When this happens , we set a " Subscriber Key" and the system generates a "Subscriber ID".
Now the system recognises John as a contact (Contact Key) , and an email subscriber (Subscriber Key)
Hope this makes sense.
Answers to Questions in Comment
- Question::PART 1 John exists in SF as a person account with the ID 123XYZ , this ID is then used as the contact key in Data Designer. So the Contact Key for John will be 123XYZ? As John is new and has not been added before he will also get a MC system generated Contact ID of say 456ABC. This then links together in Contact Builder all of the information that relates to John using the above ID's
Answer Spot on . This is correct
Question John then meets the criteria of 2 email and 1 text message Journeys. John is entered into the email Journey 1 with email Family.Smith@email.com this generates a subscriber Key of 123XYZ as the SF ID has been set as my Subscriber Key. John is then entered into the Text journey with the same email and a tel of 12345 678 678. This then attaches his text interaction using the same Subscriber Key? John is sent Email 2 and the same subscriber Key is used? When a subscriber Key is created so is a Subscriber ID lets say 999ZZZ
- Answer: Partially correct. The Subscriber Key is a user defined attribute (i.e You create the value). It is best practice to use the same values as the Contact Key. With issue of text, Mobile Connect works slightly different. It will use the Subscriber ID for the back end to send these message. You have to import you mobile demographics and set long/ short codes for your message. But yes, using a combination of Subscriber Keys, subscriber ID and Contact Key, all the above interactions are mapped to John.]
Update:
Except from the official docs:
Understand the Differences Between Contact ID and Subscriber ID versus Contact Key and Subscriber Key These system fields do not
serve the same purpose in a Marketing Cloud account. Most customers
use a primary identifier for their customers, in which case they link
their identifier to Marketing Cloud using the Marketing Cloud Contact
Key or Subscriber Key values.
The Contact ID and Subscriber ID fields act are surrogate keys used by
internal Marketing Cloud systems. You can see these fields in tracking
extracts and system data views in Query Activities. However, don't use
these values for Marketing Cloud activities to avoid performance
issues.
Resources
As the Subscriber Key should be unique per subscriber/user/contact and not per journey entry this workaround isn't a good one in my opinion. With this workaround you would have multiple records for the same contact in your All Subscribers list.
I rather suggest fixing this problem on the journey level. However, the solution depends on the way your journey is triggered. If you use an API-event you could exchange the API-event for a custom built API event with transaction key. In order to put this into place, you need an ID (primary key) in the data extension that is unique to the row (could be a random uuid for example).
If you don't use an API-triggered journey, you need to go with another solution. The unique ID part remains the same, however you need to build a custom decision split activity, that gets the unique ID as input parameter. The custom split backend then queries the data extension (using the ID from this very journey entry) and returns the expected result.
As such use cases (1:n relationships) weren't considered when implementing the decision split functionality quite a bit of development effort is necessary in order to get this to work. Fortunately I already needed both workarounds and released example implementations on my github account.
Code examples:
(Please note that the split activity needs to be adapted as my example reads data from Salesforce Service Cloud and according to your description you need to read a Salesforce Marketing Cloud data extension instead)
Further resources:
Best Answer
Your Contact Key in _Subscribers is SubscriberKey
Your Contact ID in _Subscribers is SubscriberID
Your Contact Key in _MobileAddress should be _ContactKey
Are you looking to build your own related data views? What other data are you trying to relate?