How to Analyze SaaS Cohorts Using AI
Build cohort retention tables from first-paid month, compare customers at equal tenure, and keep immature periods out of the comparison with Cube.
- Define the cohort event
- Measure retention at equal tenure
- Separate incomplete windows
What is customer cohort analysis with AI?
Customer cohort analysis groups customers by a shared start event and measures later activity at the same elapsed time. This workflow uses the month of a customer's first paid subscription as the cohort, then measures paid-active customers at each later month-end. SaaS teams can compare cohorts or break them down by acquisition channel when that dimension is modeled.
An AI agent can query modeled metrics through Cube and arrange the results by cohort and tenure. This is historical analysis: it does not predict renewals or establish why a customer cancelled. If a tenure month is incomplete, leave it unreported rather than treating it as zero retention.
Define the cohort before comparing it
Choose the first-paid event, customer eligibility rules, timezone, and month-end retention rule. Keep the original cohort size as the denominator at every tenure month.
| Metric | Illustrative example |
|---|---|
| Cohort event | First successful paid subscription; 120 February customers, 100 March customers, and 80 April customers (UTC). |
| Fixed denominator | The February cohort stays at 120 customers; 96 active at March month-end gives 96 / 120 = 80% at M1. |
| Retention numerator | Count original cohort members with a paid subscription active at the later month-end, using the model’s status definition. |
| Tenure window | M1 is the first full calendar month after acquisition: February M1 is March 1–31; M2 is April 1–30. |
| Segmentation | Assign acquisition channel at first paid date; compare each channel using its own fixed cohort size. |
Copy. Paste. Run your cohort review.
Connect to Cube via MCP or the CLI, then run the prompt below in your preferred agent.
Start with a Cube deployment connected to your data and a model containing the metrics you want to analyze.
Connect over MCP
Connect your agent to your existing Cube deployment and sign in through OAuth.
https://cubecloud.dev/mcp
Complete OAuth in your agent to connect your Cube account.
Use your default deployment or select another one available to your account.
Connect with CLI
Install the Cube CLI and sign in from a terminal-capable agent.
curl -fsSL https://raw.githubusercontent.com/cube-js/cube/master/install-cli.sh | sh
cube login --url https://TENANT.cubecloud.dev
cube spec --json
02Run this prompt in your agent
Choose your agent and copy the prompt below.
Use the Cube MCP server connected in Codex and select the intended deployment. Run read-only analytics queries. Run a customer cohort retention review using my connected Cube deployment.Use read-only requests and do not return customer identifiers. DEFINITIONSInspect the semantic model and report the approved cohort metric, customergrain, event definition, timezone, and eligibility filters. If a requiredmetric or input is missing, explain the gap instead of inventing a result.Use the model’s approved first-paid event and calendar timezone. The defaultcohort is distinct eligible customers whose first successful paidsubscription falls in a calendar month; apply only modeled exclusions fortrials, tests, or internal accounts.Keep each cohort’s original eligible customer count as the denominator forevery tenure month. M0 is that baseline cohort month. M1 is the first fullcalendar month after acquisition, M2 is the next full month, and so on.For each later month-end, count original cohort members with a paidsubscription active at that point, following the model’s status definitionfor cancellations or reactivations. State that rule. If the model cannotdistinguish these states, report the limitation. ANALYSIS1. Use the last six complete first-paid calendar months through the latest complete month with source data. State the exact cohort date ranges, timezone, and month-end snapshot dates used for every tenure point.2. For every cohort and each matured tenure month, show retained customer count, fixed cohort size, and retention rate. Compare cohorts only at equal tenure. Do not change the denominator or average cohort rates.3. Where modeled, compare acquisition channels or plans as recorded at the first-paid event. Show each segment’s numerator, denominator, and rate; flag small samples. Report revenue retention separately only if an approved metric exists, with its own numerator and denominator.4. Mark a month that has not matured as “Not yet mature.” Mark missing source data as “Not available”; do not treat either case as zero. OUTPUTReturn the metric definitions, cohort table, query context, and a conciseinterpretation. Separate observed patterns from hypotheses about causes.Do not infer causation, predict renewals, or invent customer results.Recommend follow-up checks that can test any proposed explanation.
How it works
Confirm the cohort event
Check the first-paid timestamp, customer grain, timezone, and eligibility filters. A free-trial signup and a first paid subscription create different cohorts.
Align customers by tenure
Keep the starting cohort count fixed, then calculate month-end activity for M1, M2, and later full months. Show counts with rates and mark periods that have not matured.
Compare cohorts and segments
Compare the same tenure month across cohorts, then inspect modeled acquisition-channel or plan groups. Treat differences as patterns to investigate, not proof of what caused a customer to stay or leave.
Read cohort retention at the same tenure
The chart shows fictional first-paid cohorts and their month-end retention through May 31. Each rate uses the original cohort size; a dash marks a tenure period that is not yet mature.
| First-paid cohort (UTC) | Cohort size | M0 baseline | M1 | M2 | M3 |
|---|---|---|---|---|---|
| February | 120 | 120 / 120 (100%) | 96 / 120 (80%) | 84 / 120 (70%) | 72 / 120 (60%) |
| March | 100 | 100 / 100 (100%) | 82 / 100 (82%) | 70 / 100 (70%) | Not yet mature |
| April | 80 | 80 / 80 (100%) | 64 / 80 (80%) | Not yet mature | Not yet mature |
- The February cohort has 96 of 120 customers active at March 31 (80% at M1), 84 at April 30 (70% at M2), and 72 at May 31 (60% at M3). Its M1-to-M3 rate fell by 20 percentage points.
- M1 retention is 80% for February, 82% for March, and 80% for April. These tenure-matched values are descriptive; they do not explain the small differences or establish a cause.
- March M3 and April M2–M3 are not yet mature as of May 31. They are unobserved windows, not zero-retention results.
This worked example and the chart use fictional values, not executed queries, a customer result, a benchmark, or a prediction. Real results depend on the modeled cohort event, eligibility rules, status history, and complete source data in your Cube deployment.