A 20-Step Checkout Lost 70% of Buyers

In 2023, as CoinDesk started selling tickets for Consensus 2024, about 70 percent of the people who added a ticket to their cart weren't finishing the purchase. Consensus is CoinDesk's flagship conference, so that number was a fire alarm.

I was CoinDesk's director of product management at the time, and I came to the project partway through. It had started as an engineering-led effort and it wasn't going well. The events lead was defining what success looked like, but they were also running the whole conference and didn't have time to own a checkout redesign on top of it, so I took it over. The full write-up is in my case study, and the lesson from it came with me to a very different product a few years later.

When a funnel loses most of its users, it's tempting to go looking for the one broken step. Sometimes that step exists. Here, the problem was the length of the whole journey, and the only way to see it was to walk all of it, end to end, for every kind of buyer.

The obvious suspect was only part of the problem

Buyers had to verify their email partway through checkout, and an unverified account simply stopped moving through the system until they did. Everyone suspected verification, and it really was part of the problem. It just wasn't all of it.

When I mapped the journey from the moment someone decided to buy a ticket to the moment they were fully registered for the conference, it ran more than 20 steps. Create an account, set a password, leave to verify your email, come back, answer registration questions, pay, and more, spread across separate screens and separate systems. Every step was a place to lose someone, and we were losing most of them.

Three weeks of walking the whole journey

I spent about three weeks on journey mapping, research and alternatives, and most of that time went to deciding what we could cut. I mapped every registration scenario I could find: someone already logged in, someone with a CoinDesk account who wasn't logged in, someone brand new, and someone who wanted to check out as a guest. Then I traced each one across the login service, the CoinDesk account system and the event platform, with a journey map for each that rated how the buyer would feel at every step.

Cutting was harder than it sounds, for two reasons. Some of the registration questions existed because CoinDesk had to report that data to vendors and partners, so those fields couldn't just disappear. The work was figuring out which were truly required, asking for those as efficiently as possible, and dropping the rest.

The bigger constraint was that the same system ran CoinDesk's webinars. Those were often sponsored, and CoinDesk had data obligations to those sponsors, too, so any change to how a Consensus buyer moved through registration was also a change to how a webinar attendee did. Every change had two sets of users to protect.

Two short paths instead of one long one

The redesign came down to two paths. An existing CoinDesk user who was already logged in got a path of about four steps. Everyone else got about seven to nine. Either way, it was a fraction of what buyers had been facing, and it took a lot of small decisions to get there:

• Verification moved to the end. Buyers could buy their ticket first and verify their email when they went to access it, so verification became part of getting the ticket instead of a wall in front of the purchase.
• Screens were combined. Account creation and event registration became one form instead of a sign-up screen followed by a separate registration screen.
• We stopped asking for what we already knew. For someone already logged in, the email was prefilled and the password field disappeared. For someone typing an email, the system checked right away whether they already had an account.
• Fewer questions. Every registration question we didn't need got cut.
• Getting back in got easier. Reminder emails carried a magic link, so nobody had to remember a password.

Moving verification later couldn't mean giving up what it protected. An unverified registration couldn't attach to an existing CoinDesk account with the same email, and an unverified user couldn't log in to manage a CoinDesk profile. The friction moved, and the safeguards stayed where they were.

After the new flow shipped, conversion and drop-off went back to typical levels for a ticket purchase, and we delivered it relatively quickly. Because the webinars ran on the same system, the webinar team got the shorter flow at the same time, and their sign-up rate improved without any extra work on their part. The APIs we built for it outlasted the project, too.

70% is also the e-commerce average

That number deserves a second look, because 70% happens to be almost exactly the industry average. Baymard Institute's average across 50 studies of e-commerce cart abandonment is 70.22%. But that average includes a lot of people who never meant to buy: in Baymard's own survey, 42% of US shoppers said they'd abandoned a cart because they were just browsing or weren't ready.

A conference ticket in a cart is a different animal. Somebody who has picked a ticket for a specific event on specific dates has mostly decided to go, so losing seven in ten of them at checkout is a very different signal from losing seven in ten window-shoppers. That's my read rather than Baymard's, but the fix bears it out: once the journey got shorter, drop-off came back down to normal for a ticket purchase.

Baymard's breakdown of why people leave is the useful part. Among shoppers who abandoned for reasons other than browsing, 18% left because the site wanted them to create an account, and 17% because checkout was too long or complicated. Baymard also found the average US checkout shows 23.48 form elements by default, when an ideal flow can be as short as 12 to 14. Our Consensus checkout had both of those problems at once.

None of this is new, either. "The $300 Million Button," a well-known write-up from the usability firm User Interface Engineering, is the story of a retailer that replaced a forced Register button with a Continue button and a note that buyers didn't need an account to purchase. The number of customers purchasing went up 45%. Teams keep relearning the lesson because the extra steps each have a reason to exist, and nobody owns the journey as a whole.

Where the friction goes matters as much as how much there is

A few years later, I brought the same lesson to Tallo, a career platform for teens and young adults that needed email verification because its parent company required proof that users owned the email address on their accounts. The audience made it hard. A lot of students sign up with school email addresses, schools run aggressive spam filters, and a verification email stuck in a school spam folder means a student who literally can't verify and probably won't come back.

A Tallo product lead had proposed a soft gate: let people create an account and use the product, and ask for verification later. The idea was theirs. My part was backing it with what I'd seen at CoinDesk and turning it into something a team could build, and that started with one question about every action in the product: can other people see it?

Reading, searching, taking assessments, saving jobs and applying on outside sites all stayed open. Posting, commenting, following another person, making a profile public and applying through Tallo required a verified email. The test came straight from the risk. Verification there exists to stop someone from creating an account that pretends to be somebody else, and a fake account that only reads job listings doesn't hurt anyone, while one that posts under a real student's name does.

The gate also sits as late as possible. Someone new to a product makes a series of small commitments, like exploring, saving a job or taking an assessment, and each one makes them a little more likely to stay, so the prompt only shows up when someone tries one of the public actions. It shipped about two months after the meeting where I picked up the project.

A few months after launch, I went back to the funnel. Most people who hit the prompt closed it without asking for an email, and the analysis turned up a gap: new accounts weren't getting a verification email at sign-up, so the gate was usually the first time anyone asked. We added that email. A gate isn't finished when it ships. It's a hypothesis about where friction belongs, and the only way to find out whether you put it in the right place is to look.

What I'd tell a team with a leaky funnel

Walk the whole journey before you touch any single step, and walk it as every kind of user, across every system it passes through, including the ones another team owns. Then ask what each piece of friction is protecting, put it where that protection actually happens, and take it out everywhere else.

The fix at CoinDesk wasn't one change. It was dozens of small ones, each removing a step somebody had a good reason for, and it took looking at all of them at once to see which ones the journey could live without.