Announcing User Journeys: see the paths users take through your apps

Today we are excited to announce the newest feature in bitdrift Capture: User Journeys. User Journeys allow you to show the frequency of different paths that users have taken in order to arrive at a particular state in your app. This type of analysis is invaluable for better understanding conversion, churn, force quits, rage clicks, and many other behaviors that are critical to optimize for the best customer experience.

At bitdrift, we have a very different take on observability: on-device intelligence. Instead of sending loads of expensive telemetry data only to later sift through it for a few precious insights, we couple a sophisticated device SDK, local storage, and real-time control via our control plane SaaS, in order to dynamically fetch only the data that is needed in order to understand customer behavior and solve problems quickly. We give you 1000x the observability at 0.01x the cost. What is a user journey analysis? Imagine that you have a shopping app. The most important action in this app is clearly the “buy” button on the checkout screen. We can generate interesting metrics about how often people click on this button (and how much they spend), but what if you want to start understanding the sequence of app events that lead to conversion/purchase? Are some flows more likely to lead to conversion than others? Or imagine that you want even more detailed data around which flows lead to purchases above $500? These types of questions are typically done using user journey analysis (and are typically visualized using Sankey diagrams). The end result of user journey analysis is a set of paths, sorted by frequency, that can be used to understand behavior. While conversion is the common example, the same type of analysis can be used for negative cases as well such as force quits. You might be thinking “okay, but my existing RUM solution does that.” And while user journey analysis is not a novel feature and can be found in existing RUM solutions, these existing solutions are constrained by the fact that they have to send all data to the backend for analysis. This has two very important implications:

You have to know what branching and filtering conditions you will use ahead of time. If you get them wrong you will have to wait weeks to rollout changes and deal with inconsistent data between app versions.
Because the volume of data required to perform the analysis is large, it’s typically impractical to send it all to the backend, so it’s usually aggressively sampled, making it difficult to accurately understand user behavior, especially when it extends to smaller subpopulations.

What both of these mean, brass tacks, is that you don’t get the visibility you need and your user experience suffers. And if you want to change that, it’s going to cost you an arm and a leg. This is the old observability equation. When user journeys are instead built on top of the bitdrift dynamic observability platform, the above restrictions no longer apply. For starters, workflows are used to dynamically configure the branching and filtering conditions. This means that both the steps and the start/end states can be any log/signal from your app! If you make a mistake, just change them and deploy them in bitdrift, and they will immediately take effect for all the instrumented app instances. New results will start coming in seconds! Since a substantial part of the processing is done on the device, very little data has to actually be sent to the backend for processing and storage. This means that we can avoid sampling entirely, leading to much more accurate results. Coming back to the shopping app example, when using bitdrift User Journeys it is not necessary to pre-program any branching or filtering conditions. For example, maybe we would like to start out by looking at which screens are viewed leading to purchase events, and then move on to understanding purchase events of electronic items that cost more than $250. Later, perhaps we would like to also include some button presses within one of the screens. We can do any of these changes in real-time, without needing to redeploy. The sky is the limit! Capture is changing the mobile observability game by adding a control plane and local storage on every mobile device, providing extremely detailed telemetry when you need it, and none when you don’t. If the lack of detailed user journey analysis was keeping you away, now is the time to give us a try! Interested in learning more? Check out the sandbox to get a hands-on feel for what working with Capture is like or get in touch with us for a demo. Please join us in Slack as well to ask questions and give feedback!

Author

Matt Klein

November 19, 2024

Stay in the know, sign up to the bitdrift newsletter.