Operator guideENglossarycrmreferenceterminology

CRM Glossary / Confusing Terms

Shared glossary for CRM labels that are easy to confuse across dashboard, challenges, CMS, and bonus-related workflows.

Reader view

Clean portal guidance

This page keeps the operator explanation, field and action descriptions, and screenshots visible without exposing repo paths, raw sidecars, or editorial-only implementation details.

Narrative content

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:

  • Challenges module = operator CRUD and lifecycle management
  • General - 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 Label is a configurable document-label inventory managed in the KYC Labels module 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 Status is a player's verification state. On the Players / KYC Status tab 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-specific Pending Withdrawals rows.

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 row
  • Total 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 NGR exists just because Total GGR exists
  • 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 Correction appears 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 Tags in 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 Streamer usually reads like a player-level flag
  • Streamer data usually 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:

  • ClickID usually means the click-level acquisition identifier coming from tracking
  • PID or Affiliate PID usually 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 uses
  • Wagering Multiplier = how much turnover is required under that model

Practical rule:

  • use Wagering Type to understand what counts
  • use Wagering Multiplier to 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 bonus
  • Wagering Status = progress state of the wagering requirement
  • Wager Left = numeric remainder still required before the wagering condition is complete

Practical rule:

  • treat Bonus Status as the high-level state
  • treat Wagering Status and Wager Left as 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, or Bonus 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 Correction in KPI/reporting usually means a financial adjustment row
  • Correction Amount in 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 applied
  • Min NGR to qualify [MGQ] = lower threshold required for qualification
  • Max 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 GGR vs Total GGR above.
  • NGR — Net Gaming Revenue (also "net"). Also backend-owned. On the verified KPI Summary path the backend computes it from GGR plus an already-negative marketing bucket, so the frontend does not recompute it from visible rows.
  • FTD — First-Time Deposit / First-Time Depositor (also "first deposit"). Also seen as the ftd traffic-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 Qualification configuration (grouped by PID) and CPA payouts in affiliate reporting.
  • RTP — Return To Player (also "return percentage"). Appears as Actual RTP (won divided by wagered) and Theoretical 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 PID above.

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:

  1. find the canonical surface docs page first
  2. use this glossary to separate lookalike terms
  3. if the meaning is still unclear, trace the exact FE surface and backend source before rewriting operator wording
Related references

Related pages

pageAffiliate Deals / Dashboard

Deal-period performance report that combines traffic, deposit, GGR, NGR, payout, and ROI metrics for affiliate deals.

pageAffiliate Deals / Form

Create and edit form for affiliate deals, including PID, date window, commercial terms, and responsible person.

pageAffiliate Deals / List

Searchable table of affiliate deal rows with PID filter, create action, dashboard shortcut, and edit/delete row actions.

pageAffiliate Deals Overview

Operator guide for affiliate-deal records, their create/edit flow, and the performance dashboard that reconciles contract settings with delivered traffic and revenue metrics.

pageAutomatic Withdrawal / Detail

Management workspace for automatic withdrawal, combining the rules register with processed history and the non-qualified withdrawal queue.

pageAutomatic Withdrawal / Form

Create and edit form for one automatic-withdrawal rule, including thresholds, KYC, countries, methods, tags, and per-currency limits.