Skip CRM duplicate merging
This doc explains Skip CRM duplicate merging, what it means for your data, and what you should expect to see in HockeyStack.
What this setting does
If Skip CRM duplicate merging is enabled, HockeyStack will not combine CRM company records that share a domain.
Example:
Your CRM has 3 Salesforce Accounts with the domain
acme.com(regional accounts, business units, historical duplicates, etc.).In HockeyStack, you will also see 3 separate companies (not 1 combined company).
This setting only changes how CRM company duplicates are handled. It does not change how we ingest your CRM or how we track website/intent signals.
What counts as a “duplicate” here
In this context, “duplicate” usually means multiple CRM company records that represent the same real-world company and share the same domain.
Common examples:
“Acme – West” and “Acme – Enterprise” both use
acme.commultiple historical accounts created over time
separate accounts per product line or division
What you’ll notice in HockeyStack
1) Company counts look closer to your CRM
You will typically see your company count match your CRM more closely.
2) You will see more companies than before
This is expected, because duplicates are now shown as separate rows.
3) Some companies may look empty
This is normal for duplicate records.
Those records might still show:
CRM-native activity tied directly to that record (opportunities, activities, lifecycle stage, etc.)
They might not show:
website visits, intent signals, or ad impressions (see next section).
Where website + intent data goes
Even when CRM duplicates are kept separate, HockeyStack still needs to decide where to attach non-CRM signals like:
website activity
intent data
ad impressions
enrichment data
In this mode:
HockeyStack chooses one “primary” CRM company record among duplicates using our priority rules.
The primary record receives the non-CRM activity.
The other CRM duplicates will only show activity if it exists directly on those CRM records.
Why we do it this way:
Non-CRM signals often arrive with only a domain (not a specific CRM record ID).
When multiple CRM records share that domain, we need a single deterministic place to attach the signal.
Impact on reporting (what changes and what does not)
What stays the same
Your CRM records still sync as usual.
Your dashboards and reports should still work.
What can change
Some rollups may look different because non-CRM activity is concentrated on the primary record instead of being spread across duplicates.
If you compare exports over time, results may look more consistent because we are not collapsing/expanding CRM duplicates.
When to enable this
This setting is a good fit when you want:
HockeyStack to reflect your CRM structure (including intentional duplicates for regions, business units, or historical records).
fewer surprises when comparing counts between HockeyStack and your CRM.
Common questions
Will this break dashboards?
Dashboards should still load, but reporting may look different because activity will concentrate on the primary record instead of being spread across duplicates.
Does this change how users/contacts are merged?
No. Users are still identified primarily by email. This setting applies to CRM company duplicates.
Can we control which record is “primary”?
In some cases we can support custom hierarchy / priority rules (typically for enterprise setups).
Do I need to reprocess data when switching this on?
Typically, yes. Changing merge behavior usually requires reprocessing so historical signals map according to the new logic.
Last updated