The Merge Policy Blind Spot

Ask a room full of AEP practitioners to explain what a merge policy does and you will get a decent answer. Ask the same room how many merge policies their audiences currently touch, and which ones, and you will get silence.

That silence is the problem. Merge policies are one of the few objects in Adobe Experience Platform that can change the answer a segment gives without changing anything about the segment. They sit underneath everything, they are configured once and rarely revisited, and the platform gives you almost no way to see them in aggregate. You can inspect one segment at a time. You cannot look at your portfolio.

We recently ran merge policy analysis across a single production sandbox at an enterprise retailer. The results are below, fully anonymized. The short version: 745 audiences in that sandbox are entangled with more than one merge policy, and 96 percent of them look completely healthy by every operational measure the team was watching.

What a merge policy actually is

A profile in AEP is not a thing you store. It is a thing you compute. Data arrives as fragments from every source you have connected, web behavior tied to an ECID, email engagement tied to a hashed address, transactions tied to a loyalty ID, app sessions tied to a device. Those fragments live separately. A merge policy is the ruleset that decides how they collapse into the single customer view that a segment gets to evaluate against.

Three parts of that ruleset carry most of the weight.

The identity graph setting decides whether fragments get stitched at all. Turn the private graph on and the anonymous web session, the email open, and the in-store purchase resolve into one person. Turn it off and they stay three people. Same data, same segment definition, entirely different population.

The attribute merge precedence decides which value wins when two datasets disagree. Order datasets explicitly and the CRM record beats the form fill. Order by timestamp and the most recent write beats everything. If you have ever watched a personalization decision fire on a stale attribute you thought you had overwritten, this is usually where it started.

The dataset and attribute inclusion rules decide what is even visible. A merge policy scoped to a subset of datasets, or with attributes excluded, will silently strip fields that a downstream segment depends on. The segment does not error. It just quietly returns fewer people than it should, and nobody notices because nobody has a reference number to compare against.

None of this is exotic. It is documented behavior, working as designed. The issue is not the mechanism. The issue is that the mechanism is invisible at the scale where it matters.

Why this is a correctness problem, not a performance problem

Most platform hygiene work is about efficiency. Reduce the query load, trim the unused datasets, retire the dead segments. Merge policy drift is a different category. It does not make things slower. It makes things wrong, in a way that is internally consistent enough that nothing breaks.

Consider two audiences built by two different teams six months apart. One is bound to a merge policy with stitching on. The other inherited the sandbox default, which has stitching off. Both are named sensibly. Both return plausible numbers. Both get activated. And when someone builds a report comparing their performance, they are comparing populations that were assembled under different rules. The comparison is not slightly noisy. It is meaningless, and it looks fine.

Now scale that to the four places it propagates.

Measurement comparability goes first. Any analysis that puts two audiences side by side assumes a shared definition of a person. Different merge policies break that assumption without announcing it.

Streaming and edge evaluation is next. Merge policy configuration interacts directly with what profile context is resolvable in real time. An audience that qualifies cleanly in batch can behave very differently when it is being evaluated at the edge with a different set of available fragments. This is the failure mode that shows up as “the segment works in the UI but the personalization is not firing,” and teams usually spend a week looking at the wrong layer.

Activation and destinations inherit the whole thing. What you export is what the merge policy resolved. Two destinations receiving what the team believes is the same audience can receive materially different files. Suppression logic built on one merge policy and targeting logic built on another will overlap in ways nobody modeled.

Governance is the quiet one. If a merge policy excludes attributes for good compliance reasons, that exclusion becomes a dependency for every audience evaluated under it. Change the policy and you have changed the meaning of every downstream segment at once. There is no impact analysis available for that change in the platform UI.

What one sandbox looked like

745 audiences touching more than one merge policy. 643 of them span two policies. 102 span three.

The number of distinct merge policies involved is three. That is the detail worth sitting with. This is not a sandbox with sprawling policy configuration. It is a well managed environment with a small, deliberate set of policies, and the entanglement still reaches 745 audiences. One policy appears in all 745. A second appears in 86 percent of them. A third appears in 28 percent. Three combinations account for the entire set.

Cumulative profile membership across these audiences runs into the hundreds of millions, with the largest single audience above 32 million profiles. These are not experiments parked in a corner. This is the production activation surface.

The part that breaks the obvious heuristic

The natural instinct is to assume this is a complexity problem. Big, gnarly, deeply nested audience definitions accumulate dependencies, and dependencies drag in extra merge policies. Audit the complicated ones and you will find the entanglement.

The data says the opposite. Audiences touching three merge policies score an average of 38.8 on complexity. Audiences touching two score 53.6. The most entangled audiences in the sandbox are, on average, the simpler ones.

That inversion makes sense once you think about how these audiences get built. A simple, reusable audience is the one that gets referenced everywhere, by every team, in every context. Its very simplicity is what makes it a shared dependency, and shared dependencies are exactly what pull in multiple evaluation contexts. The complicated bespoke audience built for one campaign touches one policy because only one team ever touched it.

The practical consequence is that you cannot sort your way to this. There is no complexity threshold that surfaces the problem, which is why complexity scoring on its own was never enough. It has to carry merge policy exposure as a weighted input, not a footnote. In our scoring, spanning two policies contributes a merge score of 6 and three policies contributes 10, with a multiplier applied on top for audiences where the exposure compounds with other risk factors. That multiplier landed on 512 of the 745.

Why nothing flagged it

Here is the uncomfortable chart.

717 of the 745 report OK status. 21 warrant attention. 7 are critical. Every operational signal the team had, population stability, day over day variance, activation success, was green across the overwhelming majority of this set.

That is not a monitoring failure. Those signals are doing exactly what they were built to do. A population can be perfectly stable and perfectly wrong. Watching an audience hold steady at 800,000 profiles tells you nothing about whether those are the right 800,000, and merge policy drift is specifically the class of problem that produces a stable, plausible, incorrect answer.

Population monitoring answers “did this change.” Merge policy visibility answers “is this what we meant.” You need both, and the industry has spent most of its energy on the first one.

What to do with this

Start by getting an inventory. Not a spot check on the segment you are currently editing, an actual portfolio view of which audiences are bound to which merge policies and where they overlap. If that inventory does not exist, everything downstream is guesswork.

Then look at your default. Most multi-policy entanglement traces back to audiences that inherited the sandbox default at creation time because nobody made an explicit choice. The default is a decision. It just was not made by anyone recently.

Then check comparability before you check performance. Any two audiences you are reporting against each other need to be on the same merge policy or the comparison needs an asterisk. This is a five minute check that prevents quarters of bad conclusions.

Then treat merge policy changes as breaking changes. Before touching a policy, know every audience evaluated under it. That impact list should exist before the change, not after the incident.

The larger point

AEP is enormously powerful and most of that power is configuration. Configuration that is set once, works, and then becomes invisible is the most dangerous kind, because the platform will keep executing it faithfully long after anyone remembers what it does.

Merge policies are the clearest example. They are not obscure. They are documented, well understood in isolation, and completely opaque in aggregate. The gap is not knowledge. The gap is visibility, and the fix is not a better mental model. It is a system that can look at 745 audiences at once and tell you which ones are quietly answering a different question than the one you asked.

That is what we built. If you want to know what your own number is, we can show you.

Analysis performed with MiaProva across a single production AEP sandbox. All audience names, identifiers, and brand references have been removed or replaced. Figures reflect actual distributions.