Sales Stopped Overnight: Was It the Website or the Ads?

The email was short: no orders since September 29, is everything working on your side?

Nobody likes that email. The usual reflex is to blame the website, a developer starts digging through code, and a week later the team is still guessing. I answered it the same day with a chart, and the answer was not the website.

The setup. A consumer health brand of a European pharmaceutical group, selling through its own online shop. I worked on it through a digital agency, next to the brand's CTO, its marketing team and a separate ad agency. My part was tracking and analytics, from the checkout code to the reports.

Four checks, in this order

1. The buying path itself. I went through the whole path on the live site, from product page to payment, and checked the backend behind it. Everything answered. If the shop had been broken, this is where it would have shown.

2. The server's own record. Analytics only sees visitors who accept cookies. The server logs every checkout attempt regardless of the banner. In that log, attempts fell from several a day to almost none. So people had not stopped succeeding at checkout. They had stopped arriving.

3. My own false lead. On the way I found an old backend address answering with an error. It looked like the culprit. Before saying a word to the client, I checked it and ruled it out. Reporting it would have sent everyone after the wrong thing for days.

4. Traffic by source, per day and per hour. This is where the picture became obvious.

What the numbers showed

About half of all page views came from Instagram and Facebook, and almost all of that from a single Meta campaign. On September 28, around 10:00, that campaign stopped. The share fell to a quarter that day and to zero from the next. The last order came in that evening.

The site was fine. The traffic that bought had been switched off.

The question went to the ad agency with that chart attached: which campaign, from which hour. That is a question they could check in the ad account, instead of a development investigation into a website that worked.

Paid, but no order

While reading the checkout log, I noticed a line I did not like: payment succeeded, but no order was created, cart is empty. It went back to August.

That line means a customer may have paid and the shop may not know to ship anything. Here is what I did, step by step:

• Collected every case. 11 flagged attempts, each with its payment id and without any customer data.
• Found why it happened. The shop built the order from the visitor's cart, and in these cases the cart was already empty when the payment came back.
• Found why nobody knew. There was an alert for exactly this case. It went into a log inside the server, because the alert address had never been set up on the live site. An alert nobody receives is not an alert.
• Proposed the fix in one message. Build the order from the data saved at the moment of payment, and send the alert to a person. The CTO shipped it the same evening on all three of the group's shops. I pulled it and checked it on the live site.

Ten had an order after all: the browser had created it. One payment really had no order behind it, and it was created by hand. One customer is not a big number, but it is a paying customer the shop did not know about.

A month earlier: purchases analytics never saw

On September 9 I noticed that the analytics project had not recorded a single purchase, although the shop had paid orders.

I reproduced it with two controlled requests side by side. The analytics service rejected the whole purchase event whenever its id was not in the exact format it expects, and the shop's code never looked at the answer. Every purchase was sent, and every purchase was thrown away, without a single error anywhere.

Now each order gets a fixed id built from the order itself, so a retry can never count one purchase twice, and a failed send leaves a warning. Purchases have been recorded since.

One more from the same shop

Earlier, I diagnosed why the checkout had taken no payments at all since the end of April: a secret key missing on the live server and a plugin the deployment never shipped. Two small things, and together they stopped every sale.

If your calls or bookings drop

The business here is a shop, but the order of checks is the same for a clinic, a law firm or a salon:

1. Book or call yourself. On a phone, in a fresh browser, the way a new client would.
2. Look at what your own system recorded. Your booking software keeps every booking and your call tracking keeps every call, whatever the cookie banner says. Compare it with what Google Analytics shows.
3. Split visits by source, per day, for the last two weeks. If one source dropped to zero on one day, ask whoever runs it what changed that day.
4. Check that your alerts reach a person. Send a test and see who gets it.