Category: MarTech & Data

Parts 1 and 2 walked seven stations: whether the data arrives, whether it is modelled, whether it resolves into one person, whether the fragments become a profile, how fast a rule can be answered, where a decision can be made, and how long it takes to reach a channel. Seven stations that decide whether you can act.

This part covers whether you are allowed to – and whether anyone will be able to say afterwards what it changed. Every data governance policy ships switched off – including Adobe’s own core policies – and Adobe documents that on two separate pages. Then two questions that sit around the nine stations rather than inside them: what it costs to leave your data in the warehouse, and what an AI agent can actually see.

As before, Adobe Experience Platform is the worked example because Adobe documents its limits publicly. Every figure links to its source; all pages were retrieved on 11 September 2026. None of this is a legal assessment – that is a conversation for privacy counsel, not an architecture article.

Station 8 – Govern

Every architecture diagram has a governance box. It is usually drawn as a band across the side or the bottom, coloured differently, labelled “Data Governance & Privacy”. It is the box everyone points at in the steering committee and nobody opens.

Open it. Adobe’s framework has three parts:

• Labels classify data. They come in three categories: Contract, carrying the codes C1 through C12; Identity, with I1 and I2; and Sensitive, with S1 and S2 alongside labels for permitted sensitive personal data and regulated health data.
• Policies describe what may be done with labelled data.
• Enforcement applies those policies at the point of activation.

Labels propagate usefully: audiences inherit the labels of the datasets they were built from automatically. Enforcement, when active, is real – a violation blocks the activation and shows a lineage graph of exactly which datasets, merge policies, audiences and destinations were involved.

Then there is the sentence. It appears, word for word, on two separate Adobe pages: “All data usage policies (including core policies provided by Adobe) are disabled by default. In order for an individual policy to be considered for enforcement, you must manually enable that policy.” Newly created policies are also set to disabled by default.

This is a defensible design – enforcement that blocked activations the moment you turned the platform on would make every implementation start with an outage. But it produces a specific and dangerous failure mode: nothing fails. An unenforced policy generates no errors, no warnings, no queue. Data labelled as restricted activates exactly as smoothly as data that is not. The only signal that governance is off is the absence of a signal, which is the hardest thing for any organisation to notice.

What a data governance policy actually covers

Three further facts decide whether the box, once opened, does what people assume it does.

• Marketing actions alone restrict nothing. They “must be included in enabled data usage policies” to have any effect. Labelling data and defining marketing actions without enabling a policy produces documentation, not enforcement.
• Governance is not access control. Adobe is explicit that data governance is only concerned with how data is used or activated, “regardless of the user performing the action”. Restricting which people can see which fields is a different mechanism – attribute-based access control – documented as being in limited availability for customers who purchase Healthcare and/or Privacy Shields.
• Object-level access control has its own precondition. Adobe documents object-level access control for datasets as generally available since 18 August 2026, and for destination dataflows. Dataset access control additionally requires the Default-Label-Based-Access-Control-Policy to be active – “without this policy, Adobe Experience Platform does not evaluate dataset access labels.”

The consent gap

Consent policies are a licensed capability, and they have a documented gap. They are available only with Healthcare Shield or Privacy & Security Shield. Their logic is the inverse of governance policies: Adobe describes consent policies as “inclusive in nature” – they determine which profiles may be included – while governance policies exclude labelled attributes from activation.

And then this, from Adobe’s activation documentation: “Consent policy evaluation is currently not supported in exports to the three enterprise destinations – Amazon Kinesis, Azure Event Hubs, and HTTP API” – and therefore “profiles which have not consented to being targeted are included in the exports to these three destinations.”

Three destinations in Adobe’s own catalogue, all of them common in enterprise architectures, where the consent check does not run. Adobe documents this openly. That is to its credit, and it does not make the page any less worth reading before you connect one.

A related limit on the collection side: in the Web SDK, only the data collection permission collect.val is automatically enforced. Every other consent signal you capture has to be enforced by something you build downstream.

We looked at one case where a label actively blocks a paid-social activation – the version of this that works as intended.

