The Trust view sits in your per-domain dashboard and gives you an honest measurement of how much of your tracking is being captured. It runs daily and compares three signals — the browser tracker, server-side ingestion, and webhook truth — to estimate gaps and explain where they likely come from.
This guide walks through reading the view and what to do when something looks worth investigating.
Where to find it
In app.zenovay.com, open any domain dashboard and select the Trust tab from the Reliability group in the sidebar (it lives at /domains/{id}?tab=trust). The view shows the trailing 7 days of reconciliation results.
If this is a brand-new website, you may see a friendly empty state. The first reconciliation row appears within 24 hours of activity (the daily job runs at 00:00 UTC).
The headline number
At the top, you'll see a large percentage labelled "estimated tracking loss" alongside a confidence chip:
- Positive percentage (e.g.
8.4%) — your browser tracker is recording fewer events than the server or webhook truth layer suggests. Some loss is normal; the breakdown below tells you why. - Negative percentage / "+X% over-counted" — your server is recording more events than your browser tracker. That isn't a bug; it usually means server-side ingestion caught events that adblockers or network drops would have lost.
—(em dash) — there isn't enough comparable data yet, typically because either the server layer or webhook layer is empty for this site.
Below the percentage is a completeness bar. The solid emerald section shows events that matched across layers. The amber striped section shows the estimated gap.
Confidence labels
Every metric carries one of three labels:
| Chip | Meaning |
|---|---|
| High confidence ●●● | Both layers have ≥100 events and the loss is below 30%. The number is trustworthy. |
| Medium confidence ●●○ | Either layer is in the 50–100 event range, or the loss falls between 30% and 60%. Treat the number as directional. |
| Limited data ●○○ | One or both layers have under 50 events, or the loss exceeds 60%. The view tells you what little it sees, but don't act on the number alone. |
Confidence is not the same as severity. A high-confidence 5% loss is more useful information than a low-confidence 80% loss.
Reading the metric breakdown
Three rows below the headline show the same comparison applied to pageviews, goal completions, and revenue events separately. Each row carries its own confidence label and three columns (client / server / webhook), plus a completeness bar.
A few common patterns:
- Pageviews: client and server should be close. A persistent gap usually points to ad-blockers or CSP rules silently blocking the tracker on certain pages.
- Goals: gaps here are often legitimate — the visitor closed the tab between firing the client event and the server-side confirmation. Pay more attention to trend changes than to a single-day percentage.
- Revenue: the webhook layer is the source of truth (it's what actually charged the customer). A gap here usually means either client purchase events aren't firing on every successful payment, or webhook deliveries are delayed.
If you see a row with a small message like "Server-side ingestion not yet in use", that means the truth layer for that metric is empty. The reconciliation will show something (Trust still uses the layer that exists), but with low confidence.
Top mismatch reasons
Below the metric breakdown, Trust ranks the top reasons it suspects, sorted by how many events each reason affects this week.
Three reasons are flagged Actionable with a small amber tag. For these, Pro and above plans see a one-line action step. The other reasons are diagnostic — they explain what's happening without requiring you to do anything.
Actionable reasons and what to do
Client tracker likely blocked (client_blocked)
- What we saw: server-side counts were noticeably higher than browser counts for at least one metric.
- Likely cause: an ad-blocker, browser privacy extension, or your own Content-Security-Policy header is blocking the tracker on some visits.
- What to try: add
api.zenovay.comto your CSPconnect-srcdirective. If you use a stricter CSP withscript-src, also add it there. For privacy-extension-driven loss, consider enabling first-party tracking so the tracker loads from your own domain.
Webhook delivery delayed (webhook_delay)
- What we saw: client-side purchase events outpaced webhook arrivals, AND today's webhook count fell well below the trailing 6-day baseline.
- Likely cause: your payment provider (typically Stripe) hasn't delivered some webhooks yet. This often resolves on its own within hours.
- What to try: open your payment provider's webhook delivery dashboard and look for failed or pending webhooks. If you see retries, the gap should close as those land. If webhooks are failing outright, check that your endpoint is reachable and returning 2xx responses.
Route normalization mismatch (route_mapping)
- What we saw: 1–2 specific routes account for more than half of the gap.
- Likely cause: those routes are normalized differently between the browser tracker and server. Common case: an SPA route that the tracker reports as
/checkout/abc123but the server records as/checkout/[id]. - What to try: review your tracker's SPA route handling for the affected URLs. The Pro+ drilldown table shows you exactly which routes contribute to the gap.
Diagnostic reasons (no action needed)
- Duplicate events suppressed — the ingest pipeline detected duplicate browser events with the same idempotency key and kept only one. This is correct behaviour.
- Visitor identity gaps — a visitor's browser ID didn't match cleanly across server-recorded events. Common when the visitor cleared cookies mid-session.
- Server-side ingestion not in use — you haven't started sending server-side events to
POST https://api.zenovay.com/e/{trackingCode}yet. Server-side reconciliation isn't possible without it. See Server-side events for setup. - No dominant cause identified — the gap is below the threshold for any specific reason. Often this just means your tracking is healthy.
The Pro+ drilldown table
If your plan is Pro or higher, you'll see a Per-route gap table at the bottom listing the largest single-route differences between client and server counts this week, ranked by event gap.
This is the most actionable part of the view: it tells you exactly where to look. A few examples:
- A single product detail page accounting for most of the pageview gap → check whether that page has a CSP rule, a custom inline script, or an A/B-tested layout that breaks the tracker.
- A
/checkoutroute appearing only on the server side → your client-side tracker may not be installed on the checkout page (a common omission with isolated payment flows). - A
/blog/[slug]pattern with hundreds of routes each contributing 1–2 events → expected; ignore.
Frequently asked questions
The Trust tab says I'm losing 12% of pageviews. Should I be worried?
Not necessarily. Industry baselines for browser-based analytics put adblocker loss at 20–40% in some verticals. A 12% measured loss with a real server-side comparison is much better than a typical analytics tool's unmeasured loss. The actionable question is whether the gap is concentrated on specific routes (something you can fix) or spread evenly (the cost of doing business).
Why does my number show "+5% over-counted"?
Your server captured more events than your browser tracker. This is good news — it means server-side ingestion is filling gaps your tracker would have missed. The "+" framing makes it clear this isn't loss.
The view says "Limited data" for revenue. What does that mean?
You either don't have many purchase events this week (under 50 across the window), or only one of the truth layers is populated (e.g. you have client purchase events but no Stripe webhook configured). The fix is usually to wait for more events or to wire up the missing layer.
Why don't I see action steps for some reasons?
Action steps for the three actionable reasons are available on Pro and above. On Free, you'll see the reason name and event count, but the suggested fix is gated. The reasons themselves and the headline numbers are visible to all plans.
Will the Trust tab show up on my public dashboards?
No. Trust is an internal diagnostic surface only. Public share dashboards never include it.
Related guides
- Bounce rate & session duration — pairs well with reconciliation when investigating engagement quality
- Understanding metrics — definitions for the underlying counts the Trust view aggregates
- Server-side events — how to wire up the server layer that powers reconciliation