The second-order cliff: why your best cohort never comes back

The most expensive four months in a consumer business look completely normal on a dashboard.

Revenue is flat. New customer acquisition is healthy — maybe up, because marketing is doing its job. Overall repeat rate has drifted down a point or two, which is inside the range it always drifts in. Nothing triggers an alert, because nothing crossed a threshold.

Underneath, the second-order rate for every cohort acquired after a specific Tuesday has fallen off a cliff, and the customers you paid to acquire in those four months are worth a fraction of what your model assumed.

You find out two quarters later, when the LTV assumptions in your acquisition budget stop matching reality.

Why the second order matters more than any other

The first purchase tells you your marketing worked. The second purchase tells you your business works.

Everything between those two events — delivery, packaging, onboarding, the first support interaction, the accuracy of what you promised — is compressed into a single binary signal. And because it's the first repeat decision a customer makes, it's the most sensitive one. A customer who has bought four times has a habit that will absorb a bad experience. A customer who has bought once has nothing invested.

This is why second-order rate moves before your churn number does, and why it's the leading indicator worth instrumenting first.

Strong association in the consumer businesses we work with, second-order rate reacts to operational changes roughly a quarter before those changes are visible in retention or LTV reporting. We're labelling this strong association rather than causal finding because we observe the sequence consistently but haven't run controlled tests on the lag itself.

Why aggregate repeat rate hides it

Because the aggregate mixes cohorts.

Your overall repeat rate this month contains customers acquired last month, six months ago, and two years ago. The long-tenured cohorts are stable and large, and they dilute everything. A catastrophic change affecting only new customers moves the blended number by fractions of a point for months before it becomes visible.

The fix is cohort analysis, and it's not sophisticated. Group customers by the week of their first order. For each week, calculate the percentage who placed a second order within a fixed window — 30, 60, or 90 days depending on your natural purchase cycle. Plot it.

You're not looking for a downward slope. Slopes are normal and usually seasonal. You're looking for a step: a specific week where the line drops and stays down.

A step change with a date is the most valuable object in this entire analysis, because a date is what makes causal inference possible.

From step change to cause

Once you have a dated step, you have half of a causal claim. Here's how to get the other half.

Find the dated change events. Pull every deploy, price change, policy change, supplier change, and third-party integration change in the two weeks around the step. Most teams have this in three or four separate systems — a deploy log, a CMS history, a Slack channel, someone's memory. Getting them onto one timeline is usually the hardest manual part of this work.

Build a comparison group. This is what separates a real finding from a plausible story. The change should have been experienced by some customers and not others. That split can come from:

• Geography, if the change rolled out by region
• Platform, if it shipped to iOS before Android or web before mobile
• A percentage rollout, if you use feature flags
• Timing, if you compare the cohort immediately before against the one immediately after

Check the mechanism. A cause you can't explain isn't a cause you should act on. If a checkout change reduced second orders, there should be a story about the customer's experience that makes sense — and usually corroborating evidence in support tickets, cart abandonment, or session data.

With a dated event, a comparison group, and a coherent mechanism, you have a causal finding. With the step and a plausible event but no comparison group, you have a strong association — worth acting on, but you should say which one you have.

The pattern we see most

The single most common cause of a second-order cliff is not a product quality problem. It's a surprise.

Something the customer wasn't expecting appeared at a moment when they'd already decided to buy. A shipping fee that showed up at the final step rather than on the product page. A delivery window that turned out to be longer than the one displayed. A subscription that auto-enrolled when they thought they were buying once. A tax line that appeared after they'd anchored on a price.

None of these are strictly deceptive. All of them produce the same result: the customer completes the first purchase, feels slightly worse about it than they expected to, and doesn't return.

This is why the fix is almost never a campaign. A win-back email to someone who felt ambushed at checkout performs badly, because they aren't hesitant. They're annoyed, and you're now emailing them.

What it costs

Compute it as forgone lifetime value, not forgone orders.

Customers acquired since the step change
  × (second-order rate before − second-order rate after)
  × marginal LTV of a repeating customer over a one-time customer
  = value destroyed, per segment

Then check that number against your acquisition spend over the same period. In most cases where this pattern is present, the business has been paying full CAC for materially less valuable customers for the entire duration — which means the leak has a second cost sitting inside the acquisition budget.

Who has to fix it

The reason this leak runs long is that the number belongs to Marketing and the cause belongs to somebody else.

• Marketing owns the Retain stage and sees the metric move first.
• Product and Engineering own the change that caused it and usually don't know the metric exists.
• Support is holding the corroborating evidence in ticket text, unread as a revenue signal.
• Finance owns the fee or pricing policy, if that's what changed.

In Flolyt, the Repeat & Decay agent opens a Room the moment a cohort curve steps, attaches the deploy timeline, and pulls in the owning teams. The point isn't detection speed on its own. It's that the engineer who shipped the change and the marketer watching the metric end up in the same place, looking at the same chart, before anyone has built a narrative.

The play

• Revert or fix the change, if the causal evidence supports it. Owned by Product.
• Do not launch a win-back campaign first. Fix the cause, then decide whether the affected cohort is worth recovering.
• Re-present the surprise earlier in the journey. Fees, timing, and terms disclosed before the buying decision cost you some conversion on the first order and protect the second.
• Instrument the cohort curve as a monitored signal, so the next step change surfaces in days.

How you'd know it worked

Compare second-order rate for cohorts acquired after the fix against cohorts acquired before it, at the same maturity — 30 days out compared to 30 days out. Never compare a young cohort against a mature one; that comparison always flatters the mature cohort.

If you also run a win-back to the damaged cohort, hold out 10% of it. Recovering customers who would have returned anyway is the most common way to overstate a win-back's value.

What we can't tell you yet

We can't tell you the natural rate of decay for your category. Second-order benchmarks vary enormously by price point, purchase frequency, and product type, and most published figures blend categories in ways that make them useless for a specific business. Your own historical curve is a better baseline than anyone's benchmark.

We also can't always find the dated change event. Some organizations don't keep a deploy history that maps to customer-facing behaviour, and when the timeline doesn't exist, the honest label is insufficient evidence — plus a note about what to start logging so the next investigation has something to work with.