March 2026 first-trial cohort, as implemented in the saved SQL
1 The gist · for everyone
Among mobile users whose started from 2 through 9 March 2026, 14.3% had a on after start.
6,894 of 48,210 trial users had a positive charge in the implemented window.
About 14 in every 100 users in the implemented first-trial mobile had a positive charge by day 14.
"In the saved March run, 14.3% of first recorded PixelPress Pro mobile trial users had a positive charge on days 0-14 after trial start."
"The new onboarding caused a 1.4-point lift," or "the metric used a 30-day window ending 8 March."
The does not match the readout: it uses a 14-day parameter, includes starts on 9 March, and does not show the test-account or refund exclusions described in the .
2 How it's built · for the curious
Jordan starts a first recorded on 4 March 2026, so day 14 is 18 March.
Result: Jordan counts as converted because the day-14 positive charge is inside the 's inclusive window. A first charge on day 15 would not count.
Now the general rule, one step at a time. Each step has the plain version, with the exact version one click away.
Step 1 · Who is counted
One PixelPress Pro mobile user.
One distinct user_id from app.trial_events after taking MIN(trial_start_date) per user for product = 'PIXELPRESS_PRO' and platform IN ('ios', 'android').
S3Step 2 · When the clock starts
Each user's clock starts on their first recorded PixelPress Pro mobile trial date.
trial_start_date is MIN(t.trial_start_date) per user_id from the trials CTE.
S3Step 3 · What counts
Counts a user if they had at least one charge above zero dollars in the window.
first_charge joins billing.charges where b.user_id = c.user_id, b.amount_usd > 0, and b.charge_date falls in the inclusive charge window, then groups to MIN(b.charge_date). The final summary counts DISTINCT f.user_id.
S3Step 4 · Combine
Divide users with a positive charge by all users in the implemented cohort.
ROUND(100.0 * COUNT(DISTINCT f.user_id) / COUNT(DISTINCT c.user_id), 2) AS conversion_rate_pct.
S3Step 5 · How sure
No or standard error was reported for the 14.3% headline.
Not covered by this range: Random uncertainty, data-quality uncertainty, and uncertainty from the definition discrepancies are not quantified.
conversion_summary.csv reports trial_users, converted_users, conversion_rate_pct, run_date, and data_complete_through only.
S43 Keep in mind · before you act on it
The and readout define conversion as payment within 30 days, but the parameter is 14 and the inclusive date comparison counts .
The README says the runs through 8 March, while the SQL includes starts through 9 March.
The README says internal, test, and refunded accounts are excluded, but the SQL shown here only requires amount_usd > 0 and does not filter internal users, test users, or refunds.
The readout quotes a 12.9% February rate and a 1.4-point lift, but the fixture includes no February result, comparison SQL, or uncertainty.
The saved output reports a estimate only. It does not include a , standard error, or sensitivity run.
| Tempting, but wrong | Accurate |
|---|---|
| 14.3% is the 30-day . | The saved SQL result is a positive-charge rate on days 0-14 after first recorded start. |
| The new onboarding caused a 1.4-point lift. | The files show a March rate and a quoted February comparison, but no design that isolates the onboarding effect. |
| The cohort is exactly 2-8 March. | The SQL includes first recorded trial starts from 2 through 9 March, inclusive. |
| Every trial start in the week is counted. | The SQL first reduces each user to their earliest recorded mobile trial, then keeps users whose earliest trial is in the cohort. |
| A always means a net-paid subscriber. | The SQL checks amount_usd > 0. The refund exclusion described in the README is not visible in the SQL. |
Chose: Use the 14.3% March conversion rate as the headline, because it is the first number in the readout and is backed by the saved CSV.
Could have chosen: Write a separate card for the 1.4-point March-versus-February lift.
Why: The February rate and lift are quoted in the readout but no February output or comparison code is included in the fixture.
What it changes: The card explains the measured March level and treats the lift as readout-only, not independently reproducible.
Chose: Describe the implemented SQL as days 0-14, rather than repeating the README's 30-day definition.
Could have chosen: Treat the README as authoritative and mark the saved SQL/result as incompatible with the stated metric.
Why: The skill says to trace the number to code and write from the implemented rule.
What it changes: Readers see that the 14.3% number is not evidence for a 30-day conversion rate.
4 Reproduce it · for specialists
| Population | Users whose earliest recorded PixelPress Pro iOS or Android trial started from 2026-03-02 through 2026-03-09, inclusive. |
|---|---|
| Exposure / contrast | None. This is a single-cohort descriptive rate. |
| Time zero | Each user's earliest recorded PixelPress Pro mobile trial_start_date. |
| Variable | Indicator for at least one billing.charges row with amount_usd > 0 and charge_date on day offsets 0 through 14 after time zero. |
| Intercurrent events | Refunds, internal/test status, and later trial starts are not handled in the saved SQL except that later trial starts do not change time zero. |
| Summary measure | Proportion of implemented-cohort users with converted_to_paid = 1, reported as a percent rounded to two decimals. |
README and readout define conversion as paying within 30 days of trial start.
params sets conversion_days = 14, and first_charge keeps charge_date BETWEEN trial_start_date AND DATE_ADD(trial_start_date, 14), inclusive.
Impact: A shorter window likely understates the 30-day conversion rate. The size is unknown from the saved files.
S1S2S3README says trials started 2026-03-02 through 2026-03-08.
SQL sets cohort_end to DATE '2026-03-09' and uses BETWEEN, so 9 March starts are included.
Impact: The implemented denominator can include an extra start date. Direction and size are unknown.
S1S3README says internal and test accounts are excluded.
No internal-account or test-account filter appears in the saved SQL.
Impact: If such accounts exist in app.trial_events, they remain in the result. Direction and size are unknown.
S1S3README says refunded charges do not count.
SQL joins billing.charges with b.amount_usd > 0, but shows no refund, reversal, or net-paid filter.
Impact: Refunded positive charges could overstate net-paid conversion. The size is unknown.
S1S3Descriptions say users who started a trial in the cohort week.
SQL first takes MIN(trial_start_date) per user across PixelPress Pro mobile trial events, then filters that first recorded trial into the cohort.
Impact: Users with an earlier PixelPress Pro mobile trial and another trial in March are excluded. Direction and size are unknown.
S1S2S3The readout says the new onboarding is driving a 1.4-point lift and recommends rolling it out to web.
The saved SQL computes a single March cohort rate only. No February cohort SQL, web cohort, counterfactual, adjustment, or uncertainty is included.
Impact: The fixture supports a descriptive March rate, not a causal onboarding claim or web rollout inference.
S2S3S4| Stage | Exact rule | Source |
|---|---|---|
| Eligibility 1 | app.trial_events rows where product = 'PIXELPRESS_PRO' and platform IN ('ios', 'android'). | S3 |
| Eligibility 2 | The trials CTE groups by user_id and sets trial_start_date to MIN(t.trial_start_date). | S3 |
| Eligibility 3 48,210 remain | cohort keeps rows where trial_start_date BETWEEN DATE '2026-03-02' AND DATE '2026-03-09', inclusive. | S3S4 |
| Time zero | trial_start_date is MIN(t.trial_start_date) per user_id from the trials CTE. | S3 |
| Positive-charge window [0, 15) days | b.charge_date BETWEEN c.trial_start_date AND DATE_ADD(c.trial_start_date, p.conversion_days), with conversion_days = 14. Because BETWEEN is inclusive, this is day offsets 0 through 14. | S3 |
| Had a positive charge indicator | first_charge joins billing.charges where b.user_id = c.user_id, b.amount_usd > 0, and b.charge_date falls in the inclusive charge window, then groups to MIN(b.charge_date). The final summary counts DISTINCT f.user_id. | S3 |
| Aggregate | ROUND(100.0 * COUNT(DISTINCT f.user_id) / COUNT(DISTINCT c.user_id), 2) AS conversion_rate_pct. | S3 |
| Uncertainty | conversion_summary.csv reports trial_users, converted_users, conversion_rate_pct, run_date, and data_complete_through only. | S4 |
| Group | Definition | Value | n |
|---|---|---|---|
| March 2026 first-trial mobile cohort | product = 'PIXELPRESS_PRO', platform IN ('ios', 'android'), MIN(trial_start_date) BETWEEN DATE '2026-03-02' AND DATE '2026-03-09'. | 14.3 | 48,210 |
| Name | Value | Meaning |
|---|---|---|
cohort_start | 2026-03-02 | First included first recorded trial date |
cohort_end | 2026-03-09 | Last included first recorded trial date in SQL |
conversion_days | 14 | Inclusive DATE_ADD endpoint for qualifying charges |
product | PIXELPRESS_PRO | Trial event product kept by SQL |
platforms | ios, android | Trial event platforms kept by SQL |
app.trial_eventsTrial starts and cohort assignment
Grain: trial event · Filters: product = 'PIXELPRESS_PRO'; platform IN ('ios', 'android'); MIN(trial_start_date) per user_id
billing.chargesPositive-charge outcome
Grain: charge event · Filters: amount_usd > 0; charge_date on days 0-14 after trial_start_date
results/conversion_summary.csvSaved summary used for the headline
Grain: one-row summary · Filters: trial_users = 48,210; converted_users = 6,894; conversion_rate_pct = 14.30
WITH params AS (
SELECT DATE '2026-03-02' AS cohort_start,
DATE '2026-03-09' AS cohort_end,
14 AS conversion_days
)SELECT t.user_id,
MIN(t.trial_start_date) AS trial_start_date
FROM app.trial_events t
WHERE t.product = 'PIXELPRESS_PRO'
AND t.platform IN ('ios', 'android')
GROUP BY t.user_idWHERE tr.trial_start_date BETWEEN p.cohort_start AND p.cohort_endJOIN billing.charges b
ON b.user_id = c.user_id
AND b.amount_usd > 0
WHERE b.charge_date BETWEEN c.trial_start_date
AND DATE_ADD(c.trial_start_date, p.conversion_days)COUNT(DISTINCT c.user_id) AS trial_users,
COUNT(DISTINCT f.user_id) AS converted_users,
ROUND(100.0 * COUNT(DISTINCT f.user_id) / COUNT(DISTINCT c.user_id), 2) AS conversion_rate_pctData complete through: 2026-04-17
Receipts:
Tests: No repository tests were included for this fixture. The card reproduces the headline from the saved CSV and records SQL-description discrepancies.
eval/fixtures/syn-a/README.md lines 1-21 · Question, prose definition, cohort dates, exclusions, and file listeval/fixtures/syn-a/readout.md lines 1-9 · Headline, February comparison, onboarding claim, and 30-day definitioneval/fixtures/syn-a/sql/trial_conversion.sql lines 1-43 · Implemented cohort, charge window, and aggregationeval/fixtures/syn-a/results/conversion_summary.csv lines 1-2 · Saved result rowCheck yourself
Write one or two sentences as if telling a colleague. Then compare with the checklist.
A complete explanation mentions: