Salesforce Asked by Johannes Schapdick on November 8, 2020
I recently discovered a very odd mechanic inside the journey builder when it comes to decision splits and i am uncertain how to solve this issue. The example journey:
What i want to do is the following:
I got a decision split inside a journey that should route contacts that bought something into a different path than those that did not buy something.
To make this possible I created two DataExtensions which I connected to the contactmodel via datadesigner. Some Aspects:
Below is a screenshot from the relationship:
Since I wanted to remove any complex aspects I created a query that cleans all the real purchases dataextension from customers that only the latest purchase of a customer remains. The result is inside [PURCHASED_CLEANED]
Now lets come to the odd stuff:
I defined the decision split like Journey-DataExension customer-number
compares to attribute [PURCHASE_CLEANED].customer-number
. If is this is true the contact counts as “has bought” in the following UpdateContact Activity, if not he counts as “has not bought”.
It works for most of the contacts but there is one standing out. Although he has ONE record in the PURCHASE_CLEANED dataextension he counts as “has not bought”.
I watched on the dataextensions involved and the subscriber model, this contact is similar/equal to the other ones. Except for the following fact: The purchase dataextension (not the cleaned) has two purchases for this contact and every other customer has only one(test dataset). Only one gets transferred to the PURCHASE_CLEANED dataextension though (and i am 100% certain this works correct- I use a select with a another select that uses rownumber and partition by and i only get the first rownumber, with descending eventdate on purchases).
Do you have ANY idea why this particular contact would count as “has
not bought”, while it works on all other contacts?
Input Dataextension:
Subscriber|customer-number
100|111
101|111
102|111
201|222
202|222
203|222
304|333
PURCHASE:
purchase-id|customer-number|eventdate (i leave the values out here)
1|111|...
2|111|...
3|222|...
PURCHASE_CLEANED:
purchase-id|customer-number|eventdate (i leave the values out here)
2|111|...
3|222|...
Output:
subscriber | datasplit-string
100|"has not bought"
101|"has not bought"
102|"has not bought"
201|"has bought"
202|"has bought"
203|"has bought"
304|"has not bought"
Another really questionable thing: Why does the comparison only works in the following direction:
Compare JourneyData-Attribute to DataDesigner-Dataextension-Attribute
and not
Compare DataDesigner-Dataextension-Attribute to Journey-Attribute
The Output with DataDesigner-Dataextension to Journey-Attribute:
subscriber | datasplit-string
100|"has bought"
101|"has bought"
102|"has bought"
201|"has not bought"
202|"has not bought"
203|"has not bought"
304|"has bought"
When I do this it also inverts the outcome of the decision splits that all contacts who bought, now count as “has not bought” and everyone else (and the odd one) count as “has bought”. I really do not understand this behaviour.
Journey History for this history does not deliver any deeper insight.
The reason why i experienced this behaviour was a missing contact inside the central-subscriber-table. The Journey-DataExtension had a contact which was not inside our subscribers but who bought something (it is intended that he was not inside the contacts).
Therefore the journey was not able to find the records inside the central-subscriber-table and therefore this record could not be referenced in the purchase-cleaned dataextension. Thats why these records (in the example 101-103
) were shown as has not bought.
The thing I still do not understand is the inversion when you compare the PURCHASE_CLEANED.customer-number to Journey-Data.customer-number instead the other way round.
Answered by Johannes Schapdick on November 8, 2020
The Attribute comparison function in a Decision Split is meant for comparing dynamic values within your data model, like BALANCE < CREDIT_LIMIT. You've already established the relationship between the two tables in the Contact Model, there's no need to do it again in the Journey (which is what you're effectively doing).
Have you tried simply making the Decision Split criteria 'PURCHASED_CLEANED.customer-number IS NOT NULL'?
All customer-number records from your Entry Source Data Extension that have a record in the PURCHASED_CLEANED table should meet this criteria, and go down the correct path.
Answered by Rainer G on November 8, 2020
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP