2

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:

enter image description here enter image description here

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:

  • [CENTRAL-SUBSCRIBER-TABLE] relates to subscriberkey on contactmodel
  • the PURCHASED_CLEANED.customer-number relates to customer-number from [CENTRAL-SUBSCRIBER-TABLE]
  • Every customer-number can have one to multiple subscribers.
  • The relationship is defined as ONE to ONE (in normal databases that would be wrong because you would have one to many here [just a foreign key]).

Below is a screenshot from the relationship: enter image description here

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.

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
0

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.

Improve this answer
2
  • It simplifies the condition in the journey which is nice but is not the answer for the issues i faced. But the answer helped to find the root cause which i will post soon.
    – Johannes Schapdick
    Commented Jun 25, 2019 at 7:08
  • It more than simplifies the condition, it's a much more correct way of applying that kind of condition. By essentially doing an INNER JOIN within a criteria step you're using the Journey Builder in way that it isn't designed for, which can cause all kinds of unwanted results. Joins like that should be managed within the Contact Model, or via a query to create a more meaningful Data Extension.
    – Rainer G
    Commented Jun 25, 2019 at 22:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .