Your conversion rate dropped and nobody changed anything

"Nothing changed" is almost never true. It usually means nothing was deployed. Something was still edited: a price, a shipping rule, an app that auto-updated, a payment method that quietly disappeared. Here's the checklist for finding it, in the order that finds it fastest.

Updated September 8, 2026

“Nothing changed” is almost never true. It usually means nothing was deployed, which is a much smaller claim than it sounds, because most of what can move a conversion rate never goes near a deploy.

This is the order to look in. It is arranged by how often each one turns out to be the answer, not by how technical it is.

0. First, check the drop is real

Before hunting a cause, rule out a measurement failure, because a broken tag looks exactly like a broken funnel. Compare orders in your commerce admin against your analytics tool for the same days. If the admin is flat and analytics fell, nothing is wrong with your store, something is wrong with your tracking. A consent banner change, a tag manager edit or a blocked script will do this, and you can spend a week chasing a phantom.

1. Something changed in a dashboard, not in code

This is the largest category by a distance, and the one nobody has a record of. All of these take about fifteen seconds and take effect immediately:

  • A price, a compare-at price, or a coupon that expired or failed to revert after a sale
  • A shipping rule or zone that now excludes addresses that used to qualify
  • A payment method that disappeared from checkout after a settings change
  • A tax or currency setting that changed what one market sees at the last step
  • A CMS page republished with a broken link, a missing button, or a changed offer
  • An email flow paused, so a chunk of returning revenue silently stopped arriving

The person who made the change was usually right to make it, which is exactly why they did not announce it.

2. Something updated itself

Apps and integrations update on their own schedule. An app that changes how a bundle, discount or shipping rate is calculated can alter checkout behaviour with no human involved at all, which means it will not appear in any log you search by person. If your drop starts on a date nobody can account for, check what auto-updated in the twenty-four hours before it, not what anybody did.

3. A flag is at a different percentage than you think

Feature flags are designed to change behaviour without a deploy, which makes them the single most likely non-deploy cause and the easiest to forget. A rollout moved from 50% to 100% over a weekend is not a deploy, is not in your git history, and is very much a change.

4. Segment before you theorise

An average hides the shape of the problem. Split the drop by device, by browser, by country and by traffic source before forming a theory:

  • One device or browser only usually means a rendering or interaction regression from a theme or front-end change.
  • One country only usually means shipping, tax, currency or a payment method availability change.
  • One traffic source only usually means the change is upstream in that channel, not on your site at all.
  • Everything, evenly points back to sections 1 to 3, or to a tracking break.

5. Only then, look at code

By the time you get here you have usually already found it. Deploys are the most visible and best recorded changes you make, which is precisely why they are rarely the mystery. The deploy log is the one place everybody looks first and the one place the answer usually is not.

How to make the next one take ten minutes instead of a day

The fix is not a better dashboard, it is a shared record. One list, in time order, of every production-affecting change across every tool, that anyone can read. Once that exists, the investigation stops being archaeology and becomes a lookup: what changed in the six hours before the number moved?

You can start it by hand today, in a channel or a document, and it will work. Be warned that it usually dies within a month, because the discipline falls on the people with the least reason to maintain it.

Where Rearview fits

Rearview builds that timeline automatically. Changes from Stripe, Shopify, your CMS, your feature flags and your deploys land in one place, and anyone on the team can ask it in plain English rather than needing access to five admin panels.

Related reading: tracking what changed in a Shopify store, tracking Stripe pricing changes, and why a clean deploy log is not a quiet week.

Never wonder “what changed?” again.

Rearviewputs every production change on one timeline, so anyone on the team can ask. Join the waitlist and we'll let you know when it's ready.

Get early access →