Is the funnel chart broken? Or is ist just designed that way?

[r_weber]

Though I'm a long-time Dynatrace expert, it's the first time I'm taking a detailed look at the funnel chart using USQL. I've just learned (at least it seems like it) that the funnel defined int he query has to happen exactly in that order!

For example take this funnel for an ecommerce site

It's logical that you want your customer navigate from a landingpage to product categories, product pages and eventually place them into a cart and eventually checkout. But this will barely happen in exactly that order. A shopping customer will navigate through the page, categories, products back and forth and eventually place one thing, then another one and finally maybe perform a checkout (and even during the checkout place another promoted item into the cart before completing).

I was wondering why the backend order numbers (tracked NOT via user actions but on PurePaths) were so much higher than what I could see in the funnel. (the lower RUM coverage of 25% didn't explain it). The only reason for this would be that the user journey has to happen EXACTLY in that order without any deviations? Is that correct? I fear so!

If this is the case then the funnel chart becomes rather useless for tracking user behavior...

Any other opinions?

[Marcelo_santand]

@r_weber 
Our team works for a bank, we only introduce to the funnel only those URLs that are critical, such as login, money transfer, destination bank, transfer made and generate document. Adding a lot of URLs gets quite cluttered and the funnel focus is lost.

Best Regards!

[Julius_Loman]

My experience says, that it must follow the order, there can be several user actions in between. For example you can have multiple product page action in the session but and there must be at least one add to cart after. Are you sure you have your user actions set up correctly? How does a user session look like?

Several things to keep in mind:

• Double-check if your user actions are correctly defined. this is crucially important
• check if there are for example other ways to perform an action and if you capture the actions well
• some users might have adblockers thus preventing JS from being loaded and there is no RUM data for the session. Some browsers such as Brave block Dynatrace RUM JS by default.

I'm not sure if the USQL funnel correctly shows numbers for user session with over 200 actions which are splitter by default.

[r_weber]

I tried to narrow this down a bit more and it seems to be an issue that comes with a combination of things, which I'm trying to get evidence for (and I think I have):

1. In this environment RUM capturing is limited to 25%, so one would expect that the Order Numbers (last step in the funnel) I get from User side capturing would be ~25% of what I can track on the backend - it isn't, it is way lower!
2. User action names are set via placeholder from XHR requests (e.g. "click triggered placeorder"). This works fine, usersessions show these UAs consistently. These XHR requests are also captured on the backend side accordingly.
3. Conversion goals (e.g. placeorder) are set based on this UA. This also works fine

In theory I should therefore be able to align the "placeorder" calls on the backend with both, the number of useraction executions via USQL query/funnel and the conversion goal numbers. Like this:

A "one step funnel" just showing the placeorder step (to avoid any order of UAs):

This aligns nicely with the conversion goal analysis as expected (5 conversions):

However - and this is where things fall apart - the backend placeorder calls reflect the real number of orders, which are much higher! But these calls are correct, they have been confirmed by an BI system:

I could understand if RUM side analysis would be 25% of the backend numbers but it's way off!

My only conclusion is that:

1. Dynatrace doesn't capture all XHR requests properly and thus misses quite some of the "placeorder" XHR calls or fails to identify them.
2. The combination of not capturing all XHR calls and a 25% RUM coverage leads to a much lower coverage of the critical placeorder calls.

Since the difference is so big (~5 vs. 500) only ~1% of the XHR requests that are recorded on the backend are available in user session data, it's almost impossible to make any use of the user action data or extrapolate from that.

Maybe this works better in low traffic environments, but doesn't seem to be the case here...