Station 9 – Measure

The return path is the thinnest station in this series, because it is the thinnest in the documentation. That is itself the finding.

What is published concerns querying:

• Ad-hoc queries are capped at 10 minutes of execution time.
• They return 100 rows in the interface and up to 50,000 through a client.
• Batch queries run up to 24 hours.
• The accelerated store allows four concurrent query slots.
• Data Distiller is a separate package offering a subset of platform functionality.

What the guardrails do not describe is the loop itself: how engagement outcomes become new signals, how quickly, with what identity. That has to be designed rather than configured – and it is the part of the architecture most often deferred to “phase two”, which is why so many programmes can describe what they sent and not what it changed.

When the truth lives in the warehouse

For most enterprises the authoritative customer data is not in a marketing platform. It is in Snowflake, BigQuery, Databricks or Redshift, governed by a data team who have opinions about copies.

Adobe’s answer is Federated Audience Composition, which builds audiences from data in an external warehouse without copying it. Its own FAQ is blunt about what moves: “Federated Audience Composition only stores metadata (schema descriptions). No customer data is transiting.” Seven warehouses are supported: Redshift, Azure Synapse, Databricks, BigQuery, Snowflake, Vertica Analytics and Microsoft Fabric.

For anyone who has spent a year negotiating a data-copy exception with a security team, that is a significant capability. But there is a trade, and it is in the same FAQ rather than in any comparison chart.

Two operational notes: audiences imported this way expire after 30 days by default, and the capability requires Real-Time CDP and/or Journey Optimizer at Prime or Ultimate tier, plus a specific “Manage Federated Data” permission.

What AI agents change

Every vendor now ships agents, and the interesting question is not what they can do but what they can see.

Adobe’s agentic layer is the Adobe Experience Platform Agent Orchestrator – spelled out; “AEP Agent Orchestrator” is not the product name. It is described as “the new agentic layer in Adobe Experience Platform” operating, in Adobe’s phrase, “with human oversight”. The named agents include the Audience Agent, Data Insights Agent, Experimentation Agent, Journey Agent, Product Support Agent, and the Adobe Marketing Agent for Microsoft 365 Copilot.

What they draw on is described as “structured and unstructured data sources, including Adobe product documentation, customer metadata about business objects, and analytics data.”

Read that list again for what is not in it. The knowledge base is documentation, metadata about business objects, and analytics – not the customer record itself. An agent that helps you build an audience works on the description of your data, not on the people in it.

In a regulated environment that is not a limitation to engineer around. It is the condition under which an agent is allowed to run at all – and it explains why an agent can tell you how your audiences are structured but not who is in them.

One naming correction, because it circulates wrongly: Adobe Brand Concierge is not an Experience Platform agent. It is a separate product that consumes Experience Platform data; the agent operating inside it is the Product Advisor Agent. Treating it as part of the Agent Orchestrator roster is a category error that shows up in a lot of secondhand summaries.

The blueprint: twelve questions

If you take one thing from this series into a meeting, take these. One per station, plus three that cut across.

1. Which namespace is your person identity – and is it declared unique?
2. How many identities does your average identity graph carry today?
3. Has anyone checked email case normalisation across every source that writes one?
4. Which of your audience rules reach further back than 24 hours?
5. How many edge and streaming audiences are active, against Adobe’s recommended 150 and 500?
6. For each real-time decision you have promised, is the data it needs projectable to the edge?
7. What is the activation latency of every channel in your current campaign plan?
8. Which data usage policies are enabled in your production sandbox – today, not in the design document?
9. Which destinations receive profiles whose consent was never evaluated?
10. What is your event volume per profile, against Adobe’s 5,000-event segmentation guardrail?
11. Which data genuinely needs resolved identity, and which only needs a reliable key?
12. Who signed off the primary identity on your profile-enabled schemas, and when?

If eight of the twelve have an owner and an answer, you have an omnichannel architecture. If four do, you have an omnichannel roadmap. Both are legitimate positions. Confusing one for the other is what produces the eighteen-month stall.

