Page body
Purpose
This page explains CRM labels that repeatedly confuse operators, reviewers, or new docs contributors.
Use it when a term appears in the UI but its meaning is not obvious from the label alone.
User Challenge
User Challenge does not always mean the same thing.
In the Challenges module
In Challenges / List, the User source filter means the challenge record originated from the user/runtime side rather than the admin-created path.
This is about the origin of the challenge record, not a CMS content block.
In CMS page editing
General - User Challenges is a CMS section type used inside the page editor.
It is a content block type, not the same entity as a challenge record in the CRM challenge module.
Practical rule:
Challengesmodule = operator CRUD and lifecycle managementGeneral - User Challenges= CMS content block shown on a page
Challenge Builder
Challenge Builder is the operator-facing configuration workspace for creating
or editing a challenge definition. It is not the same thing as a challenge
record or a CMS section type.
Practical rule:
Challenge Builder= configuration workflow- challenge row = configured or issued record
Challenge Auto Configs
Challenge Auto Configs refers to reusable automation-oriented challenge setup.
It should not be read as the same thing as the main challenges list row that an
operator reviews day to day.
Practical rule:
- auto configs = automation/template layer
- challenges list = working challenge records
Challenge Permissions
Challenge Permissions belongs to access control for challenge operations. It
is not a challenge status, type, or result.
Practical rule:
- permissions = who can do what
- challenge data = what exists or how it performs
Pending Withdrawals (Kyc Pending)
Pending Withdrawals (Kyc Pending) is a KPI Summary row for the subset of pending withdrawals where the user is still in the KYC pending bucket.
Important:
- it is not a frontend formula
- it is not a standalone withdrawal status outside the pending-withdrawal family
- it is a backend-provided subset of the broader pending-withdrawal amount
Related rows:
Pending Withdrawals (Globally)Pending Withdrawals (Kyc Requested)Pending Withdrawals (Kyc Approved)
Practical rule:
Globally= umbrella pending amount- KYC-specific rows = bucketed subsets of that umbrella amount
KYC Label vs KYC Status
KYC Label and KYC Status both belong to KYC, but they describe different
things and live on different surfaces.
KYC Labelis a configurable document-label inventory managed in theKYC Labelsmodule at/kyc-labels. Each label defines a verification document type that can appear in KYC and identity-verification flows, along with whether the document is required, whether it is single-sided, and its translated names. It is configuration, not a player attribute.KYC Statusis a player's verification state. On thePlayers / KYC Statustab it appears as the per-document workflow chip (for example pending, requested, approved, rejected) that controls which actions a row exposes. The same player-level KYC buckets also drive the KYC-specificPending Withdrawalsrows.
Practical rule:
KYC Label= the catalog of document types operators can request (config)KYC Status= where a specific player or document sits in the verification workflow (state)
Editing a KYC label does not change any player's verification state, and a player's KYC status does not map one-to-one to a single label.
Total GGR
Total GGR should not be assumed to mean the same thing as the plain GGR row in every widget or report.
In current KPI Summary docs, Total GGR is treated as a separate backend-provided row rather than a frontend sum built from visible cells.
Practical rule:
GGR= the normal gross gaming revenue rowTotal GGR= a separate backend-owned figure that may reflect a different aggregation path or naming convention
If an operator wants reconciliation, compare it only against the same report family and same backend path.
See the base GGR definition below for what the plain acronym means.
Total NGR
Operators often ask for Total NGR by analogy with Total GGR.
Current KPI Summary verification does not confirm a separate Total NGR row in the verified backend mapper. In that widget, the practical answer is usually the plain NGR row unless another report family exposes a distinct Total NGR.
Practical rule:
- do not assume
Total NGRexists just becauseTotal GGRexists - verify the exact report surface before using the label
See the base NGR definition below for what the plain acronym means.
Correction
Correction is usually a financial adjustment-style label, not a gameplay or bonus type on its own.
In KPI/report contexts, operators should read it as one of the adjustment rows that can change how net figures differ from gross figures.
Practical rule:
- if
Correctionappears next to revenue rows, interpret it as an adjustment component - do not treat it as interchangeable with bonus payout or cashback unless the exact report says so
Marketing
Marketing in KPI/report rows is usually a deduction or classification label inside a financial summary, not a generic module name.
Practical rule:
- when it appears in KPI/revenue contexts, treat it as a report row with financial meaning
- when it appears as navigation or page grouping, treat it as a broader business area instead
Tags
Tags is overloaded across CRM and should not be assumed to mean the same thing
everywhere.
Common cases:
- player tags used for segmentation or internal classification
- bonus tags used to group or qualify bonus definitions
- KYC or review tags used during compliance-oriented workflows
Practical rule:
- read
Tagsin the context of the current module first - do not assume a tag from one workflow is interchangeable with a tag from another workflow
Segment
Segment is overloaded and points to unrelated concepts depending on the
surface.
- Traffic / acquisition segment: in reporting and payment-method contexts, a segment is a slice of traffic or a cohort, for example FTD vs repeated traffic, or a cohort grouped by PID, country, domain, or landing page.
- Player segmentation tags: in the player list and
Auto Tags Manager, "segmentation" refers to manual or automated tags attached to players for classification and filtering. The stored entity is a tag, not a separate segment object. - Wheel-of-fortune prize segment: in
Wheel of Fortune, a segment is one slice of the spinning wheel. The builder requires between 10 and 16 segments, and a segment can map to a reusable bonus id. - Route segment (technical): in URLs and code, "segment" can simply mean one path part of a route, not a business concept.
Practical rule:
- confirm which surface you are on before reading
Segment - a traffic segment, a player segmentation tag, and a wheel prize segment are not interchangeable
Streamer Data / Is Streamer
Streamer data and Is Streamer are related labels, but they do not always
appear in the same context.
Typical usage:
- dashboard/report filters may use
Streamer data - player profile/detail pages may expose
Is Streamer
Practical rule:
Is Streamerusually reads like a player-level flagStreamer datausually reads like a reporting or filtering scope that limits visible data to streamer-tagged records
ClickID / PID / Affiliate PID
These labels all point to acquisition tracking identifiers, but they are not safe to treat as synonyms without checking the exact surface.
Practical rule:
ClickIDusually means the click-level acquisition identifier coming from trackingPIDorAffiliate PIDusually means a partner or campaign identifier used by affiliate reporting
If operators need reconciliation, compare them only within the same report family and not across unrelated widgets by label alone.
Wagering Type / Wagering Multiplier
These bonus labels answer different questions:
Wagering Type= which balance, turnover source, or wagering model the bonus usesWagering Multiplier= how much turnover is required under that model
Practical rule:
- use
Wagering Typeto understand what counts - use
Wagering Multiplierto understand how much is required
Bonus Status / Wagering Status / Wager Left
These issued-bonus labels belong to different parts of the same lifecycle.
Bonus Status= lifecycle state of the issued bonusWagering Status= progress state of the wagering requirementWager Left= numeric remainder still required before the wagering condition is complete
Practical rule:
- treat
Bonus Statusas the high-level state - treat
Wagering StatusandWager Leftas wagering-progress indicators
Amount Converted / Total Amount Converted
Amount Converted or Total Amount Converted should not be read as a plain
payout amount.
In bonus-related contexts this usually means the portion of value that has already been converted out of the bonus lifecycle into another balance or settled state.
Practical rule:
- do not assume it means the same thing as
Win,Payout, orBonus Balance - read it as a transition or conversion amount inside the bonus lifecycle
Correction Amount
Correction Amount is not automatically the same thing as the generic
report-level Correction row.
Practical rule:
- plain
Correctionin KPI/reporting usually means a financial adjustment row Correction Amountin bonus-related contexts should be read as a bonus-linked adjustment amount within that bonus record or issued-bonus lifecycle
Period To Check NGR / MGQ / XGQ
These labels belong to high-risk instant_cashback qualification logic and are
easy to misread.
Period To Check NGR= the evaluation window used before qualification logic is appliedMin NGR to qualify [MGQ]= lower threshold required for qualificationMax NGR to qualify [XGQ]= upper threshold boundary for qualification
Practical rule:
- read them together as a qualification window, not as isolated amount fields
- if the cashback setup is ambiguous, verify the exact bonus type branch before rewriting operator wording
Rakeback / Rakeback Calendar
Rakeback can refer to:
- a manual operator action on a player
- a bonus-selection flow that is limited by
autoPayout - a reported amount in player or dashboard KPI surfaces
Rakeback Calendar usually refers to the time-based scheduling or view of that
same business concept, not a different reward family.
Practical rule:
- treat manual rakeback actions and reported rakeback totals as related but not interchangeable
- if an operator asks for reconciliation, confirm whether they mean:
- manual issuance flow
- bonus configuration
- or reporting totals
Country Message
Country Message is a CMS/editor content surface for country-specific
messaging. It is not the same thing as player country data, blocked-country
configuration, or casino geo-restriction logic.
Practical rule:
- country message = content managed in the editor
- player country / blocked country = operational or configuration data
Page Configuration
Page Configuration in CMS/editor contexts means page-level composition or
presentation settings. It is not a report configuration and not a standalone
business entity.
Practical rule:
- page configuration = how a page is assembled or displayed
- page data rows = separate entities that feed content into that page
Revenue and Tracking Acronyms
Common CRM acronyms and how operators usually say them:
- GGR — Gross Gaming Revenue (also "gross"). A backend-owned revenue figure.
On verified KPI surfaces the backend computes it (for example bet amount minus
win amount); the frontend does not sum it from visible cells. See
GGRvsTotal GGRabove. - NGR — Net Gaming Revenue (also "net"). Also backend-owned. On the verified
KPI Summarypath the backend computes it from GGR plus an already-negativemarketingbucket, so the frontend does not recompute it from visible rows. - FTD — First-Time Deposit / First-Time Depositor (also "first deposit").
Also seen as the
ftdtraffic-type flag (FTD-only vs repeated) and as FTD counts in affiliate reports. - CPA — Cost Per Acquisition (also "cost per acquisition deal"). Drives the
CPA Qualificationconfiguration (grouped by PID) and CPA payouts in affiliate reporting. - RTP — Return To Player (also "return percentage"). Appears as
Actual RTP(won divided by wagered) andTheoretical RTP(configured, wagered-weighted) on gaming reports. - PID — Partner ID / Affiliate ID (also "partner id", "affiliate pid"). The
partner or campaign identifier used by affiliate and acquisition reporting.
See also
ClickID / PID / Affiliate PIDabove.
GGR and NGR are described here as backend-owned figures: treat them as values the backend returns, and reconcile only within the same report family and backend path rather than by label across unrelated widgets.
How to use this page
When a label is still confusing after reading the target surface docs:
- find the canonical surface docs page first
- use this glossary to separate lookalike terms
- if the meaning is still unclear, trace the exact FE surface and backend source before rewriting operator wording