Indicator calculation caliber
Data Overview: Indicator calculation caliber
Indicator numerator, denominator and deduplication key
| Indicators | Numerator | Denominator | Recommended to remove duplicate keys |
|---|---|---|---|
| Identification Events | Number of identification events in the current scope | None | request_id |
| Unique Visitors | Number of distinct devices currently in scope | None | device_id |
| Risk events | Number of events that hit at least one risk signal | None | request_id |
| Event/visitor ratio | Number of identified events | Number of unique visitors | Numerator request_id; denominator device_id |
| Hits for a single risk signal | Number of events containing this signal | None | Normally deduplicated by request_id; the same event and signal are counted once |
If there is not enough data for a certain indicator, the page should display "No data yet" or use a clear placeholder, and should not mistakenly display "uncalculated" as 0.
Success events and billing events
When you need to check the package quota, please also check which events will be included in the usage.
"Successful formation event" and "billing event" are two related but not necessarily identical concepts:
- Success event: Geelab has completed identification processing and formed a queryable event record.
- Billing events: requests that are included in usage or fee calculations based on the current package and billing rules.
Some product rules may only count identification requests that successfully issue tokens and meet billing conditions into billing amounts; requests that are rejected, failed, tested, or processed by specific exclusion rules may not be billed, but whether logs or queryable events are formed need to be subject to formal billing and API instructions.
Therefore:
- The number of overview events should not be taken directly as the bill amount.
- Usage cards in the overview should be clearly labeled "Identification Event" or "Billing Call".
- The bill page and package usage page should use a unified billing standard.
- The time range, application, region and package version should also be recorded during reconciliation.
Current cycle and previous cycle
The current period is the time period selected by the user on the page. The previous period is the immediately preceding period of the same length as the current period.
Example:
Current period: 2026-08-13 to 2026-08-19
Previous period: 2026-08-06 to 2026-08-12The last period for "today" is usually yesterday; the last period for "last 7 days" is the previous full 7 days; and the last period for "last 30 days" is the previous full 30 days.
If the current cycle is ongoing, the data for the current cycle may continue to increase. The previous cycle is usually a complete cycle that has ended, so the two do not necessarily have the same level of data completeness.
Chain change rate
When comparable data is available for the previous period, the period-over-period rate of change is usually calculated as follows:
Period-over-period change = (current period - previous period) / previous period × 100%For example: There are 1,200 events in the current period and 1,000 events in the previous period:
(1,200 - 1,000) / 1,000 × 100% = +20.0%The page should display both the current value and the direction of change. It is not recommended to only display the percentage and hide the original quantity of the two periods.