Why retention fell when every segment improved

Published October 3, 2026

Your return rate fell from 74% to 67%. But when you split the audience into two segments, both improved by five percentage points.

Before looking for a broken feature or a bad campaign, check who is in the denominator.

In this synthetic example, a larger share of eligible people now belongs to the lower-return segment. The change in audience mix outweighs the improvement within each segment. churn.fyi separates those contributions. Its SQL-to-CSV starter kit shows how to prepare the underlying counts without sending raw activity events to the calculator.

The seven-point drop hiding two improvements

Here are the counts:

Segment A's return rate rises from 80% to 85%. Segment B's rises from 50% to 55%. Yet the overall rate falls:

• Baseline: 740 returned out of 1,000 eligible people, or 74%
• Current: 670 returned out of 1,000 eligible people, or 67%

Segment B grows from 20% to 60% of the eligible audience. Averaging the two segment rates equally would miss that change. The overall rate needs to use the actual people counts.

The calculator's symmetric midpoint decomposition divides the seven-percentage-point decline into −12 points from audience mix and +5 points from within-segment rate changes. Those add back to −7 points.

For each segment, the mix contribution is its change in eligible share multiplied by its average return rate across the two comparisons. The within contribution is its change in return rate multiplied by its average eligible share. This convention divides the interaction equally between the two components.

These are descriptive contributions. They don't establish that moving people between segments caused a change, or explain why either segment improved. All the people and events in this example are invented.

Decide what a return means

The metric here is next-period return rate: among distinct people active in one complete calendar month, how many perform the qualifying activity in the immediately following month?

It isn't automatically new-user cohort retention, subscription cancellation, or permanent churn. Someone who doesn't return in July may return in August.

The starter kit compares June activity followed by July returns with August activity followed by September returns, all in UTC. A qualifying event is a product_action. Each person gets the segment on their earliest qualifying base-month event, with the unique event ID breaking timestamp ties. That assignment stays fixed for that comparison. Missing segments become Unknown.

Write down your own identity, activity, window, and segment rules before adapting the query. Joining today's customer profile onto historical activity can quietly rewrite yesterday's segments.

Start with the four-column file

The calculator accepts aggregate counts with exactly this header and column order:

comparison,segment,eligible,returned
baseline,Segment A,800,640
baseline,Segment B,200,100
current,Segment A,400,340
current,Segment B,600,330

Download the reference CSV and the matching metadata. Open both in the calculator and read its three confirmations before checking them. Importing metadata doesn't confirm those assertions for you.

Those files reproduce the 74% to 67% result. The separate 21-event fixture is for hand-auditing counting rules; it deliberately produces a different result. Raw events aren't calculator input.

Run the query against synthetic events

The starter-kit guide includes the query, expected outputs, counting rules, and execution instructions. Download the reference SQL seed and query.sql; no repository access or Node.js installation is needed.

In a scratch query session on an already authorized SQL Server or Azure SQL database, open the downloaded core-seed.sql, append query.sql, and execute them together in the same session. The seed creates temporary tables; a separate connection won't see them.

The query keeps one qualifying base row per person, then uses EXISTS to check for return activity. This avoids a common counting error: joining every base event to every return event and multiplying people. Repeated activity doesn't increase eligibility or return counts. A person seen only in the return window cannot enter the numerator.

Export only the final result as UTF-8 CSV with headers and proper CSV quoting. Exclude row numbers, SQL messages, and extra index columns. Keep counts as integer text without separators or percent signs. Compare the export with the reference CSV, then load it with the metadata.

The starter kit was tested on SQL Server 2019 Express LocalDB. It checked actual SQL-produced CSVs against the independent reference and calculator, including an absent segment, and checked four expected input rejections. That is engine evidence for these fixtures; Azure connectivity, permissions, and production performance still need testing in your environment.

Check the edges before using real counts

The example intentionally supports complete UTC calendar months. Its boundaries include the start and exclude the end. An event at exactly October 1 is outside September's return window. Changing the timezone label alone won't convert the query; local-time and daylight-saving boundaries need explicit adaptation and tests.

Confirm upstream completeness separately. A recent event timestamp doesn't prove that earlier events have finished loading.

Keep both comparison rows for every observed segment. If one side has no eligible people, export 0,0; the calculator shows overall rates without inventing a segment rate or decomposition.

Finally, inspect the export for small or identifying groups. Analysis runs in the browser, with no database connection or analysis backend. Page-view analytics are present, but analysis inputs and results aren't included in those requests. Downloads and clipboard exports can persist on your device. Keep raw events, customer identifiers, credentials, and confidential source data in your authorized environment.

Start with the synthetic file, reproduce the seven-point bridge, and then audit your own denominator. The next conversation about a falling return rate can begin with the counts behind it.