This article shows you how to model a funnel in Scuba.
Simplified Dataset To Model Shopping Cart Purchases
For this walkthrough, we will be using a simplified dataset. There are 10 users, and each user performs a sequence of actions, one action every 10 minutes. Sometimes the user doesn't perform any action, which is represented by a hyphen (-). The actions are letters (A, B, C, D, E) but we could imagine that they represent real actions, like:
A = view shopping cart B = update payment details C = click "Buy now" button D = send a message in the embedded chat E = read a message in the embedded chat
Here's the set of event sequences for each user.
user event sequence ----------------------------------- Alice ABCDA---CCBB--CABBABB-- Ben BBAA-A-A--BACDDED-D---D Carol DDCDCCD-A---C--DACCA-A- Dean CACACAC---CAAA-CAA-CAAA Ellie A---A---A---A---A---A-- Francisco A-A-A-A---A-A---AA---AA Gene ABCABC---ABCABC---ABCAB Heather C---AB---C---ABB---CC-- Ingrid AAAAAAABCAAABCAAABCAABC Jessica A---------B---------C--
If we were to visualize these events in Scuba 3.0, we'd see the following. Note how there are 23 data points, each which corresponds to one of the time intervals in the dataset above. At the first data point, there are 10 events, which makes sense because during the very first time interval in our dataset, all 10 users took an action. At the second data point, there are 6 events, because in the second time interval in our dataset, only 6 users took an action (the other 4 just have a hyphen which means they didn't take any action).
We can do the same thing in Scuba 2.x, and you'll notice one slight difference. Looking at the first data point (for example) the graph is showing 4 events instead of 10. That's because the Scuba 2.x query is using a resolution and trailing window of 3 minutes (the same as the Scuba 3.0 query) but is normalizing the result to show the number of events per minute. This "units" setting is configurable within the chart controls.
Define A Funnel That Represents A Shopping Cart Purchase
Suppose that the sequence of steps "ABC" represents a user making a purchase via their shopping cart. It's possible for the user to attempt multiple purchases, and only complete some of them. Let's assume that each time the user performs action "A" to view their shopping cart it represents a new attempt (cancelling any previous attempts that were not yet completed). So, for example, Alice has two completed purchases and two purchases that reached step B but did not actually complete.
If we do the same manual analysis of all 10 users, and we assume that all the "in-progress" flows eventually time out, we'll discover the following:
ABCDA---CCBB--CABBABB-- ==> 2 completed (ABC), 2 reached (AB) BBAA-A-A--BACDDED-D---D ==> 1 reached (AB), 4 reached (A) DDCDCCD-A---C--DACCA-A- ==> 4 reached (A) CACACAC---CAAA-CAA-CAAA ==> 11 reached (A) A---A---A---A---A---A-- ==> 6 reached (A) A-A-A-A---A-A---AA---AA ==> 10 reached (A) ABCABC---ABCABC---ABCAB ==> 5 completed (ABC), 1 reached (AB) C---AB---C---ABB---CC-- ==> 2 completed (ABC) AAAAAAABCAAABCAAABCAABC ==> 4 completed (ABC), 11 reached (A) A---------B---------C-- ==> 1 completed (ABC)
In 2.25, create a Funnel to model the shopping cart purchase:
Click on the Funnels icon in the left hand navigation bar, and when the navigation bar expands, click the Create New Funnel link.
In the Edit Funnel dialog, create a 3-step funnel, where the first step is "action is one of A" and the second step is "action is one of B" and the third step is "action is one of C". Select the option to "Reset funnel if event matches Step 1". Set the overall funnel timeout ("All events happen within") setting to 1 week, which is long enough that it won't have any effect for this dataset.
In 3.0, create a Flow to model the shopping cart purchase:
Click on the Flows icon in the left hand menu bar, and then click the "+ New Flow" button in the top right hand corner.
In the Flow Editor page, create a 3-step flow, where the first step is "events with action that matches A" and the second step is "events with action that matches B" and the third step is "events with action that matches C". Select the option to "Restart flow when condition in first step occurs". Set the overall flow timeout ("Flow ends after total time of") setting to 1 week, which is long enough that it won't have any effect for this dataset.
How Many Users Completed At Least 1 Purchase?
Suppose that we want to know how many users completed at least one purchase.
In 2.25, use the Funnel visualization:
From the Funnels menu, click on the name of your funnel to navigate to the Funnel visualization. Make sure your data is selected in the time scrubber, and deselect the "Allow sampling" checkbox since the number of users is so small. When we run the funnel visualization, we learn a couple of things right away. First of all, we can see that of our 10 users, all 10 of them performed step A at least once. Then, 6 users made it to step B at least once. Finally, 5 users completed the funnel (by performing step C) at least once, which is the answer to our original question.
Under the hood, this visualization essentially builds a user metric that is "max of funnel ABC.terminal state" and then counts users grouped by the results of that metric.
By hovering our mouse over each segment, we can also see that the median time spent between steps A and B, versus the median time spent between steps B and C, is about the same. (They are both around 10 minutes.) This is essentially creating a user metric that does "average of ABC funnel.time between 2 and 3" and then taking the median of this value across all users.
In 3.0, use the Sankey visualization:
Click the Explore icon in the left hand menu bar, and then click the Sankey icon in the top menu bar.
In the Show section, select your flow and click the GO button:
You'll see a 3.0 Sankey visualization that shows all the distinct paths that users took through the flow, and tell us how many users took each path. This is a bit different from the 2.25 Funnel visualization, which shows the furthest progress into the funnel for each user.
If we hover over the path that made it all the way to step C, we can see there were 5 unique users who followed this path at least once. This is the answer to our original question of "how many users completed at least one purchase" and matches the answer that we got from the 2.x funnel view.
Now, let's hover over the path that made it to step B, but then did NOT make it to step C. This represents a "drop off" and in Scuba 3.0 these drop offs are rendered as light grey paths. We can see that 3 users had at least one flow where they did "AB" and then didn't go further. This matches our finding from the raw data, and is something that the 2.25 Funnel visualization doesn't tell us.
Scuba 3.0 can go even further, if we introduce a "split by user" in the query. Now we can see, at a glance, which users made it all the way through the flow, which users never completed the flow, and which users did some of both. For example, we can see that Jessica only had the experience of completing the flow, Dean only had the experience of NOT completing the flow, and Gene had both experiences.
Finally, let's toggle Scuba 3.0 to count the number of instances of this flow (instead of the number of unique actors).
Now, the thickness of each line in the Sankey diagram indicates the number of times each user went through that flow. This is a very powerful visualization, because at a glance we can see that Ingrid had a huge number of purchase attempts, some of which completed, whereas Jessica had only a single purchase attempt (which happened to complete). And Dean and Francisco had a large number of purchase attempts, but never succeeded. We can also see that, in general, most of the dropoff happens going from step A to step B, but a few users were somehow immune from that.
How Many Purchases Did Each User Attempt?
Suppose that we want to know how many purchases each user attempted, and how far they got.
In 2.25, use the Explorer:
Click the Explorer icon in the left hand menu bar. Create a measure that does "count unique ABC funnel" and in the group by field, add both "user" and "ABC funnel.terminal_state". We are now counting the number of funnels for each user, based on how far the funnel progressed. This query is going to tell us exactly what we learned from manual inspection; for example, Alice had two completed funnels (meaning they reached step 3, in other words she performed actions ABC) and two funnels that reached step 2 (in other words she performed actions AB).
In 3.0, use the Explorer:
In Scuba 3.0, we'll answer this question a little differently. We make three measures (by clicking the compare to... link to add additional measures) each one representing flows that reached only as far as state A, B or C respectively. Then we split by user. We can then learn for each user, how many purchase attempts they made that reached each possible result.
Scuba 3.0 also allows us to ask each flow for its "termination reason". In this example, some flows restarted when the user repeated step A (in other words they initiated a new purchase), others ended because the user completed a purchase (they reached the last step), and others ended because they just ran out of time (due to the total timeout of 1 week).
What Percentage of Purchase Attempts Were Successful?
We might want to know what percentage of purchase attempts were successful overall, but even more interesting would be to know the percentage on a per user basis.
In 3.0, create Actor Properties:
Let's calculate the calculates the ratio of successful attempts out of the total attempts through this purchase flow, on a per-user basis. This requires three separate actor properties. First we define an actor property that counts "successful attempts":
Then we create an actor property that counts total attempts:
Then we create an actor property that computes the ratio (on a per actor basis). In the function builder, I added an extra "multiply by 100" step so the answer would feel more like a percentage rather than a ratio.
Finally we can use this in the explorer to query the ratio by user (it's very similar to the preview query we saw above when defining the actor property). We can also add another measure to give us the total number of attempts; the two of those measures together give us a good picture of what's happening for each user.
How Long Did Each User Take To Make Each Purchase?
Another interesting question we could ask is, for funnels that completed (in other words, the user made a purchase) how long did it take?
In 2.25, use the Explorer:
In this particular Scuba 2.x query, we're drilling into the time between step B and C, and we can see that Gene had 5 total completed purchases, and he tended to spend 10 minutes on that last page. Alice had two completed purchases, and while for one of them, she spent only 10 minutes on the last page, for the other she spent significantly more. And Jessica spent almost 1 hour and 40 minutes on that last page during her one completed purchase.
In 3.0, use the Explorer:
In Scuba 3.0, we can use the "total time" flow operator to answer this question. If we take the average time spent in flows that completed, split by user (and divide by 60,000 to convert to minutes) we discover that Ingrid and Gene had flows that completed in the smallest possible time (ABC) while Jessica had a very large average time of 200 min (A------B------C).
How Many Purchases Were Attempted / Completed Per Week?
What's interesting about this question is that it forces us to be clear about which week "owns" a particular purchase if the purchase happens to span multiple weeks. In Scuba 2.25, the effective behavior is that if a purchase spans two weeks, it gets counted in BOTH weeks. In Scuba 3.0, the effective behavior is that if a purchase spans two weeks, it gets counted only in the week in which the purchase STARTED.
So if we assume that each letter above represents a time bucket (like a week) and we ask the question, how many purchases were attempted / completed on a weekly basis, what answers would we get for weeks (1) and (2) as highlighted in the image above?
Scuba 2.25 and 3.0 would give us the same answer; 6 purchases attempted, of which 3 (eventually) completed.
Scuba 3.0 would tell us there was 1 purchase attempted, and it did not (eventually) complete. Although there were a number of purchases in-flight during this period, since they didn't START during this period they are not counted. So you can think of this as answering the question "how many purchases were started during this week" and this has the nice property that a given purchase is only counted once.
Scuba 2.25 would tell us there were 5 purchases attempted, of which 4 eventually completed. In this case, the in-flight purchases are counted during this week. So you can think of this as answering the question "how many purchases were in active during this week" and we are aware that the same purchase might be counted across more than one week.
Here's the actual graph from Scuba 3.0 with the same overlay: