Payment gaps

Report and Filters

Open Journal -> Advanced Analytics -> Payment gaps. The report shows how the time since a player's last payment compares with their usual interval. It does not explain the cause or predict that the player will leave.

Field	Purpose
Project	All authorized team projects or one project. The same account in different projects remains separate.
Game server	All project servers or one server. Select a project first.
Period	A calendar preset, year or custom dates.
From (UTC) / Through (UTC)	Included payment-history days. Today ends at calculation time. A past period is observed through its end, not through today.
Minimum payments	2 to 100; default 3. Fewer payments produce short history.
Extended gap, % of mean	First boundary; default 150%, strictly above 100%.
Long gap, % of mean	Second boundary; default 200%, strictly above the first.
Very long gap, % of mean	Third boundary; default 300%, above the second and at most 10,000%.
State	All states or one state. Summary cards still cover all payers in the selected history.
Currency	One currency and precision. Without a selection, the first available code and precision are selected.
Rows per page	1, 10, 30, 50 or 100; default 30.

Press refresh after editing filters. Reset restores the last 90 days, all projects and default boundaries. Filters persist in the page address; reopening starts at the first page.

Cards show payers and their states. Below them are payers without a measurable interval, guest payment count and guest receipts. Guests are not combined into a fictional player or assigned a personal gap. The USD example contains 108 payers.

History across 2025 and part of 2026. One currency; cards cover the complete selected history.

Mean Interval and Boundaries

Each player's distinct payments in the selected history are counted. The mean interval is the elapsed time between the first and last payment divided by payment count minus one. The first payment does not contribute an artificial zero interval.

The current gap is the time since the last payment until observation ends. The ratio to the mean is displayed as a percentage. Elapsed time includes payments within the same day. Fractional days and percentages are rounded only for display.

With a 2-day mean, a 3-day gap = 150%, 4 days = 200%, and 6 days = 300%. Boundaries must be exceeded strictly: exactly 150% stays within the first boundary, exactly 200% is extended, and exactly 300% is long.

State	Default condition
Within usual interval	At most 150% of the mean. This label includes the configured tolerance; it does not promise a future payment.
Extended gap	Above 150% and at most 200%.
Long gap	Above 200% and at most 300%.
Very long gap	Above 300%.
Short history	Fewer than three payments; controlled by Minimum payments.
No measurable interval	Enough payments, all recorded at exactly the same time. No percentage is calculated.

The state filter narrows the list without reducing the summary cards to visible rows.

Extended Gap

The first deviation group identifies moderately longer gaps. Consider the player history and project circumstances before taking action.

Default boundaries: strictly above 150% and at most 200% of the mean.

Long Gap

The next group exceeds the second boundary. Compare both the percentage and actual days: the same percentage can represent very different elapsed time.

Payment count, receipts, dates, mean interval and current gap are available together.

Very Long Gap

This group exceeds the third boundary. It does not prove that the player has stopped logging in or abandoned the project.

A gap above 300% of the mean, with payment history and receipts available for inspection.

Short History

When payment count is below the selected minimum, the gap is not classified against percentage boundaries. A single payment has no mean interval. Two payments have a measurable interval but still qualify as short history with the default minimum of 3.

Insufficient payment history is not treated as a long gap or a departure.

Simultaneous Payments

Separate payments can be recorded at the same instant. A zero mean has no meaningful percentage. These players receive a separate state while their current gap and receipts remain visible.

Separate GBP example: three payments at one instant. No infinite percentage or fabricated mean.

Changing Boundaries

Lower boundaries flag more gaps. Raising the minimum requires more payments before assigning one of the four interval groups. These controls change the report, not the payments or their dates.

Minimum 2 payments with 120%, 180% and 250% boundaries. Percentages must increase.

Player Rows and Pages

Column	Contents
Player	Email, identifier and project. The link opens the profile when the staff member may view it. Deleted or missing accounts are identified explicitly; payment history remains.
Payments	Distinct payments, not settlement installments.
Receipts	Received amounts for those payments through observation, in the selected currency.
First / last payment	First date above, last date below, in the panel timezone. Filter days use UTC.
Mean interval, days	Elapsed time between first and last payments divided by the number of intervals.
Current gap, days	Elapsed time from last payment until observation ends.
Gap / mean	Percentage of the mean when there is enough history and a positive mean.
State	Comparison with configured boundaries.

Players with the oldest last payment come first. Ties have stable ordering. Previous and next controls appear below the table. Changing filters restarts the list. If newly received data affects the report during paging, refresh the first page when prompted.

Continue beyond the first 50 players without silently truncating the result.

Projects and Servers

A server selection limits payment history to that server. Payments without a server belong to the all-servers selection. Changing project clears the previous server.

The same calculation restricted to an authorized project and its selected server.

Currencies and Eligible Payments

Different currencies and precisions are never added together. Changing currency changes both the payer list and their history. No exchange-rate conversion is performed.

Positive real customer-funded top-ups and purchases qualify. Test and administrative credits do not form a payment habit. Receipts are not net profit: fees and refunds are not deducted.

Installments of one payment are added together, but the first receipt remains its payment time. A later installment does not start a new interval. If a payment began before the selected period, its later installment does not become a new payment within that period.

EUR receipts and intervals remain separate from USD and GBP.

Historical Periods

Select a year or a custom range within stored history from 1900 onward, without a separate ten-year cap. A past range ends observation at that range end. Historical payments are not compared with today. A short selected window can contain few payments even for an old account.

The example selects 2025. Totals and gaps correspond to the end of that year.

Empty Results and Failures

An empty list means no payers match the currency, history and state. Guest receipts may exist independently. An explicitly selected currency without history remains selected; another currency is not substituted silently.

When data is unavailable, the panel shows an error and removes previous results. Do not interpret a load failure as no payments. Refresh after recovery.

The report describes received observations. Late information can change intervals and groups. Inspect a specific payment in the payment journal.

An empty historical range with zero totals, distinct from a loading failure.