The concept of a rigid “User Journey” has been heavily ingrained in our minds — it’s taught in virtually every “best practices” blog and included as a feature in just about every customer messaging platform (see here, here, and here, for just a few examples) — so it’s not uncommon for us to field these types of questions: 

• “How do I set up user journeys in Aampe?” 
• “I’ve set up user journeys in Braze — Can Aampe just use those so I don’t have to set them up again?”
• “I have these seven messages that I want to send out using this definite timeline to these specific users. How do I do that in Aampe?”

When we get these kinds of questions, this image comes to mind:

When the first locomotives came on the scene, they were basically just a bunch of horse-drawn carriages attached to an engine. It certainly wasn’t the most efficient way of doing things, it was just the only way people knew. It was what they were comfortable with, and comfort trumped efficiency and effectiveness.  

People had a hard time conceptualizing a train as anything other than a new way to pull a standard carriage. 

Today, we face a similar situation with user journeys: They’re what we’ve become comfortable with — not because they’re the most efficient or effective — but because they were the best option we were given with the tools we had at the time. 

So, how do you set up user journeys in Aampe?

Answer: You don’t.

‍

You shouldn’t be setting up user journeys at all. 

You need exactly zero user journeys in your life.

User journeys are a waste of time.

‍

The root of the issue is that a user journey is a fiction. In reality, there are many different paths an individual user could take to buy a shirt…or watch a video…or order food…or do whatever else it is that keeps your business in business. 

You can, if you really want to, define a handful of idealized journeys and pretend that enough of your users will follow what you’ve laid out that these journeys will add value. 

You can also pretend revenue is going to increase next quarter. 

Pretending doesn’t make it happen. Journey orchestration tools give you the illusion of impact, instead of actual ROI.

‍

The real data on user journeys

Let’s take a look at a popular clothing retail app we work with. The app is well instrumented – there is a definite “starting point” event that represents a user opening the app, and there’s a clear “ending point” event, representing when a user completes a purchase. 

We looked through a week of data and pulled out all users who had done these two events (app opens and checkouts), and collected the events that happened in between. Then we de-noised the paths by tossing out all the events that were more rare than the checkout event itself. We kept events like clicking on a recommendation, receiving a push notification, adding an item to cart, adding an item to wishlist, and so on. 

In all, we kept 29 events, including our two bookend-events.

Finally, we tossed out all users who didn’t make the journey from “app open” to “purchase complete” during the week, so we could focus only on the journeys that were completed. 

In all, we ended up looking at 41,904 users, each of whom followed a path to purchase between 1 and 39 times in the course of a week — 77% of them only once, but over 20% journeyed between 2 and 5 times.

In all, there were 50,252 unique paths represented among those users. 

Of the nearly 10,000 users who took the journey more than once in the same week, only 1.2% followed the same path every time. 32,490 took a path to purchase only once in the week we examined, and only 6.8% of those users took the same path as someone else.

And, if all of that data isn’t convincing enough, here’s Google’s Managing Director of Commerce saying that their data shows the same thing (watch between the 3:47 and 4:38 timestamps).

If we weren’t already clear enough, here’s the summary: 

User journeys are a waste of time.

‍

Don’t believe us? Try it yourself

Here’s that narrowed-down list of app events we used to find those 50,252 unique paths:

• Open App
• View Homepage
• View Promo
• View Recommendation
• View Product
• Filter Product Categories
• View Products List
• Search
• Click Products List
• Click Promo
• Apply Filters
• View Cart
• Open Notification
• Click Category
• Click Recommendation
• Filter Products
• Sort Products
• Update App
• View Wishlist
• Click Alternate Product
• Add to Cart
• Add to Wishlist
• View Account
• View Order
• View Order Item
• Apply Promo
• Remove from Cart
• Start Checkout
• View Checkout Step
• Complete Checkout

So, what kinds of user journeys could we identify from that list? 

At first blush, it seems easy — users will look at some of the products, add something to cart, and checkout. 

Simple, right? 

In fact, among those 52k unique paths, we can even find a user who did pretty much exactly that:

Sure, there are lots of other things they could have done, but they only really did the core things we’d expect them to if they were on the search for something to buy.

Now let’s look at the path from another active user:

‍

