Merge policies: how AEP decides which value wins

Why this matters

Understanding merge policies matters because inconsistent data leads to wrong decisions. If two sources disagree on a customer’s segment or behavior—like one marking them as high-value and another as low—without a clear merge policy, the resulting profile may misrepresent the customer. This causes inaccurate audience targeting, flawed personalization, and poor campaign performance.

Without defined rules, teams risk relying on outdated or incorrect data. For instance, if a CRM dataset is trusted over a web form due to dataset precedence, but that form has a more recent timestamp, the merge policy must explicitly resolve this. Otherwise, the system might apply outdated values or fail to merge identity-linked data properly. This leads to fragmented insights and inconsistent results across audiences, especially when different teams use different merge policies. Clear, documented merge policies ensure data consistency and reliable customer views across the platform.

The key ideas

A merge policy determines how data from different sources is combined when they conflict about the same customer. Each dataset contributes a fragment of information, and the system must decide which value to keep when they differ. This decision is driven by the merge policy settings.

For example, if a customer’s email address is recorded in both a web form and a CRM, the system may use timestamp ordered merging to keep the most recent value—such as the one from the web form submitted today. Alternatively, if the CRM is considered more reliable, the system might use dataset precedence to favor the CRM’s value over the web form’s. This ranking of datasets ensures consistency based on trust or source authority.

Additionally, the identity stitching setting in the merge policy controls whether data fragments linked by the identity graph are combined. Without identity stitching, the system might not merge data from different sources even if they belong to the same person. Audiences built from different merge policies may see the same customer differently, because each policy applies its own rules to resolve conflicts. This means the outcome depends on the merge policy in place—whether it uses timestamp or dataset precedence to resolve value disagreements.

How to apply it

When two data sources report different values for the same customer, a merge policy determines which value is used. For example, if a CRM records a customer’s email as "john.doe@company.com" and a web form records it as "johndoe@company.com", the system must decide which is correct. With timestamp ordered merging, the value from the most recent update wins—so if the web form was submitted 10 minutes ago, that version takes precedence.

If the CRM is considered more reliable—say because it's a trusted source with verified data—the merge policy can use dataset precedence to favor it over the web form, regardless of when the data was updated. This setting allows marketers to define trust levels for different data sources.

Additionally, if the identity graph links the customer across sources, the merge policy can choose whether to combine those fragments. If identity stitching is enabled, the system merges the data; if disabled, the sources remain separate. This impacts audience evaluations—two audiences using different merge policies may include the same customer differently, leading to varied targeting outcomes. Understanding these settings ensures consistent and reliable customer profiles across analytics and campaigns.

Mistakes to avoid

• Avoid assuming that all data sources are equally reliable. If a CRM dataset is trusted over a web form, ignore the web form’s value unless explicitly configured with dataset precedence. Misconfiguring precedence leads to inaccurate customer profiles.

• Don’t rely solely on timestamp ordering without considering data quality. A recent value might be erroneous if it comes from a broken data source. Always verify that timestamped updates are valid and consistent. Without identity stitching enabled, fragmented data from different sources won’t merge, leading to incomplete profiles. Misaligned merge policies across audiences can result in inconsistent customer visibility—some audiences see a user as active, others don’t. Always align merge policies across audiences and datasets to ensure consistent behavior.

Quick checklist

• Confirm whether the merge policy uses timestamp ordering or dataset precedence to resolve conflicts.
• Identify which datasets are contributing data and their relative ranking in case of precedence.
• Check if identity stitching is enabled in the merge policy to ensure identity graph links are combined.
• Verify that the timestamp of each data fragment reflects the actual time of data collection.
• Ensure that audience evaluations are aligned with the merge policy being used, as different policies may include or exclude the same person.
• Validate that the source of the conflicting data (e.g., CRM vs. web form) is known and that precedence rules reflect business logic.
• Test the merge policy with a sample customer profile where two sources provide conflicting values.
• Review whether the selected merge policy matches the intended business outcome for customer data consistency.