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:
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
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
0 Asked on December 12, 2021 by anubhuti
1 Asked on December 12, 2021 by rachit
3 Asked on December 12, 2021
1 Asked on December 12, 2021
2 Asked on December 12, 2021 by balwill
1 Asked on December 10, 2021 by jetsparx
2 Asked on December 10, 2021
2 Asked on December 10, 2021 by eduardo-lpez
0 Asked on December 10, 2021 by jonathanwiesel
2 Asked on December 7, 2021 by nemesis88
1 Asked on December 7, 2021 by nicstella
1 Asked on December 7, 2021 by sanchit
3 Asked on December 7, 2021
1 Asked on December 7, 2021 by gaurav-sharma
1 Asked on December 7, 2021 by sfdc-devloper
Get help from others!