Choosing a Person ID in CJA, and what happens when channels don't match

Why this matters

Choosing the right Person ID is critical because it directly determines how cross-channel data is joined and reported. If web data uses a browser ID and CRM data uses a customer ID, rows won’t align without a shared Person ID—leading to incomplete or inaccurate audience counts. Without a consistent Person ID, reports show inflated or fragmented numbers, misrepresenting actual customer behavior.

Stitching can fix mismatches by linking anonymous web rows to a known ID, but it’s only effective if the Person ID is defined early. If the choice is made late, or not at all, you risk rebuilding connections and data views multiple times. This delays reporting, increases errors, and wastes effort. Deciding the Person ID upfront ensures data joins correctly and people metrics reflect real individuals—not devices or browsers.

The key ideas

In Customer Journey Analytics, the Person ID is the key that connects data from different channels. When web data uses a browser ID and CRM data uses a customer ID, those rows won’t join unless they share a common Person ID. Without a shared ID, the data remains separate and doesn’t reflect the full customer journey.

Stitching helps by using a known ID—like a customer ID—found alongside a browser ID to relabel anonymous web rows. This links the browser data to the actual person, allowing cross-channel views. But this process depends on the Person ID being correctly chosen at the start.

The choice of Person ID directly affects how metrics are counted. If a browser ID is used as the Person ID, the counts reflect browsers and devices, not unique people. This can lead to inflated or misleading results. Choosing the right Person ID early ensures accurate, consistent reporting and avoids the need to rebuild data connections later. Once set, that Person ID defines how all data joins and how people metrics are calculated across channels.

How to apply it

When setting up cross-channel reports in Customer Journey Analytics, choose the Person ID early—this decision defines how people are counted. If you select a browser ID as the Person ID, each browser session is counted separately, even if it belongs to the same person, because the ID reflects devices, not individuals. This leads to inflated counts of unique users, especially across web and CRM data. To align web and CRM data, ensure the Person ID used is consistent with the data source. If web data uses a browser ID and CRM uses a customer ID, the datasets won’t join unless a common Person ID exists. Stitching can help by using a known ID (like a customer ID) found alongside the browser ID to relabel anonymous web rows, linking them to the correct person. This alignment ensures accurate person-level insights. Once the Person ID is selected, avoid changing it later—rebuilding connections and data views increases risk of inconsistencies. The final Person ID choice directly impacts metrics: people metrics count unique Person IDs, so selecting a device-level ID will count devices, not people. Choosing the right Person ID upfront ensures accurate, reliable cross-channel reporting.

Mistakes to avoid

• Choosing a Person ID that doesn’t align across channels—like using browser ID in web data while CRM uses customer ID—prevents data from joining properly. This results in fragmented reports and inaccurate people metrics. To avoid this, ensure the Person ID used in CJA matches the one consistently used across all data sources. If sources use different IDs, apply stitching to link anonymous web rows to known person IDs.

• Selecting a browser-level ID as the Person ID counts devices and browsers instead of unique people. This inflates metrics and misrepresents user behavior. Always verify that the chosen Person ID reflects the actual individual, not a session or device identifier. Decide the Person ID early in the setup process to prevent costly rebuilds of connections and data views later.

Quick checklist

• Confirm which Person ID will be used across all datasets (e.g., browser ID, customer ID) before building reports.
• Ensure web and CRM datasets use compatible Person IDs or identify how stitching will map anonymous browser IDs to customer IDs.
• Verify that stitching is applied to align anonymous web rows with known customer identities.
• Understand that choosing a browser ID will count devices and browsers, not unique people, affecting people metrics.
• Validate that the chosen Person ID is consistent with business definitions of a “person” to avoid misaligned reporting.
• Rebuild data connections and views only after finalizing the Person ID to avoid rework.
• Test the report with sample data to confirm that people metrics reflect the intended Person ID.
• Document the Person ID choice and stitching logic for transparency and future reference.