Two Data Views, One Person, Different Numbers
A media company has one Platform dataset with web behavior and a second dataset with app behavior, both keyed by ecid where available and crm_id when the user is logged in. Two data views exist: 'Web' (container = session, default metric = page views) and 'App' (container = session, default metric = screen views). Both data views use the same connection. A product manager builds a Workspace project pulling 'Visits' from Web and 'Visits' from App side by side and sees 1.2M and 0.4M respectively, but the combined 'People' metric shows 0.9M - less than the Web visits number. She files a bug.
1. Explain why combined People (0.9M) can be lower than Web Visits (1.2M) without any data being wrong.
Read the worked answer
Visits and People are different units of count, and the container/attribution settings in each data view determine what gets counted.
- Visits counts sessions. One person can generate many visits, so visits ≥ people is normal within a single data view.
- People counts distinct persons (based on the person ID configured in the data view / connection identity settings). Across two data views that share a connection, People should reconcile if both use the same person ID and stitching.
- The apparent contradiction (0.9M people < 1.2M web visits) is fine: 1.2M sessions were produced by fewer than 1.2M distinct people, and the 0.9M distinct people span both web and app.
- The real risk is if the two data views use different person ID settings (e.g., Web uses ECID, App uses CRM ID). Then 'People' is not comparable across the two and the 0.9M may be an artifact of ID resolution, not true dedup.
So the 'bug' is likely a unit mismatch, but the developer should verify person ID configuration in both data views before closing it.
2. What would you check in the data view configuration to confirm whether the two data views are comparable on People?
Read the worked answer
Check, in order:
- Person ID setting in each data view. If Web resolves to ECID and App to CRM ID, People counts are not on the same basis. Align them (e.g., both to a stitched/person-level ID) before comparing.
- Identity stitching configuration on the connection: which namespace is the 'person' namespace, the stitching lookback window, and whether the replay/stitching is enabled. If stitching is off or the lookback is short, cross-device people are over-counted (each device = a person), which would inflate People, not deflate it - so also check for the opposite: over-aggressive stitching collapsing distinct people.
- Container settings on each data view: session definition (timeout, what starts a session) affects Visits, not People, but explains visit-count differences.
- Component settings: is 'People' using the same underlying dimension in both, or is one a calculated metric with a filter?
- Data view inclusion rules / filters: if App data view excludes some rows (e.g., bots, internal traffic), its People contribution is smaller.
Only after 1–5 reconcile should you treat the numbers as a defect.