Dumps Clever Idea—And Survives Black Friday

The biggest E-Commerce surprise of Black Friday was probably what didn't happen: The problem-plagued didn't crash. Despite an absent E-Commerce chief for six weeks before the big day, and what some saw as a half-hearted defense of the site by Target's CEO on an earnings call, the chain's online store weathered the Black Friday-Cyber Monday weekend with just some performance degradation—about the same as other major E-tailers. The most likely reason it survived: deep-sixed its clever but ill-fated experiment in limiting the number of customers who could be on the site at the same time.

That's the site feature that led many customers to conclude the site was down even when it wasn't on Missoni Tuesday in September. It may also have been key to Target's plan for keeping server and bandwidth costs down—and creating a better customer experience—as the chain took its site back from Unfortunately, throttling the number of customers didn't work. It turns out that clever capacity management is no match for a hoard of big-sale-day customers. For that, the only answer really is more servers, more bandwidth and more raw power.

Target wouldn't comment on its crash-free weekend except to confirm that it happened. (The chain's new E-Commerce boss, Casey Carl, was named just three days before Black Friday and he isn't talking either.) However, it's safe to assume that as part of its fix, added more servers and bandwidth in advance of the weekend, and also worked more bugs out of its back-end order-management software.

But the most visible change for sharp-eyed customers was how the site behaved during heavy-traffic periods on both Black Friday and Cyber Monday, compared with its behavior during the crash-prone Missoni launch. The three most obvious differences: When the site got busy, there's now no page that tells customers to wait and they'll be allowed onto the site as soon as there's room. There's also no mysterious notification warning shoppers when they've been idle for xx minutes. And the site's performance is perceptibly slower than normal when all those extra customers arrive.

In short, now behaves pretty much like any other E-Commerce site under a heavy load. And while that has an obvious and business-critical benefit—the site keeps working now—it also means the end of a very interesting idea.

Most E-tail innovation comes on the customer-facing end, whether that involves videos or QR codes or merged-channel customization. Not much effort has gone into doing things dramatically in the data center (except for pushing some or all of it up into the cloud).

Faced with having to build an E-Commerce site from scratch—one that had to be better than the one Amazon had been running for the chain for a decade—Target made a bet that, when the site got crowded, customers would be willing to wait for a truly pleasant shopping experience. It was the equivalent of concluding that letting just a limited number of customers into a store at a time would make shopping more pleasant than having a whole mob stampede through the doors at once.

That has actually been tried in brick-and-mortar stores, and sometimes it works.That has actually been tried in brick-and-mortar stores, and sometimes it works. It certainly makes for a more orderly, less crazed experience for both shoppers and associates, and for special sales that are only available at a particular retailer, many shoppers are willing to wait in line for their chance to get in. Why shouldn't it work online too, by counting new online customers as they arrived, monitoring each shopper's session to spot abandoned shopping carts, and diverting new arrivals to a queue when the site got too crowded?

There was another benefit Target probably hoped to get from limiting the number of simultaneous customers in the online store: lower IT costs. Target had no real experience with IT operations for a major E-tail site. How much hardware and bandwidth did the retailer need? Unknown. But it was possible to calculate how much time an average customer spent on the site, and how much bandwidth and CPU time that required. Choose a limit for the number of customers, do the math and multiply by a fudge factor, and the result should be a reasonable estimate that would control costs and keep things nicer for shoppers.

It was a very interesting idea. And now we all know that it didn't work. Customers don't behave during a big sale anything like "average" customers, and they require much more than the average amount of server power. Online customers who can't get into a site won't wait, even if that's what the site explicitly tells them to do—they'll assume their web browser has frozen or the site has crashed.

And that improved customer experience? It turns out that customers don't notice that during a sale. They'll grumble about long lines and scream about major problems, but they don't actually seem to appreciate when everything works smoothly. For good or ill, online shoppers know they can open more tabs and be in multiple online stores at the same time. They'd rather wade through a slowly responding site than wait in line.

And while E-Commerce capacity management sounds like a great idea, it requires huge amounts of data from operational experience—experience that won't necessarily transfer even from one site to another. Buying too many racks of servers (or renting too much cloud capacity) turns out to be relatively cheap insurance against a capacity crunch.

In short, everything about Target's bright idea was wrong-headed. It's easy to see that in hindsight.

Except, of course, that if it had worked, would have a significant competitive advantage—lower E-Commerce operational costs, happier customers—and that wrong-headed idea would have been brilliant.

If Target is lucky, it won't have to go looking for that kind of brilliant idea again.