My scenario is :- I have a person account(Member) stored in data extension with ContactId as the Subscriber key. I have another data extension(Product Interest DE) that stores the products that every contact is interested in(One member can have multiple product interest). Currently, for this data extension, I have set the Subscriber key as ContactId and ContactId as the Contact Key.
I am facing two problems when I use this data extension in journey with decision split:-
-
Contacts that have multiple records in the Product Interest DE do not follow the appropriate path in the decision split. The moment the system find a contact with multiple records, it pushes that contact in the remainder path of the decision split.
-
Suppose there are 10 records with 9 unique contactIds in the data extension. Journey entry source only considers 9 contacts instead of 10 records.
Workaround:- I raised a case with Salesforce and they replied I should use a unique identifier as the ContactId or filter the data extension such that there are only unique contacts. Hence, in the Product Interest DE, I have created Id(Primary key of the DE) as the Subscriber Key and again "Id" as the Contact Key.
Question:- Is the above workaround correct? will this affect the tracking data for the subscribers.
Best Answer
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: