Paying player retention
Open Journal -> Advanced Analytics -> Retention. This report measures accounts that pay again in subsequent calendar months after their first payment. It is payer retention, not site visits, game logins or registration cohorts. The examples below use training data.
Period and filters
Choose the first-payment dates, then the date through which repeat payments are observed. For example, you can follow 2025 cohorts into 2026 without adding new 2026 payers to those cohorts.
| Field | Selection |
|---|---|
| Project | All accessible projects or one project. Accounts in different projects are counted separately. |
| Game server | All servers in the selected project or one server. Select a project first. |
| Period | Today, the last 7, 30 or 90 days, the current or previous year, or custom dates. Initially, the range starts at the beginning of the month five months ago and ends today. |
| First payments from / Through (UTC) | Inclusive dates of the first known qualifying payment. Narrowing the range never turns an earlier payer into a new one. |
| Observe through | Last included day of repeat payments, no earlier than the elapsed first-payment period and no later than today. Use today for an unfinished period. |
| Months after first payment | Between 1 and 24 columns, default 6. This controls comparison width, not available history. |
| Rows per page | 10, 25, 50 or 100 monthly cohorts, default 25. |
All boundaries use UTC. Today includes only events that have already occurred. Refresh applies the conditions; reset restores defaults. Conditions are preserved in the page address. Available historical years can be selected without a ten-year limit.
Reading the matrix
First payment month groups accounts by their first qualifying payment within the selected dates. Accounts is the cohort size. A partial month, such as January 15-31, includes only accounts whose first payment occurred on those days.
For a January cohort, Month 1 is February and Month 2 is March. These are calendar months, not rolling 30-day periods after each payment. Payments on January 31 and February 1 fall in different months even when only minutes apart.
Cell percentage = accounts paying again in that month / cohort size x 100%. In the January example, 1 / 3 = 33.33%, with 1 of 3 underneath. Multiple payments by the same account in one month count once.
Months are independent: an account can skip February and return in March. A later column can therefore be higher than an earlier one. This is neither uninterrupted monthly payment nor cumulative return. Do not add percentages across a row.
| Card | Meaning |
|---|---|
| Monthly cohorts | Nonempty cohorts across the whole selected period, not just the current page. |
| Paying accounts | Combined cohort sizes. One account within a project belongs to one cohort. |
| Cohorts still forming | Cohorts whose selected first-payment interval has not finished. This is not the number of unfinished columns. |
A person with several accounts may be counted more than once. Accounts from different projects are not merged into one person.
Observation and unfinished months
- Completed month: the entire calendar month is observed. 0% means no repeat payment exists in the available history for that month.
- Month in progress: a clock and a warm background identify a partial result. The percentage covers only the observed portion, not a final full-month result.
- Month has not started: a dash and a calendar icon replace the percentage. This is an unknown future result, not zero.
Hover over a cell to see its calendar month and state. A clock beside the cohort name means new first payments can still enter the cohort, changing its size and percentages. The observation date appears below the matrix.
Change the observation date to examine an earlier result. Compare cohorts with equal numbers of completed months. Even completed historical months may be revised when delayed records arrive.
Server scope and eligible payments
The server filter applies to both first and repeat payments. An account may have paid elsewhere earlier; its first payment on the selected server determines the cohort for that server. Adding separate server reports need not equal the whole-project report.
Project-wide wallet top-ups without a server belong to the whole-project report but not to an individual server. Purchases follow the server associated with their payment.
Positive confirmed top-ups and purchases associated with an account qualify. Guest payments without an account, test payments, administrative credits and bonus grants alone do not create a paying cohort. Currency amounts are not added: an account paying in several currencies remains one payer.
A refund does not erase an earlier payment occurrence. Use payment statistics for payment amounts and refunds. Use the registration funnel for the registration, login and first-payment sequence.
Pages and longer comparisons
Cohorts run from newest to oldest. Next and Previous change pages; summary cards continue to cover the entire period. Changing filters or refreshing returns to the first page.
Increase the month count for a longer comparison and scroll the table horizontally. On wider screens, cohort names and account counts stay at the left.
If new records change the calculation between pages, or a page expires, the report asks you to refresh. Start again from the first page to browse a consistent calculation.
Empty results and errors
The report uses available history, which may arrive with a short delay. A missing record does not prove that a payment never happened. More complete early history improves first-payment attribution.
If the report is too large, select one project or server and try again. When temporarily unavailable, old figures are hidden and a warning replaces them, rather than an empty successful result. Refresh after connectivity returns.