Well…shucks. 

Once you see a true-to-life journey of an actual user, it’s hard to unsee it. 

This user opened the app, viewed the home page, and then viewed a promotion (so far so good!). Then they viewed a list of products, and then went back and looked at a recommended item (still, nothing too out of the ordinary!). And then they went and viewed their cart — 

Wait, what?!

They must have already had something in there when they arrived! 

Well, then they went back to searching, and filtering on product categories. Then they clicked a product list, and then added that item to the cart! 

Great! They’re back on track. 

…but then they clicked on a product alternative — one of those “you might also like” suggestions and added it to their wishlist.

Wait, then they removed the item they’d added to their cart! 

…and this goes on and on and on

It’s messy. Real life is messy.

In fact, just to really drive the point home, we went through and modeled every app event’s connection to every other app event into a user journey roadmap (so, if a user did something, that event is an “intersection” on the roadmap, and if a user did one event and then another, those two intersections are connected by a road).

Here’s what that looks like:

‍

If you can find any important patterns in that hairball, you have a better imagination than we do. 

Each intersection is a dot. The bigger the dot, the more users did that event. The “road” lines are thicker for more frequently-trafficked connections. The dot in the very middle is the checkout event — the one place where the app makes money. 

But wait, it’s even more hopeless! 

The 52k user journeys we identified were only the successful journeys (the ones that ended with a completed purchase). 

For any app, the journeys that end in a checkout can’t compare, in number of variety, to the journeys that end in abandonment and churn. If you think there’s a lot of ways things could go right…try thinking about all the ways things can go sideways. It’s sort of depressing.

But don’t I need user journeys to get people to buy?

Let’s hope not, unless you’re prepared to set up and orchestrate 50,252 different journeys a week! 

User journeys over-simplify and over-complicate at the same time— 

• They over-simplify by assuming that most users will follow a very small number of paths to purchase (As we showed above, that’s just not how the world works) 
• They over-complicate by requiring a huge number of detailed rules about what to do in different situations. 

That’s why we built Aampe to operate differently.

Aampe gets rid of a lot of that complexity by automatically learning appropriate actions from user behavior, instead of making you create these “journey hypotheses” as hard-and-fast rules, like other systems do. 

Through experimentation and AI, Aampe learns:

• When each user wants to be messaged
• How often you can message each user to maximize responsiveness
• What topics each user wants to hear about
• What wording and framing speaks to each user

User journey orchestration tools require you to know all these things ahead of time, which just isn’t possible.

…Oh, and they also require you to know context: how do you know what behaviors in your app, short of an actual purchase behavior, indicate that a user has moved close to the purchase you want them to make? 

We can tame a lot of the noise in user journeys by making some modest assumptions about funnel events. The concept of a funnel, in most cases, is about as useless as the concept of a user journey: 

• Users don’t follow a linear path to conversion
• They can and often do go forward in the funnel only to then go back
• Many of them skip stages of the funnel altogether

However, the idea of a conversion funnel carries one really important idea we can use: conversion is a relatively rare event, and the process of conversion involves a user doing increasingly rare events until they get to the point of making an actual purchase.

Think of it this way: how do you know if a push notification is successful? 

Most messaging software systems measure success in clicks — if a user clicked on the notification, then it was a success. Obviously, a user who clicked on your notification makes you happier than a user who didn’t click. 

However:

• Some users who clicked went on to view one of your actual offerings in the app, while other users who clicked just jumped into the app and then left without doing anything. Do both of those groups make you equally happy? Of course not! You’re happier about the ones who engaged with your content in your app.
• Some of those who engaged with content actually added something to cart, while others didn’t. Again, you’re clearly happier about those who added something to cart.
• Some of those who added to cart began the checkout process, while others abandoned their carts. Once again, those who began the checkout made you happier.
• Some of those who began the checkout actually completed their purpose, while others didn’t. You’re happier about those who completed the purchase.

The purchase point is the hoped-for destination — the bottom of the funnel. 

More users began the checkout process than completed it, and more users added to cart than began the checkout, and more viewed your offerings than added to cart, and more clicked on a notification than viewed your offerings. 