Frequently asked questions

What is a data governance policy?

A data governance policy is a rule that says what may be done with data carrying particular labels – and it is enforced at the point of activation rather than at the point of access. In Adobe Experience Platform, labels classify the data, policies describe the permitted use, and enforcement blocks a violating activation and shows the lineage behind it. The part teams miss: every data governance policy, including the core policies Adobe provides, is disabled by default and must be enabled by hand.

Where does consent get enforced in a martech stack?

At several points, and not uniformly. Consent can be captured at collection, stored on the profile, and evaluated at activation. In Adobe’s case, consent policies require a Healthcare Shield or Privacy & Security Shield licence, and Adobe documents that consent evaluation does not run for exports to Amazon Kinesis, Azure Event Hubs or the HTTP API destination. In the Web SDK, only the data collection permission is enforced automatically. Anything else has to be enforced by something you build.

Do AI agents in a marketing platform see customer data?

In Adobe’s documented architecture, the Agent Orchestrator’s knowledge base is described as product documentation, metadata about business objects, and analytics data – not the customer records themselves. An agent can describe how your audiences are structured without seeing who is in them. Verify this per vendor and per agent rather than assuming it generalises.

How do a CDP and a data warehouse work together?

Two patterns. Copy – move the data into the CDP, where it gets full identity resolution and profile treatment. Or federate – leave it in the warehouse and compose audiences against it without copying, as Adobe’s Federated Audience Composition does. The trade is explicit: federated data is joined on a key you define rather than through identity resolution, so it gets no cross-device stitching. Most enterprises end up running both patterns for different data.

What is the difference between a customer data platform and a data warehouse?

A warehouse stores everything for analysis, optimised for large scans across long histories. A CDP stores a working profile optimised for millisecond retrieval during a live interaction, with identity resolution and activation built in. In Adobe’s case they are literally different technologies – Cosmos DB for the profile store, Azure Data Lake Storage for the lake. Most enterprises need both, connected, rather than one replacing the other.

Related reading: Part 1 – nothing works until the data is one person · Part 2 – real time is a property of the rule · When a label blocks a paid-social activation · The Salesforce side: Data 360 starts with an “Allow All” policy.

Figures in this article are drawn from Adobe’s public documentation and link to their source; all pages were retrieved on 11 September 2026. Guardrails change with releases, and Adobe distinguishes between system-enforced limits and performance recommendations – verify against your own tenant before designing to any number, including these. Nothing here is legal advice. Sources: Data Governance overview · Data usage policies · Data usage labels reference · Attribute-based access control · Activate streaming profile destinations · Query Service guardrails · Federated Audience Composition FAQ · Agent Orchestrator. Adobe, Adobe Experience Platform and Adobe Real-Time CDP are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe.

Part 1 ended with three stations that decide whether you have a customer at all: whether the data arrives, whether it is modelled so it can be used, and whether the fragments resolve into one person. Assume all three are working. You now have a resolved identity graph and no way to act on it.

The next four stations are where acting becomes possible – and where the gap between what a platform can do and what your architecture has actually been configured to do gets widest. The recurring surprise in this half of the chain is that the same platform answers the same question in 350 milliseconds, in five minutes, or tomorrow morning, and nobody chooses which. The shape of the rule does. That is what real time segmentation actually is: not a capability you switch on, but a tier your rule qualifies for.

As in part 1, Adobe Experience Platform is the worked example because Adobe documents its limits publicly, every figure links to the page it came from, and all pages were retrieved on 11 September 2026.

Station 4 – Unify

Once identities are resolved, the fragments have to become a profile. Adobe calls the result a union view, made possible by a union schema – “a merged view of all profile fragments for that entity across datasets”. Where two fragments disagree, a merge policy decides which wins, either by dataset precedence or by timestamp. You get five merge policies, and exactly one default per class.

The important structural fact is that this profile does not live where your history lives. Adobe states it directly: “The Profile store uses a Microsoft Azure Cosmos DB infrastructure and the Experience Platform Data Lake uses Microsoft Azure Data Lake storage.” Two stores, two technologies, two purposes – one built for millisecond lookups during a live interaction, one built for analytical scans across years.

