Skip to content

Bronze-Y Renewal Outcomes: 2025 vs 2026

Date: 2026-05-15 Question: For users whose annual Bronze (Bronze-Y) subscription ended in Feb–May, what did they do next, and how does 2026 compare to the same period in 2025? Source: ClickHouse — sadb_invoices × sadb_transactions

At the same 3.5-month observation depth, Bronze-Y retention is 11 percentage points better in 2026 than in 2025 (46.1% vs 35.1%). The improvement is almost entirely accounted for by the new Basic (999 SAR/yr) tier capturing users who would otherwise have churned at the end of their Bronze-Y subscription — Bronze-Y renewal rate itself is slightly higher in 2026, and Silver-Y upgrade rate is essentially unchanged. Basic is retaining marginal customers, not cannibalising existing renewals.

Distinct users with at least one Bronze-Y invoice whose end date (payment_time + 1 year) falls in the analysis window:

  • 2025 cohort: 1,212 users (subscriptions ending 2025-02-01 → 2025-05-15)
  • 2026 cohort: 759 users (subscriptions ending 2026-02-01 → 2026-05-15)

The 37% cohort-size drop reflects fewer Bronze-Y acquisitions a year prior (Feb–May 2024 vs Feb–May 2025); it is not a retention signal. That is a separate top-of-funnel question worth diagnosing on its own.

Each year’s cohort is observed only through May 15 of the same year — i.e., both have ~3.5 months of post-window observation. The middle column shows the full-year outcome for the 2025 cohort (observed through 2026-05-15) as a forecast hint for 2026.

Outcome2025 (at +3.5mo)2025 (full year)2026 (at +3.5mo, current)
Cohort1,2121,212759
Renewed Bronze-Y311 (25.7%)412 (34.0%)216 (28.5%)
Upgraded Silver-Y65 (5.4%)92 (7.6%)37 (4.9%)
Upgraded Golden-Y000
Downgraded Basic0 (not offered)0 (not offered)95 (12.5%)
Pro-Y25 (2.1%)22 (1.8%)0 (sunset)
Bronze-M (legacy)24 (2.0%)33 (2.7%)2 (0.3%)
Silver-M (legacy)04 (0.3%)0
Total retained425 (35.1%)647 (53.4%)350 (46.1%)
Churned787 (64.9%)565 (46.6%)409 (53.9%)
  1. +11 pp retention vs 2025 at the same observation depth. 46.1% vs 35.1%. This is the strongest year-over-year retention improvement the subscription product has shown.

  2. Basic ≈ marginal retention, not cannibalisation. The 12.5% Basic share roughly equals the 11 pp churn improvement. Bronze-Y renewal rate is higher in 2026 (28.5% vs 25.7%) and Silver-Y upgrade rate is essentially flat (4.9% vs 5.4%). Users who buy Basic at renewal are users who would otherwise have left.

  3. The 2025 trajectory implies 2026 retention will keep climbing. Between month 3.5 and month 12, 2025 retention grew from 35.1% → 53.4% (+18 pp) as users made delayed decisions. If 2026 follows the same curve, end-of-year retention would land around 63% — well above 2025’s final 53.4%. Worth re-running this query at year-end to validate.

  4. Pro-Y has effectively disappeared. 22 users went to Pro-Y in 2025, zero in 2026.

  5. Legacy monthly absorbed 2.0% of 2025 Bronze-Y exits. Basic now does 6× the work that Bronze-M ever did at this transition. The product fills a real demand that monthly was only partially serving.

Caveat: Bronze-M is not exactly comparable to Basic

Section titled “Caveat: Bronze-M is not exactly comparable to Basic”

In 2025, Bronze-M (229 SAR/mo, ~2,750 SAR/yr if fully paid) was an option for cost-conscious users who didn’t want to pay 1,999 SAR upfront. In 2026 Basic (999 SAR/yr fixed) is dramatically cheaper. Some of the 12.5% Basic share would have gone to Bronze-M; some would have churned. The categories overlap but aren’t substitutable. The clean way to separate these would be to model 2025 Bronze-M cohort retention separately — covered in the Basic-replaces-Monthly Simulator.

-- Bronze-Y subscription end → next action, with observation capped at
-- May 15 of the same year to match windows across cohorts.
-- Toggle the BETWEEN dates and the <= cutoff for each year.
WITH qualifying AS (
SELECT
ft.user_id AS uid,
max(i.payment_time) AS qpay
FROM sadb_invoices i FINAL
JOIN sadb_transactions ft FINAL
ON i.transaction_id = ft.transaction_id AND i.payment_type = 'FIAT'
WHERE i._peerdb_is_deleted = 0
AND i.type = 'INVOICE'
AND ft.transaction_type IN (1, 36) -- Bronze-Y new + renew
AND toDate(addYears(i.payment_time, 1))
BETWEEN '2026-02-01' AND '2026-05-15' -- swap year for 2025 run
GROUP BY ft.user_id
),
latest_action AS (
SELECT
ft.user_id AS uid,
argMax(ft.transaction_type, i.payment_time) AS last_tt,
max(i.payment_time) AS last_pay
FROM sadb_invoices i FINAL
JOIN sadb_transactions ft FINAL
ON i.transaction_id = ft.transaction_id AND i.payment_type = 'FIAT'
WHERE i._peerdb_is_deleted = 0
AND i.type = 'INVOICE'
AND ft.user_id IN (SELECT uid FROM qualifying)
AND ft.transaction_type IN (1, 36, 3, 38, 89, 90, 95, 2, 37, 54, 72, 74, 86)
AND toDate(i.payment_time) <= '2026-05-15' -- observation cap
GROUP BY ft.user_id
)
SELECT
multiIf(
la.last_pay <= q.qpay, 'Churned (no further action)',
la.last_tt IN (1, 36), 'Renewed Bronze-Y',
la.last_tt IN (3, 38), 'Upgraded to Silver-Y',
la.last_tt IN (90, 95), 'Upgraded to Golden-Y',
la.last_tt = 89, 'Downgraded to Basic',
la.last_tt IN (2, 37), 'Pro-Y',
la.last_tt IN (54, 72), 'Bronze-M (legacy)',
la.last_tt IN (74, 86), 'Silver-M (legacy)',
'Other'
) AS outcome,
count() AS users,
round(count() * 100.0 / (SELECT count() FROM qualifying), 1) AS pct
FROM qualifying q
JOIN latest_action la ON q.uid = la.uid
GROUP BY outcome
ORDER BY users DESC
  • End date is computed implicitly as payment_time + 1 year. No subscriptions table exists; invoices are the source of truth.
  • Cohort anchor is the user’s latest qualifying Bronze-Y. A user with multiple Bronze-Y subscriptions whose ends fall in window is anchored at the latest one. This means anyone who renewed Bronze-Y within the window appears anchored at the renewal — preventing double-counting and ensuring the “next action” check covers actions taken after the most recent Bronze-Y purchase.
  • la.last_pay <= q.qpay detects churn. If the user’s most recent subscription invoice across all packages is still the qualifying Bronze-Y itself, they took no further action.
  • The IN (SELECT uid FROM qualifying) filter is load-bearing for performance. A naive correlated join (JOIN ... ON ft.user_id = q.uid) times out at 30s. ClickHouse plans the IN form as an early-stage filter on the large invoice table.
TypePackage
1Bronze-Y new
36Bronze-Y renew
3Silver-Y new
38Silver-Y renew
89Basic
90Golden-Y new
95Golden-Y renew
2Pro-Y new
37Pro-Y renew
54Bronze-M new
72Bronze-M renew
74Silver-M new
86Silver-M renew