A simple funnel construction is just a matter of counting — you have some things that a lot of people do, and some things that very few people do, and as soon as any individual user does something that is less common than the things they’ve done before, they’ve shown new willingness to move towards the endpoint that you hope they’ll eventually get to.

Now, back to our app:

At the very top of the funnel, we have the most general behavior — “Open App”. It doesn’t really get more general than that. 

At the bottom of the funnel, we have “Complete Checkout” (which, for the e-commerce app we’re looking at, means the user completed a purchase). 

The funnel is only useful in that it allows us to clean up that big messy network of events to give us automatable insight into the conversion process. 

Now, let’s recreate that network of roads and intersections, but this time, we’re going to impose the assumptions from our funnel. For example:

• We’ll only count events that happen in the order the funnel imposes, so:

• If someone opens the application then views the homepage, we’ll count that. 
• If someone opens the application then immediately starts a checkout, we’ll even count that (skipping steps isn’t a problem). 
• However, if someone does views the homepage and then opens the application next (yes, it happens), we don’t count that. 
• We only count connections between events that move in the direction the funnel says they should.

• As before, we’ll drop a lot of events that were even more rare than our checkout event (Since they’re more rare than our bottom-of-funnel endpoint, we’ll assume they’re noise for now).
• We’ll allow users to go through the funnel as often as they want (So a user might reach the checkout step, and then go back to adding something to cart. Because that goes backwards in our funnel, we won’t count the connection between those two events. However, if, after they’ve added something to cart, they move forward again to remove something from cart, or add to a wishlist, or checkout, we’ll count that connection).
• If a user does an action and then does nothing afterwards, we’ll create a “(Churned)” event to record that fact, so we can look at failures (which we want to minimize) as well as successes (which, of course, we want to maximize).

Now when we look at the road-and-intersection network, it looks very different:

As before, the dot in the center of the spiral is the checkout event. The closer a dot within the spiral is to that center, the closer the event was to checkout in the funnel. That big dot all the way over in the bottom-left corner is the “Churned” event. 

It’s still complex, but there’s manageable structure there. 

We can work with that.

Ok, so how do we actually use this?

When you have a network, you can “traverse” it — you can hop from point to point to understand how to efficiently get to the endpoint you want (completing a purchase) rather than the endpoint you don’t want (churn). 

We do that by picking a starting point and doing a “random walk” through the network — Each node in the network has a certain probability of connecting to other nodes. When we arrive at the node, we pick which node to hop to next based on those probabilities. 

(We couldn’t do this with the big, messy network we had originally. Because every event looped back on itself, the random walks just went in circles. We had to simplify the network in order to extract useful information from it.)

For example, here are the “transition probabilities” for the “user added something to their cart” event:

Filter Products         19.6%

(Churned)               14.7%

Click Alternate Product 12.9%

Remove from Cart        11.0%

Add to Wishlist         6.3%

View Wishlist           5.4%

View Checkout Step      4.7%

View Order              4.2%

Apply Promo             4.1%

Click Category          3.9%

Sort Products           3.6%

View Account            2.8%

Start Checkout          2.6%

View Order Item         2.4%

Complete Checkout       0.9%

Open Notification       0.8%

So if someone has just added something to their cart, they are most likely to then filter the product list, but they’re almost as likely to just abandon the cart and churn, and pretty likely to click on a product alternate, and so forth.

So we did a random walk through the funnelized network. In fact, we took 50,000 random walks. 

Here’s a random sample of 1000 of them:

Blue lines ended in a purchase; gray lines ended in churn. You can see that the number of steps in each walk varied greatly — the longest path touched on 13 different events before reaching the end, and the shortest one skipped straight from opening the app to churning. 

You can see that users can churn at pretty much any point in the process.

We can use these random walks to figure out which points in the funnel most consistently lead to purchases — we literally walk through the network tons of times and calculate the percentage of times we ended up with conversion instead of churn. This allows us to estimate the probability that a particular event feeds into conversion:

Both of the above plots show all of the funnel events, in the order that we established earlier. 

The bars on the left side show the probability that a user who reaches a particular point in the funnel will eventually convert instead of churn. That conversion probability generally rises as we go further down the funnel, it’s not a smooth or consistent increase. It’s those “bumps” in the conversion probabilities that interest us, and that allow us to calculate the momentum probability, which is shown in the right-hand plot.

