Data Quality
The Data Quality section monitors the health of the data pipeline feeding the loyalty program. It surfaces ingestion errors, missing fields, invalid values, and API call failures — catching problems before they propagate into incorrect points issuance, broken campaign mechanics, or skewed analytics.
This dashboard is the primary tool for technical teams, implementation managers, and anyone responsible for integration health. It shifts the detection of data problems from reactive (a customer calls support) to proactive (an error alert fires before the store closes).
Use Cases
| Use Case |
|---|
| → Detect failed or rejected API calls to the Streaming API before they accumulate into a backlog. |
| → Identify transactions missing required fields (e.g. customer ID, store code, cart line amounts). |
| → Monitor ingestion error rates by store or location to find POS systems with misconfiguration. |
| → Catch schema changes in the upstream POS feed before they break points issuance rules. |
| → Set up alerts for when error rates exceed a configurable threshold. |
| → Track the volume of anonymous (non-identified) transactions that could not be attributed to a loyalty member. |
| → Verify that new integration work (added stores, new POS version) does not introduce regression. |
Filters
| Filter | Description |
|---|---|
| Date From / To | Analysis window for error and health metrics |
| Country | Filter by country |
| Store | Restrict to specific store locations to isolate integration issues |
| Error Type | Filter by error category (see Error Types below) |
| Endpoint | Filter by specific Streaming API endpoint |
Dashboard Sections
Overview
Summary health metrics for the full pipeline.
| KPI | Description |
|---|---|
| Total API Calls | Total requests received by the Streaming API in the period |
| Error Rate | Failed or rejected calls / total calls |
| Successful Calls | Calls that processed correctly and generated a loyalty event |
| Rejected Calls | Calls that returned a non-2xx response — includes validation errors, auth errors, and schema errors |
| Anonymous Transactions | Transactions where a customer was not identified — no loyalty event could be generated |
| Identification Rate | Identified transactions / total transactions — measures how effectively customers are being recognized at checkout |
Error Volume
Time-series view of error counts, with breakdown by type and location.
| KPI | Description |
|---|---|
| Errors by Day | Daily error count trend — reveals spikes linked to specific incidents or deployments |
| Errors by Store | Locations generating the highest error volumes — identify misconfigured POS terminals |
| Errors by Endpoint | Which API endpoints generate the most errors — helps prioritize integration fixes |
| Error Rate Trend | Error rate (%) over time — distinguishes growing problems from isolated incidents |
Error Types
Classification of errors by root cause.
| Error Type | Description |
|---|---|
| Authentication Error | Missing or invalid X-Api-Key / X-Api-Secret headers |
| Schema Validation Error | Request body does not match the expected API schema (missing required fields, wrong data types) |
| Unknown Store | Store code in the request does not match any location configured in the platform |
| Unknown Customer | Customer identifier not found in the CDP — customer has not been created yet |
| Duplicate Idempotency Key | A request was replayed with the same Idempotency-Key as a prior successful call |
| Timeout / 5xx | Server-side processing error — usually transient; monitor for sustained elevated rates |
| Missing Cart Lines | Transaction submitted without product line items — cannot apply SKU-based rules |
| Invalid Amount | Line item amounts or totals contain negative, zero, or non-numeric values |
Identification
Detailed view of customer identification rates.
| KPI | Description |
|---|---|
| Identification Rate by Store | Breakdown of identified vs. anonymous transactions per location |
| Identification Rate by Period | Trend over time — reveals whether customer enrollment campaigns or UX changes are increasing identification |
| Anonymous Transaction Volume | Absolute count of transactions where no loyalty event was possible |
| Top Anonymous Stores | Locations with the lowest identification rates — candidates for POS UI improvements or staff training |
Missing Data
Fields that are technically accepted but missing or null in the ingested payload.
| KPI | Description |
|---|---|
| Missing Customer Email | Transactions where the customer was identified but email field was absent |
| Missing Category | Cart lines where product category was not sent — impacts Retail analytics and category-based rules |
| Missing SKU | Cart lines without a valid SKU — affects product-level reporting and SKU-targeted discounts |
| Missing Location | Transactions without a store code — cannot attribute to a location for partner or retail reporting |
:::tip Fixing Missing Data Missing data entries in this section indicate that the API call was accepted and processed, but the resulting loyalty event and analytics will be incomplete. Work with your integration team to ensure POS payloads include all recommended fields before go-live. :::
Alerts
Data Quality supports configurable alert thresholds. When an error rate or missing field rate exceeds the configured threshold, the platform sends a notification (email or webhook) to the designated recipients.
| Alert Type | Description |
|---|---|
| Error Rate Threshold | Trigger when the hourly or daily error rate exceeds X% |
| Zero Calls | Trigger when no API calls are received from a specific store for more than N hours |
| Identification Drop | Trigger when identification rate falls below a configured floor |
Alerts are configured in Platform Settings → Notifications.
How It Works
Data Quality metrics are derived from the Streaming API access logs and the loyalty engine processing pipeline. Unlike the other Loyalty Insights sections (which aggregate business outcomes), Data Quality measures the pipeline itself — call counts, response codes, and field presence in the raw payloads.
Data is updated near-real-time (with a 15-minute delay). Use this dashboard proactively during new store go-lives, POS version upgrades, or after any changes to the API integration layer.