Data & Methodology
We publish what we can observe, state what we cannot, and never turn missing evidence into zero.
Measurement scope
What is counted, and what the number is counted for.
Payment = a qualifying observed payment fact under the published protocol method — not every transfer. Value moving on-chain does not make an event a payment.
Counted as a payment
- An approved post-authorization funds action under the protocol's versioned interpretation.
- Attributed to the named tracked object by the published protocol method.
- Carrying a usable event time, so it can enter a window.
Not a payment
- A funding transfer or account top-up.
- A wallet-to-wallet transfer.
- A swap.
- A treasury movement.
- A pooled settlement between intermediaries.
- A refund or a reward.
Excluded even when the value moves on-chain and even when it belongs to the same product.
What a tracked object is
A tracked object is the specific payment product, card program or protocol scope named on the page. It is not automatically the whole issuer, company, payment processor or ecosystem behind it.
Where several brands or products share infrastructure, activity is attributed only as far as the evidence and the registry permit. Issuer-level residual activity is not assigned to a product merely because that product uses the issuer.
Different protocols expose different moments
Payment architectures expose different points of the payment lifecycle: one protocol may expose an authorization-adjacent action, another a pooled settlement. Observations are normalized into one comparable payment fact only where the method contract says the business semantics are comparable — never merely because both produced a number.
What each metric means
The headword is the metric's name in this method; where a page column reads differently, the column label is noted.
Payments
Means
The number of qualifying canonical payment facts for the selected tracked object and window.
Duplicate, retry and non-payment facts are excluded by the canonical fact contract. A fact without a usable event time does not silently enter a rolling window.
Does not mean
Registered users, issued cards, authorization attempts, transfers, settlements or company-wide transactions.
Active payment accounts
Shown as Active
Means
Distinct canonical activity accounts with at least one qualifying payment in the window — observable payment accounts.
Does not mean
Unique people, customers, cardholders, wallets or addresses. One person may control several accounts, and an account can stop being the right business identity after a migration.
Publishes only when identity attribution coverage passes the publication gate. Otherwise the value is unavailable — never substituted with 0.
Payment amount
Shown as Amount
Means
The amount attached to the canonical payment action under that protocol's approved amount role. The role is protocol-specific, because architectures expose different parts of the lifecycle.
Does not mean
Company revenue, total GMV, or a settlement fact shared across protocols. A transaction amount and a booked spend-to-hold amount are not presented as the same thing.
Denomination and asset provenance are preserved, and native amounts in different assets are never summed raw. A missing amount scale is missing — not 0, and not an assumed number of decimals. Cross-protocol amounts are built on the Comparable Amount Set: each qualifying payment is valued in USD at its own payment time through a versioned adapter, with provider, date and rate kept as provenance.
Median payment
Shown as Median
p25 · p50 · p75 · p90
Means
The typical payment size. Inside one protocol it is the exact median of that protocol × window × denomination population; across protocols it is the exact median of the pooled Comparable Amount Set, where every qualifying payment is first valued in USD at its own payment time. The exact mathematical median: the middle value of an odd sample, and the exact arithmetic mean of the two central values of an even sample.
Does not mean
An average, or a value that must equal some single observed payment — it is a derived statistic. Never an average of protocol medians: each payment enters the pooled population once, so a protocol's weight is carried by its payment count rather than by a second round of weighting.
Publishes only when amount coverage for that cell is complete under the amount contract and at least 30 publishable observations exist. Incomplete source evidence may publish as Partial with the covered population stated; a missing valuation adapter never can — that is an unfinished integration, not a coverage gap. The stored value stays exact; only the displayed value is rounded for reading.
Payments / active account
Shown as Pays / acct
qualifying payments ÷ active payment accounts
Means
Usage intensity among observable active accounts in the same object and window.
Does not mean
A per-person or per-card frequency.
If active payment accounts is unavailable or zero, the ratio is unavailable rather than fabricated.
Growth
(current N-day value − previous N-day value) ÷ previous N-day value
Means
The measured change of an N-day window against the immediately preceding equal-length, non-overlapping, comparable window.
Does not mean
An explanation. A growth percentage describes a measured change; by itself it says nothing about the business cause.
If the previous value is unavailable, growth is unavailable. If the previous value is a known zero, the product shows Zero baseline — never Infinity and never an invented percentage.
Repeat account rate
accounts with ≥2 payments ÷ accounts with ≥1 payment
Means
Within one window, the share of active accounts that paid more than once.
Does not mean
Retention, or evidence that anyone came back from an earlier period — it is entirely a within-window measure.
Identity coverage must be disclosed and publishable for the rate to publish.
Returning, first observed & account change
Shown as Return rate
previous active + first observed + reactivated − became inactive = current active
Means
Cross-period account movement. Returning is historical activity followed by activity again under a compatible identity and history contract; first observed is the first time an account can be seen in the covered history; became inactive is active in the previous comparable period but not now.
The account-change bridge accounts for both positive and negative movement, so a rising account base and a churning one cannot look the same.
Does not mean
First observed is not “new customers” or “new users” — that stronger statement needs historical completeness this data does not by itself establish.
Concentration
Means
Whether observed usage is spread broadly or sits with a smaller set of observable accounts. Every displayed value states its basis — payment count or payment amount — and its population.
The shipped measure is percentile concentration — the share held by the top 1% and by the top 10% of active payment accounts, never a “top 10 accounts” list. Amount is the default basis wherever a value publishes one, with payment count as the alternate, and the basis is labelled on the value itself.
Does not mean
A quality judgement. High concentration is a structural description, to be read against history, product model and peers — not evidence of weak usage.
Usage pattern
Means
Day-of-week and hour-of-day structure of the underlying qualifying fact's own timestamp.
The event semantics are stated next to the pattern itself, because “UTC” alone is not a semantic explanation.
Does not mean
Guaranteed to be the moment a cardholder paid. Where the observable event is settlement- or batch-oriented, the pattern reflects settlement rhythm rather than payment time.
Growth decomposition. Where payment amount growth is broken into contributions, the identity is Payment amount = active payment accounts × payments per active account × mean payment size — so a change can be discussed as an account-base, per-account-usage and ticket-size effect. Mean belongs to this identity; median describes a typical payment and is never substituted into it. The decomposition explains the composition of a measured change, not its business cause.
Windows & comparability
Which stretch of time a number covers, and when two numbers may be put side by side.
The three windows
- 1D
- The latest complete UTC day — never the incomplete day in progress.
- 7D
- A rolling seven complete days, anchored to the published as_of day.
- 30D
- A rolling thirty complete days, on the same anchor.
Window form: [as_of + 1 − N, as_of + 1) in UTC. The comparison window is the immediately preceding equal-length, non-overlapping window.
Two values are comparable only when the comparison preserves
- the same metric meaning;
- the same window, on a compatible as_of anchor;
- the same object level — a card program against a card program, not an issuer against a deployment without saying so;
- compatible protocol attribution;
- compatible observable lifecycle semantics;
- coverage sufficient for that metric — identity, amount, source;
- compatible method and data generation, or an explicit break annotation.
Where a protocol has been observable for fewer days than the selected window, only the data that exists is shown, with its available history stated. Missing earlier points are never invented to fill a chart.
Every payment is valued before amounts are compared. Native amounts in different assets are never added or ranked raw. The Universal Valuation Layer converts each qualifying payment into a USD-equivalent at its own payment time — a versioned adapter per denomination, keeping provider, date and rate as provenance — and every cross-protocol amount is computed on that population. A denomination with no approved adapter is an unfinished integration, not a Partial or Not comparable data state: it is fixed before that denomination joins the comparison, never given an assumed rate.
Rankings need a comparable base. A protocol without prior-window truth, or without sufficient comparability, does not quietly enter a growth ranking. Read the relative percentage together with the absolute change: a large percentage on a tiny base is not a large expansion.
Coverage & data states
What we can see, and the exact words used when we cannot.
Coverage always means our observable and publishable scope. It is not market share, and it is not “the percentage of the company we know”.
- source / event coverage
- Is the relevant underlying activity captured at all?
- protocol attribution coverage
- Can captured facts be assigned to the named tracked object?
- identity coverage
- Can qualifying payments be assigned to canonical activity accounts?
- amount coverage
- Do qualifying payments carry a publishable amount, scale and denomination?
- history coverage
- How far back does the comparable observed history actually go?
Any coverage percentage shown carries a named denominator. Where no defensible denominator exists, a factual scope statement is used instead of a score.
No synthetic confidence scores. No “Data quality 98%”, no Trust Score, no Evidence Quality rating. A number like that would be an opinion wearing the clothes of a measurement.
The words, and what each one commits to
| State | What it means | What you see |
|---|---|---|
| Available | The value is publishable under the current method and coverage requirements. | A figure. |
| Known zero | The population is observable and the correct answer really is zero. | 0 — and it means zero. |
| Partial | Some relevant scope or history is observable, but the stated coverage is incomplete — missing facts, a stale source, a known ingestion gap. It describes evidence, never an unfinished method. | A figure, plus what the partial scope represents. Read it as a floor. |
| Stale | The evidence exists but falls outside the accepted freshness condition. | The value marked as stale, never dressed as current. |
| Not observed | No qualifying evidence has been observed under the stated scope. | A word. It is not proof the business activity does not exist. |
| Unavailable | The required evidence or input is not available to us. | A word, never 0. |
| Not publishable | Evidence may exist, but the metric fails a publication rule — identity coverage, amount scale, or minimum sample size. | A word, and the rule that was not met. |
| Not comparable | Two otherwise valid values do not satisfy the comparison contract. | A refusal to compare, rather than a misleading side-by-side. |
| Zero baseline | The previous-period denominator for growth is a known zero. | Zero baseline — no percentage, no Infinity. |
None of these ever collapses into 0. A zero on this product means a measured zero. Everything else keeps its own word.
Freshness & evidence
Where a published number comes from, and how current it is.
Every analytical value carries its publication context
- as_of
- the latest complete day the value is anchored to
- window
- which of 1D / 7D / 30D is selected
- tracked object
- the protocol or card program the value belongs to
- method revision
- the version of the method that produced it, where exposed
- freshness
- the source watermark, where one is available
- state
- its coverage and publishability state
A stale value is never presented as a current one merely because the interface can still draw it.
The evidence chain behind a number
Each step is reconstructible from the one after it. Observed, reconstructed and inferred statements stay distinguishable — and a lack of public evidence is never translated into “the process does not exist”. Off-chain and private boundaries are facts about observability, not gaps in the business.
- Metric you read
- Payment fact
- Protocol interpretation & method
- Raw event or transaction
- Block · chain · source
What the public product gives you
The method and metric definitions on this page; the coverage and freshness context beside each value; the source and protocol attribution for a tracked object; representative evidence and provenance where the surface supports it; and enough reference to understand how a published claim was constructed.
What it deliberately is not
Raw transactions stay secondary. This is not a block explorer, and there is no full fact browser: querying the whole payment-fact population, auditing exactly which facts compose a metric, exporting data, API feeds and historical method snapshots are not part of the free public product today.
Figures marked Demo are illustrative. Where a research page still shows a value that is not yet backed by GWEIBIAO's observed data, it carries a small Demo marker. Such values are not published facts; a module built on them is marked as a whole. Each is replaced in place as coverage goes live, and the marker goes with it.
Known boundaries
The inferences this data cannot support, stated before someone makes them.
Payment products differ structurally. Some expose an authorization-adjacent payment action, some a pooled settlement, and some keep final clearing, merchant information or parts of payment execution off-chain or private. The correct reading is always scoped to what is observed, reconstructed or supported.
-
Active accounts are the number of users.
An account is an observable payer, not a person. Registered users and unique people are not derivable from it.
-
Payment accounts are issued cards.
Issued or active card counts are a separate fact the payment evidence does not carry.
-
A payment fact identifies the merchant.
Merchant identity and category are not present in a generic payment fact.
-
An on-chain payment action is the final settlement.
Final card-network clearing happens later and elsewhere; an earlier on-chain action does not prove it.
-
Observed payment amount is revenue or GMV.
It is the amount attached to observed payment actions under a protocol's amount role — not company revenue and not total volume.
-
What is not visible on-chain does not happen.
Much of a payment business is off-chain or private by design. Absence of observation is not absence of the process.
Method version
What is frozen, what a change would mean, and how to tell us it is wrong.
A material change to the payment population, identity model, amount roles, windows or comparability rules is a versioned change. It does not silently rewrite the meaning of history — because a comparison across a methodological break is exactly the mistake a version marker exists to prevent.
This page did not answer your question
Both routes reach us with the page, protocol, section, window and language already attached, so nothing has to be described twice.