For example, look at “Add to Wishlist” (8th event from the bottom, between “Sort Products” and “View Order”). The conversion probability for that event isn’t bad (it’s around 20%), however, that’s considerably higher than the preceding event, and the one before that. 

That moment in the funnel (adding a product to the wishlist) represents a change in momentum for the user. That’s why the plot on the right looks quite a bit different than the plot on the left. 

The plot on the left represents the probability that a user will convert given that they reached a certain point. The plot on the right represents the size of the shift from where the user was previously (We’ve highlighted in blue the events that have particularly high momentum, but there’s no hard cutoff). 

Using the cutoff we selected, there are three major groups of momentum-generating events:

• Viewing a promotion 
• Viewing a wishlist and removing items from a cart (not adding to them - sometimes users take a step back in order to take two steps forward)
• Adding to the wishlist, viewing an order, and then actually starting a checkout. 

Notice that all of the events after “Start Checkout” have high conversion probability, but they all have lackluster momentum probability. That’s because those events are riding on the momentum of starting a checkout (they have a high conversion probability because the user already took the step that committed them to forward movement toward a completed checkout).

High-momentum events are inflection points where users are already predisposed to move forward in the funnel. 

…and these are great times to reach out to your customers and build on that momentum 

(Note: You don’t always have to reach out with a high-pressure conversion message. For example, for a ‘filtering product category’ action (which has a decently high momentum probability compared to the surrounding events), you could try to reach out with additional information about the categorie(s) your user selected to build on the momentum they aready have going.

They don’t need you to pressure them into making a decision or preemptively offer them a discount. They might just appreciate some relevant information that helps them make their final choice.)

‍

Smart orchestration is a conversation, not a journey

Is it practical to think that you can convince every user, at every moment, to make a purchase?

Probably not.

Not all users are “in-market” at any given time. 

A user may add an item to a wishlist because they want to get it for their mom’s birthday six months from now. They’re using your app to save information about things they want to buy, which is great, but you’ve orchestrated a user journey that takes adding to a wishlist as a signal to push a user toward checkout. 

For the user shopping for mom’s birthday six months from now, that’s really frustrating. 

Want to convince your user to stop using your wishlist feature? Orchestrate a user journey that annoys them every time they add something to a wishlist. 

Yes, you’ll get those indecisive folks who added to wishlist because they weren’t quite ready to buy, but you’ll annoy all the people who added to wishlist because they were quite sure they were ready to buy…at a future date.

‍

If a user is in-market, you have the opportunity to have a conversation with them about that. 

Yes, that might involve recommending specific items for them to buy, or even offering them a deal, but that might not motivate your users. In fact, pushing that blatantly marketing tone in the conversation could turn off a lot of your users. 

Instead, you can use the network structure of your app event to identify high-momentum points where you know a user is open to interacting with you - and then interact appropriately, like you would in a real face-to-face conversation.

‍

Aampe lets you orchestrate your messaging using those high-momentum points. 

You can set them yourself (we help you figure out which ones are the best bets), and then write messages to run when users reach each point. 

When a user gives an indication that they’ve moved to an momentum-rich part of the funnel, Aampe automatically reaches out at a time they like (because we’ve learned what times they like) with a product they like (because we’ve learned which products they like), and framed in wording that they like (because we’ve figured out what wording they like), offering them a message tailored to where they are in the process right now.

These aren’t funnel workflows. A user can move forward toward a purchase, and then further away, then back again. That doesn’t matter. 

What matters is where they are at a given moment, and what the most helpful and appropriate thing to say to them is, given where they are. The idea isn’t to move them on, but to meet them where they’re at. 

If you do that, they’ll act on their own because they’ll have all the information they need to make a confident decision.

‍

No more impersonal User Journeys

In everyday conversation, few people react well to nagging and bribes, but the majority of app communication today falls into one or both of those two categories, largely because most messaging systems are too steeped in the outdated campaign-and-journey approach to communication to allow anything better. Don’t settle for a horse and buggy. 

Don’t settle for user journeys. 

Your users are people. 

People don’t want marketing. 

They want conversations.

‍

Want to discover your app’s momentum generating points? Drop us a note at hello@Aampe.com.

‍