That split explains every limit that follows.

Five thousand events. Adobe’s performance guardrail is 5,000 experience events per profile for segmentation; beyond that, only the most recent 5,000 are used. For a monthly newsletter audience, that is a lifetime. For an app with daily sessions, it is a few months.

Size caps that drop data. A profile record over 100 KB and an event over 10 KB are not truncated or flagged – Adobe’s wording is that they “will be dropped.” Ingestion continues. The record does not arrive.

Expiry by default. Pseudonymous profiles – the ones with no known person attached – expire after 14 days in production and 3 days in development sandboxes by default. The floor for experience event expiration is one day, and expired data is “permanently deleted and cannot be restored.”

No retroactive fill. When you enable a dataset for the profile, the data already sitting in it does not flow in. Adobe’s guidance: “it is recommended that you re-ingest any existing data to have it contribute to customer profiles.” Every team discovers this the week after go-live.

That conclusion is worth stating plainly, because it contradicts how the profile is usually sold. The long history lives in the data lake – different store, different retention (the lake floor is 30 days and the ceiling ten years), different questions. Asking the profile a five-year question is a category error, not a configuration problem.

Station 5 – Segment

Segmentation is where “real time” stops being a marketing word and becomes a property you can check.

Adobe separates two things that are usually conflated. An audience is “a collection of people who share similar behaviors and/or characteristics.” A segment definition is “the rule set Adobe Experience Platform uses to describe key characteristics or behavior of a target audience.” The rule is the thing you write. The audience is what comes out.

The same rule can be evaluated three ways, and the platform chooses which, based on how the rule is written: “If the query matches any of the query types in the following table, it will automatically be evaluated using edge segmentation.” Edge segmentation processes an inbound event in up to 350 milliseconds. Streaming segmentation takes up to 5 minutes to qualify a profile. Batch segmentation runs every 24 hours. Three orders of magnitude apart, on one platform, decided not by a setting but by the shape of your rule.

Real time segmentation and the twenty-four-hour edge

Which brings us to the single most consequential sentence in the segmentation documentation: “The lookback window is limited to one day.” Streaming segmentation considers events from the last 24 hours. Anything older “will be processed in the subsequent batch job.”

The same boundary appears in the ineligibility list. Multi-entity queries, combinations of a single event with an inSegment condition, “ignore year” time constraints, and single events with no time window at all are not eligible for streaming. Edge evaluation is narrower still.

Three more figures that campaign plans routinely assume away.

• A new segment definition takes up to one hour to become available – for streaming and at the edge alike. You cannot write an audience and activate it in the same ten minutes.
• Streaming data takes up to three hours to appear in batch segmentation workflows.
• Events for the same profile should be at least five seconds apart “to ensure reliable audience evaluation”.

Then the capacity envelope, all of it recommended rather than enforced: 4,000 active audiences per sandbox, of which 150 edge and 500 streaming. The real-time tiers are the scarce ones – the edge recommendation is a small fraction of the total. Adobe also recommends a maximum audience membership of 30 percent, which is a polite way of saying that an audience covering a third of your customers has stopped being an audience and become a mailing list.

Station 6 – Decide

Orchestration is usually discussed as a capacity question: how many journeys, how many messages, how fast. That is the less interesting question. The constraint that actually shapes a decisioning architecture is not how much it can do. It is what it can see at the moment it decides.

Adobe’s architecture has two places where a decision can happen. The hub is the central data centre that “contains all the historical data and rich profile context.” The Edge Network is the distributed layer – seven regions – that sits next to the customer.

What lives at the edge is stated precisely: “The only data that lives on the Edge Network are the audience memberships, profile identities, and attributes necessary for personalization.” Not the history. Not the full profile. Memberships, identities, and the attributes needed for this interaction – held for 14 days on a rolling basis, reset every time the profile is accessed.

