Why your cohort retention dashboard is lying to you in Ramadan

A cohort retention curve is one of the most-trusted artefacts in a subscription-app dashboard. You acquire 1,000 users on Monday, you plot what percentage of them are still active each subsequent day, the curve drops fast and then slowly flattens, and the shape tells you something about your product-market fit, your onboarding quality, and your unit economics.

The curve works because of a quiet assumption built into it: that what happens to a user on day 14 after install is a function of the user’s day 14 in the product, not the calendar’s day 14 of the world. The curve treats the calendar as background noise. In MENA during Ramadan, this assumption breaks — and when it breaks, your dashboard becomes actively misleading rather than just imprecise.

The assumption, named

The standard cohort retention model says: take all users acquired on March 5. Track them. Plot the retention curve. The shape of that curve tells you about those users, modulo random noise that averages out at sufficient cohort size.

This is true if the world is calendar-uniform. If a user’s behaviour on day 14 looks roughly the same whether day 14 is March 19 or April 19 or June 19, the assumption holds and the curve is interpretable.

Ramadan breaks this assumption in three specific ways:

1. Engagement times shift. The same user, in the same product, behaves at 11pm-2am during Ramadan instead of 6pm-10pm. A push notification scheduled for 7pm that worked all year now lands in iftar and is silenced or ignored. The “drop in engagement” the cohort curve shows is not a drop in user interest — it is a drop in push-channel-deliverability against a behavioural pattern the system wasn’t tuned for.
2. Transactional decisions are deferred. Cancellation rates drop during the last 10 nights of Ramadan because users are spiritually disinclined to do “transactional housekeeping” in that window. The cancellations don’t disappear — they cluster in the first week after Eid. A cohort whose day 14 falls in the last 10 nights looks like it has unusually high retention; the same cohort’s day 28 looks like it has unusually high churn.
3. The acquisition source mix changes. During Ramadan the audiences active at different hours change. A campaign that reaches one demographic at 8pm in February reaches a different demographic at 12am in March. The cohort acquired through “the same campaign” on March 5 vs April 5 is not actually the same kind of user.

The cohort retention curve has no way to encode any of this. It treats all three effects as part of the user’s natural curve and reports them as such.

The Mar 5 vs Apr 5 example

Make this concrete with two cohorts acquired through the exact same Meta Egypt creative, same audience targeting, same bid strategy:

• Cohort A: acquired March 5, 2026. Day 14 falls March 19 — three days into Ramadan. Day 30 falls April 4 — last week of Ramadan.
• Cohort B: acquired April 5, 2026. Day 14 falls April 19 — one month after Eid al-Fitr. Day 30 falls May 5 — well into the post-Ramadan normal pattern.

Same product, same creative, same audience. The retention curves will look completely different:

• Cohort A’s D7 looks normal (early Ramadan engagement is roughly continuous with pre-Ramadan).
• Cohort A’s D14 looks weaker than expected (push notifications now misaligned, in-app engagement compressed).
• Cohort A’s D30 looks artificially strong (cancellations deferred to post-Eid).
• Cohort A’s D60 looks weaker than expected (deferred cancellations now cluster here).
• Cohort B’s D7, D14, D30 all look normal.

A team comparing “March cohort vs April cohort retention” and concluding “April creative is performing better” is reading noise as signal. The creative isn’t better. The April cohort just hasn’t been distorted by Ramadan.

The “Ramadan tail” pattern

Across audits we run, the most common Ramadan distortion signature is what we call the “Ramadan tail” — a retention curve that looks normal through D7, dips below baseline through D14-D21, recovers to above baseline through D30-D45 (because cancellations are deferred), and then crashes back to below baseline through D60-D90 (when the deferred cancellations finally come through).

If you take a flat 60-day cumulative retention number for that cohort, you get something roughly normal — the artificially-strong D30 cancels out the artificially-weak D60. But the shape tells the story. The same total retention number means very different things depending on whether it’s a Ramadan-distorted cohort or a structurally healthy one.

The “post-Eid catch-up” pattern

The mirror image: cohorts acquired in the week of Eid al-Fitr show unusually clean curves through D14 (no Ramadan distortion in the early window) and then unusually high churn at D30-D60 because the deferred-cancellation wave from earlier cohorts now sweeps through these too, even though they weren’t acquired during Ramadan.

This one is harder to spot because the cohort itself wasn’t acquired during the distortion window. The distortion is inherited from the broader user base’s transactional rhythm, not from the cohort’s own acquisition timing.

How to detect Ramadan-distorted cohorts in your data

Three signals to look for:

1. Cohort age + Ramadan calendar overlap. Calculate for each cohort whether days 7-30 of their retention window overlap with any segment of the local Ramadan calendar. If they do, flag the cohort.
2. Retention curve shape, not just retention number. Compare a cohort’s curve shape against the median curve from comparable non-Ramadan cohorts. A Ramadan-distorted cohort will show the “tail” signature even when the total retention number looks normal.
3. Cancellation timing distribution. A normal cohort distributes its cancellations roughly uniformly over the retention window. A Ramadan-distorted cohort distributes them in a bimodal pattern — depressed during Ramadan, clustered post-Eid.

What to do about Ramadan-distorted cohorts

Four concrete responses:

1. Don’t compare Ramadan-distorted cohorts against non-Ramadan baselines. If you must compare, compare against last year’s equivalent Ramadan cohort, not against the cohort acquired one month later.
2. Use longer retention windows. D60 or D90 for Ramadan cohorts; D30 is too noisy. The deferred-cancellation wave needs to land before the number stabilises.
3. Re-attribute deferred cancellations. If you’re calculating churn rate, separate the post-Eid cancellation spike into “Ramadan deferred” and “post-Eid voluntary” — the underlying user behaviour is different.
4. Pause cohort-based pricing decisions for the Ramadan window. If you’re running a paywall A/B test whose evaluation period overlaps Ramadan, extend the test or restart it post-Eid. The signal will be too noisy to interpret in that window.

How Madar handles this

Madar AI’s cohort retention queries automatically segment by Ramadan-overlap status — every cohort whose retention window touches the Ramadan calendar gets a separate cohort-tag, and comparisons across cohorts always check whether you’re comparing like-for-like or whether one side is Ramadan-distorted.

You don’t have to remember to filter manually. The reasoning layer knows the cultural calendar (see the seven cultural events post for the full list) and applies it automatically.

If you want to see whether your current cohort comparisons are being distorted, the live demo flags this in the first audit pass.