When sales dip or a tool breaks, the first explanation that shows up is usually a villain. The new app. The vendor. The other agency. It is tempting because it is tidy. Three times in the last few weeks the tidy answer was wrong, and what we did next is the part we would want you to know about before you hire anyone.
1. The sales dip and the cookie banner
An online store told us on a Monday morning: very low sales yesterday, none yet today. By 9 AM we had checked the site, the checkout, the payment options, and the hosting status. All clean. Then a plausible culprit surfaced. A privacy-banner setting looked like it had changed, and the analytics showed a spike in visits with no source attached. We wrote to the store’s contact and said it might be the banner.
She pushed back. So we tested again, in a real browser, as a US visitor who never clicked anything on the banner. Tracking fired normally. The banner was not blocking anything. And the “spike” of untracked visits turned out to be how the analytics platform reports the last two days before the numbers settle. It was not a change. It was Monday’s data being Monday’s data.
We retracted the theory in writing before 10 AM, the same morning we had floated it. The real picture was duller: a soft Monday, a lower-priced mix of orders, and a drop of roughly a quarter in search traffic after the ads vendor had tightened budgets a few days earlier. That last point became the right question to the right party, which is where the morning should have started.
2. The bug report that was our fault
We had a ticket open with a social publishing platform for three weeks. Posts with images failed every time, text-only posts worked, and we had re-tested and told support it was still broken.
Support wrote back: your image links are not reachable. We checked. Every failing test had used the sample image from the platform’s own documentation, and that sample had quietly gone dead since. We re-ran the test with an image we host ourselves. It worked the first time.
We replied the same day and said so: you were right, we were testing with a dead file. The platform still had a small defect, an unreachable image produces a generic error instead of a clear one, and we noted it as a courtesy. But the three weeks were on us. New rule in the shop: never test with somebody else’s sample asset.
3. “Is your agency pulling spend at the end of the month?”
A store owner noticed orders sagged in the last week of every month and asked us, fairly, whether the ads vendor was easing off spend to hit a budget.
We pulled five months of daily ad data. Spend per day in the final week was flat or higher every month. Orders per day fell in the final week in four of the five months anyway. That is a customer rhythm, not a budget one. People buy less in the last week of the month. The vendor was cleared, in writing, with the numbers attached. Then we used the finding: the vendor agreed to front-load each month’s budget modestly so more of it lands when people are buying.
Why we work this way
Being wrong is not the problem. Staying wrong is. Each of these could have run for weeks on the tidy answer, and every one of them would have cost the client something: a pointless app change, a soured vendor relationship, a budget conversation built on a myth.
- We check the claim in a real browser or a real data pull before we send it.
- When we are wrong, we say so the same day, in writing, to the same people who heard the first version.
- We hold ourselves to the evidence standard we hold vendors to. Sometimes that clears them. That is fine. The client is paying for the right answer, not for a winner.
If your agency has never told you it was wrong about something, either it has never been wrong or it has never said. You can decide which is more likely.