A next-best-action that needs the full purchase history cannot run at the edge, because the purchase history is not there. One that needs only “is this person in the high-value audience” can, because that membership is exactly what gets projected outward. One operational detail that surprises people in testing: the edge has a cold start. Adobe notes that “the first few evaluation calls may result in a timeout.” A first test that fails is not necessarily a broken configuration.

The orchestration side of an authenticated portal shows what this looks like when the same profile has to surface across a website, a service console and a field channel.

Station 7 – Activate

Activation is the step where a resolved, unified, segmented profile finally reaches a channel. It is also where the timing assumptions in campaign plans meet documented reality.

Destinations are capped at 100 per sandbox – a hard, system-enforced limit. Each instance should carry no more than 250 audiences and 50 mapped attributes, and bulk activation of more than 50 audiences at once “is not supported”.

The timing splits by destination type, and the spread is wide.

• Batch, file-based destinations run one full export daily, or incremental exports every 3, 6, 8 or 12 hours. Files split automatically at 5 million rows – worth knowing before someone writes an import job expecting a single file.
• Streaming destinations have no documented limit on messages per second to partner API endpoints.
• Enterprise destinations target under 10 minutes, 95 percent of the time, at under 10,000 requests per second per instance.

And one piece of guidance that belongs in every campaign brief: Adobe advises setting an activation’s start time at least one hour after completing the activation flow – a buffer Adobe’s own scheduling guidance builds in.

Stack it up. A new segment definition takes up to an hour to become available. Adobe advises a further hour before an activation starts. A batch destination exports on a three-hour cycle at best. The distance between “the audience is ready” and “the channel has it” is measured in hours on the batch path and in minutes on the streaming one – and which path a given channel uses is a decision made at integration time, not campaign time.

What part 3 covers

These four stations decide whether you can act, and how fast. What they do not decide is whether you are allowed to – or whether anyone will be able to tell afterwards what it changed.

Part 3 takes the last two stations and the two questions that sit around them: Govern, where the box drawn in every architecture diagram ships switched off; Measure, the thinnest station in the documentation and the one most often deferred to phase two; the warehouse question, where federating instead of copying costs you identity resolution; and what AI agents actually see when they run on top of all of it.

Frequently asked questions

What is real time segmentation?

Real time segmentation is audience evaluation that happens while the interaction is still running, rather than in an overnight batch. In Adobe Experience Platform it is not a setting: the platform picks edge, streaming or batch evaluation from the shape of the rule. Edge processes an inbound event in up to 350 milliseconds, streaming qualifies a profile in up to five minutes, and streaming has a lookback window limited to one day – so a rule reaching further back silently becomes a batch audience.

How is a unified customer profile actually assembled?

Data arrives in multiple datasets as profile fragments. Identity resolution determines which fragments belong to the same person. A union schema merges them into a union view, and a merge policy resolves conflicts – either by dataset precedence or by most recent timestamp. The result is a single profile the channels can read, subject to hard size caps and a recommended ceiling on events per profile.

When is an audience evaluated in real time instead of overnight?

It depends on how the rule is written, not on a setting. Adobe’s streaming segmentation has a lookback window limited to one day; rules referencing anything older fall back to the subsequent batch job. Multi-entity queries, certain nested-segment conditions and rules with no time window are also ineligible for streaming. Edge evaluation, the fastest tier at up to 350 milliseconds, is narrower still.

What is the difference between edge and hub decisioning?

Location and visibility, not speed alone. The hub holds the historical data and rich profile context. The Edge Network holds only audience memberships, profile identities and the attributes needed for personalization, on a rolling 14-day window. A decision that needs the history has to be made at the hub; one that needs only a membership flag can run at the edge in a few hundred milliseconds.

What has to be true before personalization works across channels?

Five things, in order: identities resolved into one graph; fragments merged into one profile; an audience rule whose evaluation speed matches the use case; a destination whose activation latency matches the moment; and governance policies actually enabled. A break at any one of the five produces personalisation that is wrong, late, or outside the boundaries you assumed were enforced – rather than personalisation that fails visibly.

