> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/identity-verification/monitoring-and-analytics/verification-analytics.md). # Verification Analytics ### Overview Verification Analytics is currently released as a beta feature. The Verification Analytics page shows how identity verification is performing across your verification journeys — how many people verify successfully, where they fail, how often they retry, and how long verification takes. It replaces the previous Analytics page and adds specific failure-reason reporting, so you can see which checks are driving failures and act on them. You can analyze results at two levels — Unique Users and All Sessions — filter by journey and time period, and review four areas: * Key indicators * Verification performance over time * Top failure reasons * Risk signal breakdown All metrics on the page are calculated using completed sessions only. A completed session is one that reached a final outcome — Success, Failed, or Not Performed — so sessions a user abandoned partway through are not counted.
#### Navigation In AdminX, go to **Verification → Verification Analytics**. By default, the page shows **All Verification Journeys** for **This week**. Metrics are shown in your local time zone (displayed at the top of the page). #### Filtering the data | Filter | Options | | ----------------------------------- | ----------------------------------------------------------------------------- | | Filter by Verification Journey Type | All Verification Journeys, a specific journey, or a select number of Journeys | | Time period | Today, This Week, This Month, or a custom date range (Select dates) | The filters apply to the whole page. #### Choosing Unique Users or All Sessions Metrics can be viewed by **Unique Users** or **All Sessions**, selected from the **Showing metrics for** control. A unique user is identified by **First Name + Last Name + Date of Birth**, so multiple sessions from the same person count as one user, while the session total still reflects every session. {% hint style="warning" %} The **Key Indicators** section and the **Verification Performance Over Time** graph each have independent selectors. Changing one does not affect the other. {% endhint %} ### Key indicators The top tiles summarize verification performance for the selected journey and period. | Indicator | What it shows | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Total Completed Sessions | The number of completed sessions, or unique users, in scope based on the selected view. In the Unique Users view the subtext shows how many completed sessions those users represent. | | Verification Success Rate | The percentage of completed sessions (or users) that verified successfully. | | Successfully Verified | The number of completed sessions, or users, that verified successfully. | | Failed Verification | The number of completed sessions that failed, or the number of users who failed without ever succeeding. | | First-Attempt Success Rate | The percentage of users whose first verification attempt in the period succeeded. | | Retry Rate | The percentage of users who ran more than one verification session in the period. | | Face Liveness Failure Rate | The percentage of completed sessions (or users) that failed the face liveness check, measured only against those where the check actually ran. | | Avg. Verification Time | The average time taken to complete a verification session. | {% hint style="info" %} * All indicators are calculated on completed sessions only. * First-Attempt Success Rate and Retry Rate are always calculated at the unique-user level, even in the All Sessions view, because they require grouping a user's sessions. {% endhint %} #### How metrics are calculated Most indicators report a different number depending on whether you are viewing **All Sessions** or **Unique Users**. * In the **All Sessions** view, each completed session counts separately. * In the **Unique Users** view, the system groups a person's sessions together and counts them once. A few indicators — First-Attempt Success Rate, Retry Rate, and Avg. Verification Time — group by user (or session) regardless of the selected view, so they show the same value either way. For example, the examples below use the same sample set: five completed sessions from four users. | Session | User | Result | Face liveness | Duration | | ------- | ----- | ------------- | ------------- | -------- | | S1 | Alice | Success | Passed | 40s | | S2 | Bob | Failed | Failed | 60s | | S3 | Bob | Success | Passed | 50s | | S4 | Carol | Failed | Failed | 70s | | S5 | Dan | Not Performed | Not run | 30s | **Total Completed Sessions** * **All Sessions:** total completed sessions * Example: 5 sessions → **5** * **Unique Users:** count of distinct users * Example: Alice, Bob, Carol, Dan (Bob's two sessions count once) → **4** A session that can't be tied to a user (no date of birth, or missing both first and last name) still counts as a session but not as a user. **Verification Success Rate** * **All Sessions:** successful sessions ÷ total completed sessions × 100 * Example: 2 ÷ 5 × 100 = **40.00%** * **Unique Users:** users who succeeded at least once ÷ total users × 100 * Example: 2 ÷ 4 × 100 = **50.00%** Not performed sessions stay in the denominator. A user who fails and later passes counts as a success. **Successfully Verified** * **All Sessions:** count of successful sessions * Example: S1, S3 → **2** * **Unique Users:** count of users who succeeded at least once * Example: Alice, Bob → **2** **Failed Verification** * **All Sessions:** count of failed sessions * Example: S2, S4 → **2** * **Unique Users:** count of users who failed and never succeeded * Example: Carol only → **1** Not Performed sessions are never counted as failures. Bob is excluded here because he later passed; Dan is excluded because his only session was Not Performed. **First-Attempt Success Rate** Always measured per user, so both views show the same value. * **Formula:** users whose first session succeeded ÷ total users × 100 * Example: only Alice's first session passed → 1 ÷ 4 × 100 = **25.00%** **Retry Rate** Always measured per user, so both views show the same value. * **Formula:** users with more than one session ÷ total users × 100 * Example: only Bob had a second session → 1 ÷ 4 × 100 = **25.00%** **Face Liveness Failure Rate** Measured only against sessions (or users) where the liveness check ran, shown in the tile subtitle. * **All Sessions:** sessions that failed liveness ÷ sessions where liveness ran × 100 * Example: 2 ÷ 4 × 100 = **50.00%** (liveness ran on S1–S4, not S5) * **Unique Users:** users who failed liveness at least once ÷ users where liveness ran × 100 * Example: 2 ÷ 3 × 100 = **66.67%** (liveness ran for Alice, Bob, Carol) A user who fails liveness once and later passes still counts as a failure. **Avg. Verification Time** Always measured per session, so both views show the same value. * **Formula:** sum of each session's duration ÷ total completed sessions * Example: (40 + 60 + 50 + 70 + 30) ÷ 5 = **50.00s** {% hint style="info" %} Sessions missing a start or completion time, or completed before they started, are excluded. {% endhint %} ### Verification performance over time The **Verification Performance Over Time** graph plots verification results across the selected period. Depending on the selected view, it shows total, successful (passed), failed, and incomplete users or sessions, so you can see trends and improvement over time. ### Top failure reasons The **Top Failure Reasons** chart lists the top 10 reasons verifications failed for the selected journey and period. Each reason shows: * the number of sessions in which that failure occurred, and * its weight, that reason's share of all failure occurrences. {% hint style="info" %} A single session can fail more than one check, so it contributes to each failure reason it contains. As a result, the weight is calculated against the total occurrences of all failure reasons, not the number of failed sessions. {% endhint %} ### Risk signal breakdown The **Risk Signal Breakdown** lists the risk signals detected for the selected journey and period, alongside the number of users affected by each. Risk signals indicate potential fraud or identity manipulation that falls outside standard document and face verification checks. They point admins to patterns worth investigating rather than failures tied to a single session. Each entry shows: * the risk signal name, * a short description of what it detects, and * the number of users affected. Risk signals currently reported include: | Risk signal | What it detects | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Different Face Detected for the Same User | A different face is detected across verification sessions associated with the same identity (first name, last name, and date of birth) | | Geolocation Change Between Sessions | The same identity (first name, last name, and date of birth) is verified from a location more than 500 miles away from a previous session | | Virtual Camera Detected | Potential use of virtual or manipulated camera sources during verification | | Document & IP Country Mismatch | The issuing country of the presented document differs from the user's IP geolocation country | | Identity Mismatch With Authoritative Source | The extracted identity (first name, last name, and date of birth) does not match the authoritative identity on file | {% hint style="info" %} **Notes** * Each signal shows the number of users affected for the selected journey and period. * This page replaces the previous Analytics page. * All metrics are calculated on completed sessions only — a completed session is one with a final result of Success, Failed, or Not Performed. Abandoned/incomplete sessions are excluded, and the trend graph no longer shows an "Incomplete" series. * The page opens with the Unique Users view and the This Week period by default. * Unique-user identity is based on First Name + Last Name + Date of Birth. * Failure reasons identify the specific verification/fraud check that failed and are derived from IDV error codes. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.1kosmos.com/identity-verification/monitoring-and-analytics/verification-analytics.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.