Glad you made progress! Looking good! Yes, the diagram automatically adjust visible node values based on the space available. Since thinner paths don't provide enough room to display a value - the graph hides these. I'm not aware to have this behaviour changed at this stage. You can however see values by hovering over to see the tooltip or by looking at the detail table view (top right corner has a button for this). The detail table also has a nice behaviour to have the row selected of the current selected path. Yes, since path analysis is only available within Explorer any consumers would need to open the exploration. The easiest way to share the information would be to send out a link to your exploration (you can use the File-Email option which generates the link for you). Hope this helps. Regards, Falko ... View more

In regards to your questions: In the below diagram, what's causing the Green 'Ordered' & the Red 'Ordered' paths to merge when they have different Sequence dates? [Falko] These are merged because both 'Ordered' events are the 3rd event in each sequence of events (or 3rd step in a path). Well, now you may say - but 'Ordered' is not the 3rd in the red path. Problem here is the duplicate sequence value and related problem of path analysis not able to determine which comes first. See my answer for your last question below. Also I notice that the Blue 'Existing' & the Green 'Existing' have merged but they have different sequence dates too? [Falko] Same as before both 'Existing' events are the 4th step in each path and hence merged. Also same problem as before - your blue path has a duplicate sequence value for 'Existing' and 'Cancelled' and as such may appear in a wrong order. The order of the Red path Events has also changed from the table compared to the diagram 'New' >> 'Ordered' >> 'Complained' has become 'New' >> 'Complained' >> 'Ordered' in the diagram. - I assume the diagram can make changes of the events if the dates are the same for that Trans_ID? [Falko] Does the diagram show you a warning about 'artificial sequence orders' at the bottom? I would suspect so - since you have duplicate sequence dates within a single transaction. That means the path analysis algorithm can't determine which event occurred before the other potentially resulting in unexpected paths generated. This would also explain why you see the wrong order of 'Ordered->Complained' vs 'Complained->Ordered'. Cheers, Falko ... View more

No, It's just the sequence of events. The time/sequence is just required to keep events (within a transaction) in order. ... View more

Well, it's more about the sequence of events which must be the same in order to have paths merged. The transaction ID is just used to differentiate between these sequences (for every customer visit you would get a new transaction ID in your example). Let's take the last transaction of my previous example (ID: 207). You will notice the weight is 5 - indicating we have 5 customers who took this particular path. Alternatively in using a weight - you could just use the frequency and represent the same using the following. This is likely a common scenario in transactional data since every customer is traced a single entity. ID EVENT TIME CUSTOMER_ID 207 CANCELLED 100 1 207 ORDERED 101 1 207 CANCELLED 102 1 208 CANCELLED 100 2 208 ORDERED 101 2 208 CANCELLED 102 2 209 CANCELLED 100 1 209 ORDERED 101 1 209 CANCELLED 102 1 210 CANCELLED 100 3 210 ORDERED 101 3 210 CANCELLED 102 3 211 CANCELLED 100 4 211 ORDERED 101 4 211 CANCELLED 102 4 In this scenario all transactions with the event order of CANCELLED->ORDERED->CANCELLED are merged as one path. The overall path frequency is 5 since there are 5 transactions representing this sequence of events. Hope this makes sense. Cheers, Falko ... View more

Well, I would say yes - although I'm struggling to fully understand your diagram. The way path analysis works in VA is by aggregating all transactions for a given path. This means you will always end up with the full count on the right most nodes unless you have drop-offs somewhere along the paths. The diagram you have above doesn't show any drop-offs but still doesn't add up across sequences. In your example we have 662 customers (NEW/152 + EXISTING/500 + CANCELLED/10) and only 560 took an action (COMPLAIN/50 + ORDERED/510). Can I assume some of the customers just didn't do any actions at all? Here is a sample data file which has weight values specified based on your example - although you will see that I had to introduce some drop offs in order to get your counts right. id event time weight 198 NEW 100 0 198 COMPLAIN 101 2 200 NEW 100 0 200 COMPLAIN 101 0 200 LAPSED 102 120 201 NEW 100 0 201 COMPLAIN 101 0 201 EXISTING 102 30 202 EXISTING 100 0 202 ORDERED 101 0 202 LAPSED 102 5 199 EXISTING 100 0 199 ORDERED 101 29 203 EXISTING 100 0 203 ORDERED 101 0 203 EXISTING 102 465 204 EXISTING 100 0 204 ORDERED 101 0 204 CANCELLED 102 1 206 CANCELLED 100 0 206 ORDERED 101 0 206 EXISTING 102 5 207 CANCELLED 100 0 207 ORDERED 101 0 207 CANCELLED 102 5 Visualizing this in VA would produce something like: Since sankey diagram will always show the path width based on the frequency or weight some paths will appear quite thin. If you need to see detail values behind such paths - the 'show details' option (button top right corner) usually helps: Note, I should also mention that instead of using weights - you probably would just use the standard frequency as in a real environment you typically have one transaction represent one customer touch point. As such the total count of these transactions will give you the same diagram. Using weights here - just simplifies the sample data and reduces the overal number of rows required. Hope this helps. Cheers, Falko ... View more

The weight aggregation shown in the diagram is based on the total weight of the in/out bound paths. The main driver here is the transaction identifier. The time/date values are just used to specifiy the correct order of events within the given transaction. Keep in mind - the weight indicates the 'path' weight - not individual event weights. Whether or not a path will be split just depends whether you have two or more paths which share a sequence of events. If they do - the shared sequence of events are displayed as one path. In my last example above I define a path NEW->EXISTING-ORDERD (row 1-3) and a second path NEW->EXISTING->HOLIDAY (row 4-7). As you can see NEW->EXISTING is a sequence of shared events although ORDERED and HOLIDAY are not - hence the path will be split at this point. However - as mentioned before - the aggregation weight is for the entire path. So in your example the total weight is calculated by aggregating all weight values from row 1-3 (NEW->EXISTING-ORDERD) and row 4-7 for the second path. It's sometimes easier to see and understand weight calculations if you switch the link color (Properties panel) to 'Event' or 'Path' - dependent what you want to see. This will color each sequence differently and also show individual weights for each path. Hope this helps. Cheers, Falko ... View more

Hi Peter, The way path analysis works is by looking at the transactions first and then sorts each each event by their sequence order. In your example the NEW, EXISTING and CANCELLED events are all in different transacations (200, 201, 202) and as such represent different paths. You may have noticed that all three events are on the left side since they start off a new path. In order to have them appear within one path (and split into exisiting and cancelled customers as you describe) you would need to represent these within the same transaction or by grouping your data by the paths you describe. Example: Time Sequence Event Weight 01/01/2015 200 NEW 0 01/01/2015 200 EXISTING 180 02/01/2015 201 NEW 0 02/01/2015 201 CANCELLED 20 Note, that the first event (NEW) starts with 0 count since child sequences carry the actual weight. The example only shows the first two sequences but hope this gets you started. Cheers, Falko ... View more