Related reading: MarTech under the hood, part 1 – nothing works until the data is one person · What omnichannel marketing means – four roles, four answers · HCP portal, part 3 – the orchestration architecture.

Figures in this article are drawn from Adobe’s public documentation and link to their source; all pages were retrieved on 11 September 2026. Guardrails change with releases, and Adobe distinguishes between system-enforced limits and performance recommendations – verify against your own tenant before designing to any number, including these. Sources: Real-Time Customer Profile overview · Real-Time Customer Profile guardrails · Pseudonymous profiles · Experience event expirations · Segmentation Service overview · Streaming segmentation · Edge segmentation · Segmentation FAQ · Edge and hub comparison · Edge profiles · Destinations guardrails. Adobe, Adobe Experience Platform and Adobe Real-Time CDP are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe.

Every omnichannel programme starts with the same slide: a customer in the middle, channels arranged around them, arrows pointing inward. It is a good slide. It describes an outcome, not a system, and the gap between those two is where most programmes quietly stall.

Here is the test that separates the two. Multichannel and omnichannel differ in exactly one place: whether every channel reads the same profile, or whether every channel keeps its own list. Everything else – the arrows, the word “seamless”, the customer in the middle – follows from that one architectural fact. If your email platform holds one list, your web personalisation another, and your call centre a third, you are running multichannel with better vocabulary.

Making all channels read the same profile is not a procurement decision. It is nine of them, each with a technical consequence that shows up eighteen months later. This series walks all nine, using Adobe Experience Platform as the worked example – not because the answer is always Adobe, but because Adobe documents its limits publicly, and documented limits are the only way to talk about this honestly. Every figure links to the page it came from. Part 1 takes the first three – collection, the data model and identity resolution – the stations that decide whether you have a customer at all, and the identity graph where they either hold or quietly stop holding.

Four roles inside a company mean four different things when they say “omnichannel” – we mapped those four answers separately. This article is the layer underneath all four.

The stack, not the tool

The first confusion to clear up is the difference between a platform and an application built on it.

Adobe lists the applications built on Experience Platform as Real-Time CDP, Real-Time CDP B2B Edition, Journey Optimizer, Customer Journey Analytics, Journey Orchestration, and Mix Modeler. The platform underneath handles ingestion, the data model, identity, the profile, audiences, governance, and activation. The applications consume all of that.

This matters because of how buying decisions get described internally. “We bought Journey Optimizer” describes an application. It says nothing about whether the data underneath it is modelled, resolved, governed, or activatable – and those four are what decide whether the application does anything useful. The same separation exists in every stack, under different names and in a different arrangement.

One more piece of vocabulary before the stations, because it recurs at almost every one: the sandbox. It is the isolation boundary – a virtual partition of the platform with its own data, its own configuration, its own limits. Almost every number in this article is defined per sandbox. It is the most consequential invisible line in the architecture, and it appears on none of the diagrams.

Station 1 – Collect

Data arrives two ways, and they are not two speeds of the same thing. They are two paths into two different stores with two different sets of limits.

Batch ingestion moves files. Streaming ingestion moves events. The published timings sit further apart than the word “streaming” suggests.

• Streaming into the profile. Adobe publishes a service level of under 15 minutes at the 95th percentile for B2C ingestion, and under 30 minutes for B2B.
• What its troubleshooting guide observes. In practice, streamed events are “generally reflected in Real-Time Customer Profile in under 60 seconds”.
• Streaming into the data lake. The same path is documented at under 60 minutes.

Note what that means: the sub-minute figure is an observation in Adobe’s troubleshooting guide rather than a published latency, while the hour into the analytical store is documented. Two answers to “do we have that data yet”, both correct, depending on who is asking.

The throughput numbers run the same way round. Adobe’s performance guardrail for streaming into the profile and into streaming segmentation is 1,500 requests per second; into the data lake it is 4,000–5,000. The faster path is the narrower one. That is not a flaw, it is the trade – real-time processing costs headroom.

Two more figures worth carrying into any implementation plan.

