Why Your CRM Flows Stopped Converting, and How One Tracking Event Can Throw Everything Off

A jewelry client comes to us with a simple symptom. Open rates holding at 61-62%, stable, nothing to flag. But the number of orders per click is tanking. 10 orders on a flow that did 37 the month before. Divided by three in a month, and we hadn't touched the content.

When this happens, the classic reflex is to tell yourself "the flow is tired, time to rebuild the content." Nine times out of ten, the flow is fine. And in this specific case, the content had nothing to do with it. The problem actually came from a tracking event firing at the wrong moment.

Look at post-click conversion, not open rate

When a flow drops off, the first thing everyone checks is the open rate. If opens are holding, you assume deliverability is fine and you go looking elsewhere. That's half true.

On this jewelry account, opens were spotless. 61%, 62%, stable week after week. So deliverability wasn't the issue. What was collapsing was post-click conversion. People were opening, clicking, and on the other side the cart was empty or the link pointed to nothing useful.

The revenue impact. Flows made up 9% of eShop revenue versus 12% the month before. And worse, some flows showed 0 euros in revenue. Zero. A flow that's running, sending emails, getting decent opens, but generating not a single cent. That means something is broken upstream, before the email even goes out.

Because if your tracking is feeding back incomplete or false data, it pushes you into terrible decisions. Either you tell yourself "this flow doesn't work anymore, I'm killing it," when in reality it's just wired wrong. Or you rebuild the content three times for nothing. Rotten data, you pay for it in bad decisions.

The root cause, an Add to cart event firing on a simple product view

Here's what we found when we reproduced the journey live.

You land on a collection page, that fires a normal Shopify event. So far so good. You click on a product page to look at it. And there, instead of just firing a "View product" event, the site SIMULTANEOUSLY fires a "View product" AND an "Add to cart" via API. Even though you added nothing to the cart. You just looked at the product.

The problem is obvious. A visitor who looks at a product page without adding anything to the cart should land in the browse abandonment flow. The one that follows up with "you checked out this product, do you like it?" Except with this parasite event, the system thinks they added to cart. So it moves them into the Add to cart flow.

The trouble kicks in once the Add to cart flow has grabbed this visitor. An Add to cart flow is supposed to point to a cart to restore. "Finish your order, your item is waiting." But since the person never added anything, there's no cart. So the email links to nothing. The cart link doesn't exist on an Add to cart flow when the cart is empty. The guy gets an email talking about an item he never put in his cart, and the button sends him into the void.

So the person misses the flow that would have converted them and lands in a broken flow that generates 0 revenue. That's why the orders collapsed.

The buggy event was erratic, which makes the diagnosis much harder

The worst part of this story: how the API event behaved over time. When we pulled the monthly history, here's what we saw.

22,000 events in April. 0 in May. Then 17,000 in May. 44,000 in June.

No logic to it. An event that goes from 22,000 to zero then back up to 44,000 without anyone touching anything is impossible to explain in the moment. Because until you pull that history, you have no idea the problem comes from there. You dig through the content, the segmentation, the deliverability, and the whole time it's an event spinning out on its own.

And it's not an isolated case. We'd already seen exactly the same bug on another brand, in food, grocery. Which wasn't even on the same Shopify theme. So it's not a dodgy template issue. It's something deeper in how API events fire, and it can hit any account. Which means if you're running Add to cart flows, you'd better go check how your event is wired.

The bonus complication, two Add to cart flows running in parallel

As if one buggy event wasn't enough, on this account there were also two Add to cart flows running at the same time. A history to untangle.

At the start, a single flow hooked to the native Shopify event. Then that Shopify event broke following changes on the site. Detected one to two weeks later, not right away. While we were fixing it, we cloned the flow onto the API event so we wouldn't lose revenue. And once the Shopify event was repaired, we left both running.

We left them both because the clone on the API event brought in an extra 4 to 5,000 euros in revenue, without pushing up unsubscribes. And we'd set up a mutual exclusion so the same person wouldn't get both versions and end up with duplicates. So on paper, keeping both made sense.

Except that when the API event spins out like I just described, having two flows hooked to different events makes the diagnosis even more painful. You have to untangle which flow pulls from which event, which one is behaving strangely, which one generates phantom revenue. It's a real audit job, not a two-minute fix.

The other rotten-tracking signals to check before rebuilding anything

Before concluding your flow is dead, go check these two things. They'll save you from rebuilding content for nothing.

First thing to check, the cookie banner that reappears on every visit. Even after the person accepted, the banner comes back every time. That's a sign the consent isn't being stored correctly. And if consent is shaky, your tracking collects data all over the place. You see people arriving but your events only half fire. It's often the same cause that breaks the journey your ads just launched onto the site, as I explain here.

Second thing, the real origin of your "place orders." On Klaviyo, we looked at where the orders triggering the events actually came from. Turns out, only 37% of "place orders" genuinely came from the web. The rest were POS orders, physical stores, coming through with a checkout started event then an Order. So those store orders were skewing the attribution of your flows and campaigns. You think a flow converts when actually it's a customer who bought in-store. It's the same kind of trap when attribution is broken between your ads and your offline sales.

Without segmenting web and POS, there's no way to trust the conversion rate per flow.

The audit method, in order

So when a flow drops off for no reason, I always do this before touching the content.

First I compare events across three sources. Klaviyo, GA4 and Shopify. If the numbers diverge heavily from one source to another on the same event, there's a wiring problem somewhere. That's the first place to look.

Then I pull the monthly history of each key event. That's what caught the 22,000 / 0 / 17,000 / 44,000 in the jewelry case. An event behaving erratically over time, and you already have 90% of the diagnosis.

Then I reproduce the journey live. I browse the site like an average customer and watch which events fire at each step. That's how we spotted the "Add to cart" firing on a simple product view. You can't find that by staying in the dashboard, you have to walk the journey yourself.

And finally I segment web versus POS, to strip out all the noise from store orders polluting the attribution.

Once you've done that, and only then, you can start asking the content question. In 90% of sudden-drop cases, the problem is upstream, in the tracking, not in the email. Before rebuilding a scenario, revisit which time of year it's actually worth testing what. But a flow at 0 revenue with stable opens, the problem is in the wiring. Fix the wiring, the content comes after.