Program Analytics
Open Users -> Partner Program -> Analytics and select a project.
Participants
Open Participants for the selected project. Each row represents an accepted referral relationship: the inviter, the player who accepted the invitation and the relationship state. This is not a registration list; meeting the conditions again does not add another participant to the report.
Filters
| Field | Meaning |
|---|---|
| Period | A preset, current or previous year, or custom dates |
| First accepted from / through | First invitation acceptance dates. Both dates are included and days use UTC. There is no limit on the number of years |
| Grouping | Automatic, days, weeks, months or years; changes the chart without changing the selection |
| State at period end | The latest known state before the selected period ends. A current or future period uses changes already received |
| Player | An exact player ID or full email address. Either side of the relationship can match, within the selected project only |
| Per page | 25, 50 or 100 relationships |
Use refresh to apply filters or reset to return to the initial selection. A missing player produces a message rather than an unfiltered list. Relationships belong to the whole project, so this report has no game-server selector.
Metrics and states
| Metric | Meaning |
|---|---|
| Relationships accepted in period | Relationships first accepted during the selected dates and matching the other filters |
| Distinct inviters | Different inviting players in that selection |
| Active relationships | Accepted and qualified relationships |
| Qualified relationships | Relationships that meet the program conditions; included in the active count |
| Suspended relationships | Relationships with suspended participation |
| Ended relationships | Previously accepted relationships subsequently rejected or reversed |
Accepted means the invitation has been recorded. Qualified means the program conditions have been met. Suspended indicates paused participation. Rejected and Reversed remain in the history of a previously accepted relationship. An unsuccessful invitation attempt that never established an accepted relationship is not included.
The chart groups relationships by first acceptance date. Metrics and chart values cover the entire filtered selection, not just the visible page. When complete history is unconfirmed, missing intervals remain unknown rather than zero. Distinct inviters are counted across the whole period: the same player does not become multiple inviters across different dates.
Period and grouping
Use monthly grouping for the current year. Partial months contain only events within the selected dates; the future part of a period is not counted.
For long history, choose custom dates and yearly or automatic grouping. This example starts in 1900 without inventing historical events. Dates and grouping remain selected after reloading the page.
Weekly grouping makes a shorter period easier to compare. Overall counts keep the same meaning and do not add distinct players from separate intervals.
If the grouping is too detailed for the range, a message appears. Select larger intervals or a shorter period; the chart is not silently truncated.
List and refresh
Relationships are ordered from most recently accepted to oldest. Rows show acceptance and state-change times, both players' email addresses and IDs, and the inviter's relationship count within the selection. The final button opens the inviter's details. If an email is no longer available, the player ID remains visible.
Next continues with the same calculation time, overall metrics and chart. Previous returns to the preceding page; returning to the first page recalculates the data. Changing filters or refreshing also starts again from the first page. If the browsing session expires or a late change affects participants, a message asks you to refresh the list.
Search by full email or ID to select relationships in which that player is the inviter or referred player. Metrics and the chart are recalculated for that selection.
When no relationships match the selected dates, the table and chart show an empty state. This is different from a loading error.
The first page refreshes every 30 seconds while visible and filters are not being edited. Subsequent pages pause automatic refresh. The calculation time appears above the chart, and processing delays produce a warning. Unavailable data shows a retryable error instead of zero metrics.
Referral rewards
Open Referral rewards for the selected project. The report includes completed achievement and invitation rewards, payment-related accruals and clan rewards. Pending deliveries are not included yet. Reversed accruals are excluded; transferring previously earned funds is not another reward.
Filters and metrics
Select all servers or one server and the completion date range. There is no limit on the number of years. Both dates are included and day boundaries use UTC. For a period that has not ended, only events that have already occurred are counted. Reprocessing an award does not change its first completion date or increase its count. All servers also includes project-wide wallet awards; they are not assigned to a specific server.
| Field | Meaning |
|---|---|
| Game server | All servers, including project-wide wallet awards, or one accessible server |
| Period | Today, the last 7, 30 or 90 days, this year, last year or custom dates |
| Awarded from / through | Inclusive completion dates; editing dates switches the preset to custom |
| Grouping | Automatic, daily, weekly, monthly or yearly chart intervals |
| Observation, days | From 1 to 90 days after the recipient's first reward inside the selected period |
Press refresh to apply. Filters remain in the page address and are restored after reloading. The report period and observation window are independent: a multi-year report can observe payments within seven days after each recipient's first reward.
| Metric | Meaning |
|---|---|
| Completed awards | Distinct completed, non-reversed awards in the period |
| Recipients | Distinct players who received those awards |
| Awards with items | Awards containing at least one item, not the number of individual items |
The chart groups completed awards into the selected calendar intervals. Missing history is not replaced with zeros. The table below groups awards by kind. One player may receive awards in several intervals and several kinds, so recipient counts across rows do not necessarily add up to the overall total.
Credited amounts keeps each credited currency separate. Different currencies are neither summed nor converted into each other. This is the currency received as a reward, which may differ from the referred player's payment currency. Item awards are not assigned an assumed cash value.
Annual and multi-year reports
Use monthly grouping for the current year, or yearly grouping or Automatic for a long history. Weeks start on Monday. The first and last interval can be partial: only awards inside the selected dates are counted.
An overly fine grouping for a long period produces a message. Choose Automatic, a larger interval or a shorter range. If the report itself is too large, shorten the period or select a single server. A partial result is not substituted for the complete report.
Payments after rewards
Observation, days selects a window from 1 to 90 days. For each recipient it starts at their first included award within the selected period. Each reward-kind row starts its own observation. A payment must settle strictly after the award and before the window ends. Test payments, guest payments and administrative funding are excluded.
| Column | Meaning |
|---|---|
| Recipients | Distinct recipients in this row |
| Observation completed | The full window has elapsed and complete payment history is available |
| Made a payment | Recipients with completed observation who made an eligible payment |
| Still observing | The window has not ended |
| Incomplete history | Complete history is unavailable from the start, so absence of payment is not established |
| Share of paying recipients | Paying recipients divided by recipients with completed observation |
Without completed observations, no percentage is calculated yet. This measures an association, not proof that rewards increased revenue. It is not a return-on-investment calculation, and a later refund does not erase the fact that a payment occurred.
The overall rate uses distinct recipients with completed observation, not an average of reward-kind percentages. For example, two paying recipients out of four completed observations give 50%. Shortening the observation window does not make incomplete payment history complete.
Empty periods and refresh
The calculation time appears above the results. Delayed processing shows a warning; unavailable data can be retried with the refresh button. Errors do not replace results with zeros. The open report refreshes every 30 seconds, pausing while filters are being edited.
Retention after rewards
Open Retention after rewards for the selected project. The report measures whether reward recipients signed in to the player cabinet again after receiving a reward. It does not measure in-game online activity.
Period and grouping
Select all servers or one server, the first-reward date range and an observation window. There is no limit on the number of years. Reward dates use UTC; both selected dates are included. If the period has not ended yet, only events that have already occurred are counted.
| Field | Meaning |
|---|---|
| Game server | All servers, including project-wide wallet rewards, or one accessible server |
| Period | Today, the last 7, 30 or 90 days, current year, previous year or custom dates |
| First reward from / through | Inclusive first eligible reward dates; editing them switches the preset to custom dates |
| Group by | Automatically, days, weeks, months or years; changes table rows, not the observation window |
| Observation, days | From 1 to 90 days after each recipient's first reward |
Press the refresh button. Applied filters are saved in the page address and restored after reloading. The report period and observation window are independent: a multi-year report can check each player's return within seven days after a reward.
Each recipient is counted once, starting from their first completed, non-reversed reward among the selected servers. Later rewards do not restart observation. A return must occur strictly after the reward and before the observation window ends.
| Metric | Meaning |
|---|---|
| Reward recipients | Players whose first eligible reward falls within the selected date range |
| Observation completed | Recipients with complete login history whose full observation window has elapsed |
| Returned after reward | Recipients with completed observation who signed in during the window |
| Still observing | The window has not ended, even if the player has already signed in |
| Insufficient history | Complete login history is unavailable from the start of observation; these players are not classified as non-returning |
| Return rate | Returning recipients divided by recipients with completed observation |
Without completed observations, the rate is Not yet available, not 0%. For example, six returning players out of ten completed observations produce a 60% rate. Two recent recipients still under observation do not change that percentage yet.
Annual and multi-year periods
Use monthly grouping for Current year. Automatically selects suitable detail for the chosen range; years can be selected for a long history. Weeks start on Monday. The first and last rows may cover partial intervals, including only rewards within the selected dates.
If the selected detail is too fine for the range, the report shows a message. Choose Automatically, a coarser grouping or a shorter period. Rows are never silently discarded to display part of a result.
Server and completed observation
When a single server is selected, the first reward is determined among that server's rewards. Project-wide wallet awards appear only under All servers.
Each row shows the return rate of its recipients. The overall rate uses the total number of players with completed observation, not an average of row percentages. For example, 1 out of 1 in one row and 1 out of 3 in another produce 2 out of 4 overall, or 50%.
The calculation time appears above the table. When recent activity is still being processed, a warning explains that results may change. A loading failure shows an error and can be retried with the refresh button; it does not replace results with zeros. The open page refreshes every 30 seconds, pausing while filters are being edited.
Referred player revenue
Open Referred player revenue for the selected project. The report includes payments made after invitation acceptance. Participation must still be active at the selected period end; current or future periods use the time already observed. Test, guest and administrative funding are excluded.
Revenue filters
| Field | Purpose |
|---|---|
| Game server | All project servers or one server |
| Period | Today, last 7, 30 or 90 days, current year, previous year or custom dates |
| From / through | Both dates are included; day boundaries use UTC |
| Grouping | Automatic, daily, weekly, monthly or yearly |
| Currency | Switches cards, charts and tables for the selected currency and precision |
There is no limit on the number of years: select any range within the retained history. Future dates do not add predicted payments. Automatic selects a suitable interval for the report size. The refresh button applies filters; dates and grouping remain in the page address.
Revenue metrics
When payments use several currencies, a currency selector appears above the results. It switches cards, charts and tables together. Different currencies are never added together or converted using an assumed exchange rate. Matching currency names with different decimal precision are also kept separate.
| Metric | Meaning |
|---|---|
| Payment total | Confirmed payments in the period before fees |
| Fees | Fees for those payments |
| After fees | Amount after fees, before refunds or dispute effects |
| Refunded | Successful refunds in the period, including refunds of older payments |
| Open disputes | Unresolved disputed amount at the end of the selected period |
| Lost disputes | Amount from disputes lost during the selected period |
| Per paying player | Payment total divided by distinct paying players in the period, rounded to currency precision |
| Paying players | Distinct players with included payments in the period |
| Payments | Number of included payments |
A player who pays on several servers is counted once in the project-wide payer total. Average spend covers the selected period, not lifetime participation. If only refunds or disputes exist without payments, average spend is unavailable.
Years, months and weeks
Select Current year with monthly grouping for a month-by-month comparison.
Yearly grouping is available for longer history. The overall amount and unique paying-player count cover the entire period: another payment by the same player in another year does not add another person to the total.
Weeks start on Monday. The first and last intervals may be partial: only operations within the chosen dates contribute. When history completeness is unknown, missing intervals remain gaps rather than zero income.
Project-wide balance and servers
All servers includes project-wide wallet payments. Selecting a specific server does not assign project-wide payments to that server.
Charts show payments, refunds and lost disputes by the selected intervals, UTC hour and weekday. A refund belongs to its refund date, not the original payment date. Open disputes appear separately in the summary; they are not interval income. Hover over a point or bar for its exact amount. The server comparison and expandable Values by interval table show the operations actually included.
Empty results and limits
When no operations exist for the selected dates, the report shows an empty result without invented amounts or average spend.
If the selected detail produces too many values, the report asks you to adjust filters. Choose automatic or coarser grouping, a shorter period or one server. A truncated result is never presented as a complete report.
The calculation time appears above the results. Delayed processing shows a warning; incomplete refund or dispute data is flagged separately. A loading failure does not replace results with zeros. Use the refresh button to retry. The page refreshes every 30 seconds while visible, pausing during filter editing.
Referral payment conversion
Open Referral payment conversion for the selected project. The report includes players who first accepted an invitation within the selected dates. Repeated qualification neither adds another player nor restarts observation.
Period and metrics
| Field | Meaning |
|---|---|
| Period | A preset or custom dates, including multiple years |
| Grouping | Automatic, day, week, month or year; changes table intervals without changing observation rules |
| Invitation accepted from / through | First acceptance dates, not payment dates. Both dates are included; boundaries use UTC |
| Observation, days | From 1 to 90 days after each player's invitation acceptance |
| Server | Limits payments to the selected server. Relationships belong to the project, so the accepted-invitation count does not change with the server |
All servers includes project-wide wallet payments. A specific server does not receive project-wide payments. Payment must be confirmed strictly after acceptance and before that player's observation deadline. Guest, test and administrative funding are excluded. Refunds do not erase the fact that a payment occurred; refund amounts appear in Referred player revenue.
| Metric | Meaning |
|---|---|
| Accepted invitations | Unique players who first accepted within the selected period |
| Excluded participants | Previously accepted players whose participation is suspended, rejected or reversed at calculation time |
| Completed observations | Active participants whose observation window has ended and whose payment history is complete |
| Paid within the window | Players with an eligible payment among completed observations |
| Still observing | History is complete, but the window has not ended; these players do not yet enter the final percentage |
| Incomplete history | Complete history is unavailable for the observation window; absence of payment is not established |
Payment conversion is the share of paying players among completed observations. Without completed observations the percentage is unavailable, not zero. Invitation cohorts shows the same counts by the selected calendar interval, most recent first. A player belongs only to the interval of their first-ever invitation acceptance.
A year or multiple years
There is no limit on the number of years. Select the current year with monthly grouping or enter your own dates. Automatic grouping chooses a suitable interval for a long period. The current unfinished interval includes only time that has already elapsed.
Row percentages are not averaged. If one group has 1 paying player out of 1 and another has 1 out of 3, the combined result is 2 out of 4, or 50%, not the average of the two rates. A partially selected month includes only invitations accepted within the selected dates.
Excessively detailed grouping for a long period shows a clear message. Select automatic grouping or a larger interval. The report is not truncated or presented as complete when only part of it was read.
Server and observation window
Server selection changes eligible payments, not the number of project players who accepted an invitation.
The observation window is independent of grouping. For example, one day looks for an eligible payment during the day following first acceptance, even when the table uses monthly or yearly intervals.
Payment ranking
Top 10 paying referrals lists the ten participants with the highest observed payment totals in the selected currency. Equal amounts are ordered by player ID. The total number of paying participants in that currency appears above the table. Rows show the player, paid amount, payment count and latest payment date.
Payment currency changes only the ranking, not the overall conversion percentage. Different currencies and decimal scales stay separate. Amounts are gross payments before fees and refunds, not net revenue. The ranking includes already observed payments from ongoing windows and windows with incomplete history, so its player count can differ from Paid within the window.
The page refreshes every 30 seconds while visible and filters are not being edited. Processing delays show a warning. Use the refresh button after a loading error; an unavailable report is not replaced with zero metrics.
Dashboard
The dashboard links to Participants, Referral rewards, Referred player revenue, Retention after rewards and Referral payment conversion, each with its own filters. The paying-player ranking is part of the conversion report.
Award counts and payments after awards are available in Referral rewards. The dashboard does not display a combined amount for different currencies.
Participant details
In Participants, use the inviter-details button at the end of a row. The account has two sections: Overview and invitations and Reward history. The header shows the player's email, project, ID and registration date. Invitation and inviter links open the corresponding player's account; Referral participants returns to the full list.
Overview and invitations
| Metric | Meaning |
|---|---|
| Referral coins available | The current amount available to use |
| Referral coins reserved | Amount already reserved by unfinished operations |
| Referral coins credited, all time | Cumulative credits, not the current balance or the value of item rewards |
| Accepted invitations, all time | All accepted direct invitations, including relationships later suspended or ended |
| Active invitations | Direct relationships currently Accepted or Qualified at calculation time |
The first three metrics describe the referral wallet. They do not include the player's regular balance or assign a value to awarded items. Below them, the inviter, relationship state and first acceptance date are shown. An absent accepted invitation has its own message.
Direct referral payments
| Field | Meaning |
|---|---|
| Game server | Limits payments to one server; All servers also includes project-wide wallet payments |
| Period | Recent days, this or the previous year, or custom dates |
| Payments from / through | Payment confirmation dates. Both dates are included, days use UTC; there is no limit on the number of years |
| Rows per page | 25, 50 or 100 invitations; does not limit metrics or totals |
Server and date filters change only the payment table. They do not change the current wallet, inviter or lifetime invitations. Refresh applies filters; reset restores the defaults and the first page.
Payments from active direct referrals separates each currency and decimal precision, showing gross paid, payment count, paying players and latest payment. Payment must be confirmed strictly after first acceptance. Test payments, guest payments and administrative funding are excluded. Payments from subsequent referral generations are not included. Refunds are not subtracted here; see Referred player revenue for refund amounts.
Different currencies are neither added together nor converted into each other. When complete history is unconfirmed, a warning explains that missing records do not establish an absence of payments. The example shows that actual incomplete-history state rather than invented amounts.
Select This year to view payments from January 1 through December 31. Future dates do not add payments; the wallet and accepted invitations remain current metrics.
For several years, enter the start and end dates manually. Period changes to Custom dates. Reloading retains the selected dates; reset restores the last 30 days.
Invitation list
Each row shows the referred player's email and ID, registration date, first acceptance, current relationship state, Their invitations and Awards received. The last two counts belong to that referred player: their own accepted direct invitations and distinct completed, non-reversed awards received by them. Several changes to one award do not increase the award count. An unknown registration date is shown as Not recorded.
Invitations are ordered from most recently accepted to oldest. Next retains the calculation time and invitation totals. Previous returns to the preceding page; returning to the first page refreshes the calculation. The example below shows the final page: one referred player already has two invitations of their own and one received award.
An account without accepted direct invitations still shows its wallet and account details, with a separate empty list state.
Reward history
History includes changes where the selected player is the inviter, referred player or recipient. It is not limited to rewards received personally; each row identifies the participants' roles.
| Filter | Meaning |
|---|---|
| Game server | All servers, including project-wide wallet awards, or a single server |
| Reward type | Achievement, invitation, accrual or clan reward |
| Period | A preset, this or the previous year, or custom dates |
| From / through | Reward-change dates, inclusive, in UTC; several years can be selected |
| Status | Pending, completed, review required, reversed or skipped |
| Reward ID | The exact value from row details; leave empty for all rewards |
| Rows per page | 25, 50 or 100 changes |
Metrics cover the entire filtered history: recorded changes, distinct operations, recipients, completions, review requests and reversals in the period. One delivery may have several records. A row's state describes that change, not necessarily the delivery's current state.
Here dates filter reward changes themselves, not payments from referred players. This year includes all recorded changes in the year; totals cover the full period, not just visible rows.
Select custom dates to include earlier history. When no records predate the program's launch, extending the period does not increase the number of operations.
Expand a row with the button on the right to see identifiers and available details. Current delivery and reward composition loads the current state, name, completion and update dates, amount and items with quantities and enchantment levels. If that lookup is unavailable, retry it; the historical record remains visible.
Refresh and errors
The calculation time appears above the results. Recent changes may still be processing, and delays produce a warning. The first page refreshes every 30 seconds while visible and filters are not being edited. An expanded reward entry pauses refresh, as do subsequent pages.
If late information changes invitations, payment totals or reward history, the page asks you to refresh the list. Continuing the old list does not mix in new results. The wallet always shows the current balance rather than freezing it for the invitation traversal.
Changing filters, resetting or manually refreshing returns to the first page. Refresh an expired browsing session. A loading error can be retried and is not replaced with false zeros. Accounts from unavailable projects and nonexistent players cannot be opened.