• Batch into the profile. Adobe’s performance guardrail is 90 combined profile and event batches per sandbox per day – enough for a scheduled architecture, not enough for one that treats batch as a retry mechanism.
• The staging area. The Data Landing Zone, which many teams use as an informal handover point between systems, deletes everything after seven days: “Experience Platform enforces a strict seven-day expiration time on all files and folders uploaded to a Data Landing Zone container.”

A note on Adobe’s own documentation here, because it is instructive. The guardrails page states a maximum of 25,000 files and 1 TB per batch. The batch ingestion overview page states 1,500 files and 100 GB for the same thing. Both are current. When a vendor’s own two pages disagree, the practical answer is to design well inside the smaller number and to verify against your own tenant rather than against any article – including this one.

Station 2 – Model

This is the station teams rush, and it is the only one in the chain that is effectively irreversible.

Adobe’s data model is XDM – the Experience Data Model. Its composition rule is stated as a formula: “Class + Schema Field Group* = XDM Schema”. The class decides whether a schema describes things as they are (record data – a customer, a product, an account) or things as they happened (time-series data – a click, a purchase, an email open). That choice is made once, at the class, and everything downstream inherits it.

Schema evolution follows what Adobe calls a purely additive versioning principle: changes are only permitted if they are non-destructive. You may add fields. You may make a required field optional. You may not remove a field, rename it, move it, relax a value restriction, delete a schema, or disable its participation in the profile. Once real data has been ingested, “the rules of schema evolution become strictly enforced”, and fields “will become non-editable across all XDM schemas in which they are referenced”.

One item on the prohibited list deserves to be read twice: “Changing primary identity on Profile-enabled schemas with ingested data.”

The primary identity is the field that says this row is a person, and this is which person. Choosing it is a modelling decision made early, often by whoever is closest to the source system, often before anyone has thought about what the identity strategy will look like in three years. After the first row of production data, it is fixed.

Everything else in this article can be rebuilt. Audiences can be rewritten, destinations reconnected, policies enabled, journeys redesigned. The data model cannot – not without a migration that touches every downstream object. It deserves a proportionate amount of the project’s attention, which is roughly the opposite of what it usually gets.

Station 3 – Resolve

Here is where omnichannel either works or fails silently. Not loudly. Silently.

A customer is not one identifier. They are a browser cookie on a laptop, another on a phone, an app install ID, a hashed email from a newsletter, a CRM record, a loyalty number, a second browser after they cleared cookies last month. Identity resolution is the process of deciding that all of those belong to one person.

Adobe’s Identity Service does this by building an identity graph – the set of identities that represent one customer. Each identifier sits in an identity namespace: Email, Phone, CRMID, ECID, and any custom namespace you define. There is no limit on how many custom namespaces you can create.

There is, however, a limit on the graph.

Fifty

“The maximum number of identities in an Identity Graph for an individual profile is 50. Any profiles with more than 50 identities are excluded from segmentation, exports, and lookups.”

Fifty sounds generous until you count a real household. Four people. Three devices each. Two browsers per device. Cookie clearing every few weeks, each clear generating a fresh ECID. A shared tablet that links two family members’ identities into one graph. A work laptop and a personal one. Add a customer-service interaction that writes a case ID as a namespace, and a loyalty programme that writes its own.

Fifty arrives faster than anyone plans for. And what happens then is worth quoting exactly: when a graph with 50 linked identities is updated, Identity Service “will apply a ‘first-in, first-out’ mechanism and deletes the oldest identity to make space for the newest identity for this graph”.

The eviction is not random. It prioritises by identity type – Cookie ID first, then Device ID, then the durable person identifiers grouped together as Cross-Device ID, Email and Phone – and within a type, by the timestamp on the identity. The design is sensible: throw away the cheap identifiers before the durable ones.

But note the two things it does not do. It does not warn you. And namespace priority does not protect you: Adobe states plainly that “namespace priority does not affect graph behavior when the limit of 50 identities per graph is reached”. The priority you configured governs which links survive a conflict. It does not govern which identities survive the cap.

The small things that break an identity graph

