Page body
What this page shows
FTD Cohort groups players by the date of their first successful deposit and then measures later behavior across follow-up periods.
When to use it
- evaluate post-FTD retention
- compare how many first-time depositors stay active later
- compare follow-up deposit behavior by PID or country
- analyze deposit momentum after the first deposit event
How to read it
Each base row is one cohort. The first deposit event defines the cohort date. The later columns are follow-up periods whose meaning depends on the selected cohort mode:
- daily
- weekly
- monthly
- custom-period buckets
The filter card exposes three metric-type labels:
ActivityDepositorsDeposit Amounts
Important reading rules:
- the current backend service does not branch by
metricType; the selected label is sent by FE but is not used in the traced service - visible period cells currently represent distinct cohort users seen after FTD in either gaming daily summaries or later successful deposit rows
- period
0is always set to100.00%for each cohort and for the total row - future periods are returned as
nullby the backend but are displayed as0.00%by the current FE percentage formatter
Filters that change the result
PIDCountryCohort ModeMetric TypeCustom Period (days)FTD Start DateFTD End Date- rows per page
Action and filter behavior
Apply Filterscopies the currently edited filter controls into the active query state and resets pagination to page 1.Refreshre-runs the last active query only. It does not apply staged changes that have not been committed withApply Filters.Export CSVuses the active filter snapshot and ignores the visible table pagination by requesting up to 10,000 cohort rows from the backend.- pressing
Enterin the PID field also applies the staged filters. - typing a PID and leaving the PID field adds it to the staged PID chips, but the active query still waits for
Apply Filtersor Enter. Custom Period (days)is only visible when cohort mode isSelected period (custom)and the FE clamps it to at least1.
Known caveats
- The cohort is defined by the first successful deposit only.
Metric Typeis currently not a verified backend switch. Do not readDepositorsorDeposit Amountsas separate backend formulas until the service starts branching onmetricType.- later-period values come from a union of gaming-summary activity and later successful deposits after FTD; the original FTD day is excluded from later periods by
> ftd_date. - The FE renders all metric cells as percentages.
- Exported CSV rows keep raw decimal ratios rounded to 4 decimal places, not the
%formatting shown in the table. - The
PIDfilter is implemented through thenx.user_kpi_summarydatabase table, but this page does not depend on annx-workspaceservice route. - When the backend reports more than 50,000 cohort rows, the page shows a warning banner that recommends narrowing the date range or filters before exporting.
totalCountcounts cohort buckets, not users.
Verification status
- status:
verified_backend - FE route, filters, export, metric-type caveat, and cohort-grid behavior are mapped
gs-admin-backendowns the cohort definition and current later-period aggregation logic- no explicit
nx-workspaceservice dependency is required for the current report semantics