• Identity Service is case-sensitive. Adobe’s own example: “abc@gmail.com and ABC@GMAIL.COM would be treated as two separate Email identities.” If one source system uppercases email addresses and another does not, you are not building one graph. You are building two, and they will never merge.
• ECIDs have a format. Exactly 38 characters, digits only. Records that do not conform are skipped at ingestion. Identity values in general may not exceed 1,024 characters, and may not be the strings “null”, “anonymous”, “invalid”, or empty.
• You get three unique namespaces. Declaring a namespace unique means a graph can hold only one identity in that namespace – the mechanism that stops one CRM ID from collapsing into another. You may configure a maximum of three, and changes take up to 24 hours to take effect.

The repair rule

When a graph has collapsed – when two people have merged into one profile because of a shared device or a bad key – changing your configuration does not repair it retroactively:

“Existing collapsed graphs will be affected (‘fixed’) by the graph algorithm only if these graphs get updated after you save your new settings.”

A collapsed graph for a customer who has not been active since the fix stays collapsed. Your configuration is correct. Your dashboard is green. The profile is still wrong, and it will stay wrong until that person comes back.

This is what “fails silently” means in practice. There is no error state, no queue of rejected records, no alert. There is a profile that stopped being targetable, and a number in a report that is quietly lower than it should be.

We walked one version of this in detail – an authenticated portal where the ECID, the CRM identity and the streamed consent record all have to line up before a physician sees the right page.

What part 2 covers

The three stations in this article decide whether you have a customer at all: whether the data arrives, whether it is modelled so it can be used, and whether the fragments resolve into one person. Get those wrong and nothing downstream can compensate – an audience built on a collapsed identity graph is wrong no matter how good the campaign is.

Part 2 takes the next four: Unify, where fragments become a profile with an expiry date; Segment, where “real time” turns out to be a property of the rule rather than the platform; Decide, where the constraint is not capacity but what a decision can see; and Activate, where the timing assumptions in campaign plans meet documented reality. Part 3 closes with governance, measurement, the warehouse question and what AI agents change.

Frequently asked questions

What is the difference between multichannel and omnichannel, technically?

Whether every channel reads the same customer profile or each keeps its own list. In a multichannel stack, the email platform, the web personalisation engine and the contact centre each hold their own copy of the audience. In an omnichannel stack, all three read one profile, resolved from one identity graph. Everything else – consistent messaging, recognised customers, continuous journeys – is a consequence of that single structural difference.

How does identity resolution work in a CDP?

Every identifier a customer produces – cookie IDs, device IDs, hashed emails, CRM records – is placed in a namespace and linked into an identity graph representing one person. Links form when a shared signal ties two identifiers together, such as a login tying a browser cookie to a known account. The quality of resolution depends entirely on the quality and consistency of the keys your source systems write.

What is an identity graph, and does it have a limit?

An identity graph is the set of identities that represent one customer. It has a documented ceiling: Adobe caps an individual profile’s graph at 50 identities, and a profile above that is excluded from segmentation, exports and lookups. When a full graph is updated, the oldest identity is deleted first – cookie identifiers before durable ones. No error is raised.

What does it actually take to run omnichannel marketing?

Nine capabilities that have to work in sequence: collection, a data model, identity resolution, a unified profile, segmentation, decisioning, activation, governance, and measurement. None can be skipped and none can be bought as a finished product – each is a set of decisions with documented limits attached. The platform is the easy part. The nine decisions are the work.

Related reading: What omnichannel marketing means – four roles, four answers · HCP portal, part 2 – the data walks a permission chain.

Figures in this article are drawn from Adobe’s public documentation and link to their source; all pages were retrieved on 11 September 2026. Guardrails change with releases, and Adobe distinguishes between system-enforced limits and performance recommendations – verify against your own tenant before designing to any number, including these. Sources: Data ingestion guardrails · Streaming ingestion overview · Data Landing Zone · XDM schema composition · Identity Service guardrails · Identity Service overview · Real-Time Customer Profile guardrails · Identity Graph Linking Rules. Adobe, Adobe Experience Platform and Adobe Real-Time CDP are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe.