What Omnichannel Really Means – for Four Roles in the Company
Omnichannel marketing is not a channel and not a tool. It is the state in which customer data, decision logic and delivery are connected so that every message knows the same things about the customer. What that means in practice depends on where you sit: in marketing it means different campaigns, in analytics different questions, in management different numbers. In architecture it means different decisions, and most of the work.
In 60 seconds
Omnichannel rarely fails at the channel. It fails at the handovers between marketing, analytics, leadership and architecture — at the points where one role assumes something another never agreed to deliver. This article describes, for each of the four roles, what omnichannel actually means, where it breaks down, and what that role needs from the others.
Where do you sit?
Omnichannel means something different in each of the four roles. Pick yours — the article answers them one at a time.
A message no longer sits at the start and the end of a campaign, but inside a journey that keeps running. Timing becomes a variable, and frequency applies per person rather than per campaign.
Where it breaksSend-Time Optimization does not know about quiet hours — and quiet hours only apply if the profile has a time zone.
To the marketing chapter →The work shifts from analysis at the back to modelling at the front. The question is no longer what happened, but which event has to be created so the journey can react to it tomorrow.
Where it breaksThe identity graph holds a maximum of 50 identities per person. Above that, deletion runs first-in, first-out, starting with cookie IDs.
To the analytics chapter →An investment decision with an uncomfortable property: the benefit only appears once several layers are finished at the same time. A half-connected system costs twice and delivers nothing.
Where it breaksMeasuring the build phase with the numbers of the operating phase. Both yardsticks are right, just not at the same time.
To the leadership chapter →A chain of decisions nobody sees later — and which determine whether the other three roles get what they expect. Data ownership, mapping, and the place where the decision is made.
Where it breaksGovernance is not standard scope: consent policies are licensed, and all policies are disabled by default.
To the architecture chapter →Omnichannel marketing is the orchestration of communication across several channels on the basis of one shared customer profile and one shared decision logic. The difference from multichannel is not the number of channels but the fact that all channels share the same state of knowledge: whoever opts out by email is also opted out in the push channel. Whoever bought yesterday sees no ad for the same product today.
That sounds obvious and is rarely the case in practice, because the four groups working on it each mean something different by “omnichannel”. The handover points between them are where projects fail. A Harvard Business Review study of B2B sales organisations reaches the same conclusion: multichannel treats channels as silos, omnichannel presupposes a cross-channel view of the customer.
For the marketing team: the same person, not the same list
For a campaign team, omnichannel means that a message no longer sits at the start and the end of a campaign but within a journey that keeps running.
An email is delivered with an identifier that the customer brings along when clicking. The website recognises them and, instead of the home page, shows the context they came from. What they do there is then stored in the same profile from which the next message is built. If they are in a second journey at the same time, say the welcome series and a reactivation, the system notices the conflict instead of sending both.
Timing becomes a variable. Adobe Journey Optimizer offers Send-Time Optimization for this: a model that calculates a probability for every hour of the week from 16 weeks of open and click behaviour and places the send within a chosen window of 2 to 100 hours. Salesforce does the same with Einstein Send Time Optimization: 90 days of engagement data, a probability score for each of the 168 hours of the week.
Frequency applies per person, not per campaign. Frequency rules can be defined across channels; the documentation explicitly states that several channels can be selected if the cap is meant to apply as a total across all of them.
Content becomes a rule instead of a text. Personalisation accesses the same profile fields as the journey’s entry condition; fragments keep mandatory information in one place and, according to the documentation, are automatically propagated to all content that uses them, including live journeys, as long as the inheritance has not been broken.
Two functions with the same goal do not talk to each other. Adobe documents as a guardrail that Send-Time Optimization does not know about quiet hours. Quiet hours in turn only apply if the profile has a time zone, verbatim: If a profile has no time zone value, quiet hours are not enforced for that profile.
An empty attribute disables the safeguard, and nobody notices until a push goes out at night.
Quick check · Quiet hours
Quiet hours are configured. For which profiles do they still not apply?
The gap nobody reports
In practice this rarely fails because a function is missing. It fails because the teams that build campaigns do not know the range of what their own tool can do. You cannot order what you do not know, so you fall back on the orchestration you have mastered: list, send, report. The platform could do more, but nobody asks for it.
This is not a question of competence but of opportunity. A campaign team with a full send calendar does not have an hour in which it is allowed to try out a function. Besides, the things that make the difference are rarely the big ones: an additional event in the tagging, a small data set that makes a condition possible in the first place, a field that has long existed and that nobody has been shown. Someone has to actively demonstrate such details, an architect or a product owner who knows both sides.
Behind this lies an organisational pattern in which marketing formulates a wish and technology builds it. For a single campaign that works. For omnichannel marketing it does not, because the interesting use cases only emerge once both sides know what the other has. In a waterfall, marketing ends up with what it was able to imagine, and that is regularly less than what would have been possible. Harvard Business Review described this pattern back in 2016 under the title “Bridging the Gap Between Marketing and IT”: as long as IT acts as a gatekeeper instead of sharing responsibility for outcomes, the supplier relationship persists.
Marketing wishes, technology builds: that is a supplier relationship. Omnichannel is not one.
- a profile with a maintained time zone and consent per channel
- clean events instead of lists built after the fact
- a decision on which channel takes precedence when two journeys apply at the same time
- a sandbox with realistic test data in which experimenting is allowed
How such enablement is set up is a topic in its own right.
For the analytics team: raw data becomes decisions
For analysts, omnichannel marketing shifts the work from evaluation at the back to modelling at the front. The question is no longer what happened, but which event needs to be created so that the journey can react to it tomorrow.
The difference sounds academic and is not. A raw record from the warehouse is a state. A journey needs an event, something that happened at a point in time and remains immutable. Adobe separates the two through two classes: the state-describing profile and the time-based Experience Event. Whatever is modelled as an attribute can be checked in a condition. Whatever is modelled as an event can trigger a journey. This decision is made in the data model, not in the campaign.
In between sit the flags: derived attributes that carry a decision without transferring the raw field. A customer’s origin, value tier, region instead of address. They are created at import and are the point at which a database becomes a basis for decisions.
Identity is a modelling question. Whether a device ID, an email and a CRM ID become one person is decided by the Identity Graph on the basis of namespaces. Merge Policies define which record wins when two sources contradict each other, either by dataset precedence or by timestamp.
Where the evaluation happens matters too. An audience that is meant to be evaluated on the edge has to be modelled for it. The documentation leaves no doubt about this. If an audience contains only profile attributes, it is evaluated just once a day, even on the edge.
The data was already there
The most common misconception before an omnichannel initiative is that data has to be collected first. In the projects I have supported, that was never the problem. Events and identifiers had long been flowing into the company, often into a dedicated warehouse or an existing customer data platform, looked after by data architects with a good overview. The work lay in modelling the same data so that a journey can read it.
Specifically, that meant the right mapping to XDM so that an existing field becomes an addressable attribute. Transferring the right datasets in the first place, and deliberately not the wrong ones. Data quality against duplicates before they turn into two profiles for one person; a study in Harvard Business Review found in 2017 that only three per cent of the company data records examined met basic quality standards. And finally identity resolution: which identifier from which channel may be merged with which, and which one is ultimately the leading one.
These questions sound technical and are business decisions. This is clearest in a case every company knows: A customer has two email addresses. Is that two people or one? Merge them and you risk fusing two different people. Keep them separate and you risk an unsubscribe reaching only half the person, so the customer keeps receiving mail despite having opted out. Both are errors, but only the second is a legal problem. The answer therefore does not belong in the rule configuration but in a decision that someone is accountable for, and afterwards in rules that automatically exclude such cases from delivery.
The Identity Graph holds a maximum of 50 identities per person. When the limit is exceeded, Adobe deletes on a first-in-first-out basis, starting with cookie IDs. Namespace priority no longer helps at that point; the documentation makes it explicit that it has no effect once the limit is reached. A company that collects many anonymous sessions thereby loses the very link it built the whole thing for.
- the business question before the field: which decision is to be made?
- from architecture, the assurance that events arrive reliably and in the right order
- from the business side, an accountable answer to the question of when two identifiers mean the same person
For marketing leadership: which number justifies the budget
At CMO level, omnichannel marketing is not a feature list but an investment decision with an uncomfortable property. The benefit only materialises once several layers are finished at the same time. A half-connected system costs twice as much and delivers nothing.
Two phases, two definitions of success
The most common mistake at this level is to measure the build phase with the numbers of the operating phase. Both yardsticks are right, just not at the same time.
In the first phase, success is a gain in capability. Data pipelines are extended, new data points are added, and from them emerge use cases that were not possible before: a customer score, an activation level, a segmentation based on behaviour rather than membership. The real effect is that decisions and follow-up steps are made on the basis of data at all. Existing channels get new use cases before new channels are added.
Open rates, click counts and bounces are the wrong metric in this phase. Not because they are unimportant, but because the reference base underneath them is changing: different audience logic, different triggers, different frequency. A metric whose population is changing measures nothing.
In the second phase this reverses. Once the journeys are running, impact is the only question that counts. Then three effects carry the case, and one of them is the one least talked about.
Media budget stops paying for existing customers. When audiences from the company’s own profiles are activated to advertising platforms, customers can be excluded deliberately. Adobe names the use case in its B2B blueprint: exclude existing customers, won accounts and open sales processes from acquisition campaigns in order to reduce wasted spend. The premise behind it is proven. Blake, Nosko and Tadelis showed in Econometrica, using a geographically randomised shutdown of search ads at eBay, that a large share of the budget goes to users who would have bought anyway.
Frequency becomes controllable, unsubscribes fall. Cross-channel frequency rules limit how often a person is contacted in total. The evidence for the effect is more robust here than for most marketing topics: Zhang, Kumar and Cosguner examined the relationship between contact frequency and churn in the Journal of Marketing Research, Sahni the effect of spacing between contacts in randomised field experiments.
Impact becomes measurable instead of plausible. Journey-level holdout deliberately keeps a configurable share of the audience out of the journey. Comparing the two groups shows what the campaign caused, not what was attributed to it. The feature has been in limited availability since September 2026; the measurement itself runs through Customer Journey Analytics, not in journey reporting.
Attribution distributes credit. It does not measure impact. That is a difference that costs budgets.
This point deserves clarity because it runs against habit. Gordon, Zettelmeyer, Bhargava and Chapsky evaluated fifteen randomised experiments with around 500 million observations in Marketing Science and showed that observational methods regularly miss the advertising effect, mostly overstating it. Lewis and Rao demonstrated in the Quarterly Journal of Economics, using 25 field experiments, that the usual sample sizes are not sufficient for a robust ROI statement. A budget that rests on an attribution model rests on an allocation rule, not on evidence.
The open rate has in any case not been usable as a target metric since Apple’s Mail Privacy Protection. Apple loads remote content in the background and hides the IP address, which structurally distorts open events. Sahni, Wheeler and Chintagunta showed in a randomised experiment that opens and leads respond to different degrees; the proxy does not scale with the outcome.
For the causal effect of excluding existing customers on acquisition costs there is no peer-reviewed study and no working paper with a disclosed test design. All figures of this kind in circulation come from vendor case studies without a control group. A robust number for your own company has to be measured yourself, via a geographic split or a ghost-ads design.
The two-phase split does have one condition, though, or it becomes an excuse. The build phase needs an end date and a commitment as to when impact will be measured. Without that agreement, an initiative stands there after eighteen months with many new capabilities and not a single robust number, and it becomes a matter of debate at the very moment a budget is renegotiated. Separating the phases means scheduling the transition.
- an honest statement of which layers have to be finished before the first effect appears
- an explicit agreement on when to switch from capability to impact
- the willingness to tolerate a holdout group instead of seeing it as wasted reach
For architecture: where the decision is made decides everything
In architecture, omnichannel marketing is not a feature but a chain of commitments that nobody sees later and that determine whether the other three roles get what they expect.
The first commitment is data ownership: which system remains the system of record, and which slice does the platform get? The second is the mapping: which raw field is transferred, which attribute is derived at import, which retention period applies per dataset. The third concerns the place where the decision is made.
Hub or edge is not a matter of detail. According to the documentation, the edge profile processes behavioural data only, data from the hub is held there for a maximum of 14 days, and there can be differences between the two. Website personalisation is therefore promised on this basis, not on the full profile.
Client-side or server-side is a product decision. The web channel in Journey Optimizer can be implemented client-side or hybrid; a pure server-side implementation is explicitly not supported. For Adobe Target: without the Web SDK there is no edge segmentation and no same-page or next-page personalisation.
A dedicated tracking domain is recognition, not cosmetics. Adobe documents first-party device IDs that are set server-side via a DNS entry and captured via CNAME, with a clear rationale: cookies set via JavaScript are almost never protected from browser policies. Apple has limited such cookies to a lifetime of seven days since ITP 2.1.
Quality assurance here means above all the return path. A purchase, an objection or an unsubscribe has to go back into the system of record, reliably, with error handling and traceably. Otherwise the platform is right but the data the company relies on is not.
Governance is not standard scope. Adobe documents that consent policies are only available to organisations that have licensed Healthcare Shield or Privacy & Security Shield, and that all policies, including the ones shipped with the product, are disabled by default. The assumption that consent is enforced automatically therefore presupposes something that first has to be switched on and usually paid for in addition.
In practice the answer is: it depends on the use case
In theory you decide once whether to work client-side or server-side. In practice you inherit that decision. Companies with a grown landscape run legacy systems and older licences that dictate one variant: sometimes because the licence level only covers one operating mode, sometimes because a predecessor system brings an integration that nobody touches without good reason.
The uncomfortable consequence is that the question is not answered once but checked per use case. That creates effort and does not yield a neat target architecture. But it is more honest than a commitment that is overturned in the first implementation step, and it prevents a use case being promised that the existing licence does not support at all.
What makes the difference in the end
The following paragraph is an assessment from project work, not a documented finding. But it is the point I keep coming back to. The most effective measure in an omnichannel initiative is not a technical one. It consists of bringing everyone involved to one table before decisions are made: marketing, analytics, architecture, leadership and the people who know the legacy systems. Not as a kick-off meeting, but as a way of working for the duration of the project.
This is due to the structure of the task. Each of the four roles makes decisions that bind the other three, and none of them can make those decisions correctly on its own. The scope of the datasets helps determine which campaign will be possible later. The definition of an audience helps determine whether it is evaluated hourly or daily. The measure of success helps determine whether a holdout group is planned or not. These dependencies cannot be resolved by requirements documents, only by the people involved having the same discussion.
- the use cases before the data model
- a decision on what the company will not hand over
- transparency about existing licences and legacy systems before an operating mode is promised
- a format in which the four roles decide together instead of delivering one after another
Where omnichannel projects actually fail
Not because of the technology, but at the points where one role assumes something that another would have to deliver, without anyone having written it down.
| Handover | Expectation | What is actually missing | Consequence in operation |
|---|---|---|---|
| Marketing → Analytics | “Reach the customer at the right time” | Time zone in the profile, consent per channel | Safeguards do not apply, message goes out at night |
| Analytics → Architecture | “The journey should react in real time” | Event modelled instead of attribute | Audience is evaluated daily instead of immediately |
| Architecture → Marketing | “The website personalises from the profile” | Clarity that the edge only sees behaviour and 14 days | Promised content does not appear |
| Leadership → everyone | “Show me the effect” | Holdout group planned from the start | After the fact, the effect can no longer be proven |
| Everyone → Marketing | “Tell us what you need” | Knowledge of what the platform can do | What gets ordered is what is known – not what would be possible |
Strikingly, none of these rows describes a tooling problem. Each describes an assumption that was never spoken out loud. The last row is the most uncomfortable, because it cannot be solved by a document. Only those who have seen what can be ordered are able to order it.
That is why the most effective measure at the start of a project is not an architecture diagram but three things: a list, an appointment and a way of working. The list: which decision is to be made, which information carries it, who delivers it, by when it is approved. The appointment: one hour in which someone shows the campaign team what already exists in the platform. The way of working: the four roles deciding together instead of delivering one after another. All three cost almost nothing and prevent most of the rows in the table.
In regulated industries a fifth role joins the table
In pharma, medical devices and financial services there is someone else at the table who does not appear in any of the rows above: the review body. In pharma communication that is MLR approval, at a bank the data protection and security review. It does not decide what gets built, but whether it may go live. And it asks questions that none of the four roles asks on its own: which data may reach the platform at all, how long it stays there, and how it is proven that it disappears again.
In regulated industries, omnichannel marketing is therefore not a different concept but the same one with an additional handover that has to start earlier than all the others. What that means per industry is described under Industries; what it looked like in practice in a banking project is in the case study: attribute catalogue, schema design, audits.
Omnichannel marketing – short answers
What is the difference between multichannel and omnichannel?
Does omnichannel necessarily require real time?
Is omnichannel marketing a marketing project or an IT project?
How do you measure the success of an omnichannel project?
How do I know whether my company is ready?
What does governance cost, and is it included in the product?
Omnichannel Orchestration Architect for pharma, medical devices and financial services. Builds target architecture, data foundation and orchestration hands-on, as architect, administrator and campaign engineer in one person. The examples in this article come from my own projects with Adobe Experience Platform, Journey Optimizer, Salesforce and Veeva.
Vendor documentation (Adobe Experience League and Salesforce Help, retrieved 2 September 2026, English version as primary source): Send-Time Optimization · Einstein Send Time Optimization · Quiet hours · Frequency capping · Manage fragments · XDM schema composition · Identity Service guardrails · Identity graph linking rules · Merge policies · Edge segmentation · Edge and hub comparison · Adobe Target connection · Web channel prerequisites · First-party device IDs · Automatic policy enforcement · Data usage policies · B2B audience activation blueprint · AJO release notes (journey-level holdout) · WebKit: ITP 2.1 · Apple Mail Privacy Protection.
Studies (peer-reviewed): Blake, Nosko, Tadelis, “Consumer Heterogeneity and Paid Search Effectiveness”, Econometrica 83(1) 2015, 10.3982/ECTA12423 · Gordon, Zettelmeyer, Bhargava, Chapsky, “A Comparison of Approaches to Advertising Measurement”, Marketing Science 38(2) 2019, 10.1287/mksc.2018.1135 · Lewis, Rao, “The Unfavorable Economics of Measuring the Returns to Advertising”, Quarterly Journal of Economics 130(4) 2015, 10.1093/qje/qjv023 · Zhang, Kumar, Cosguner, “Dynamically Managing a Profitable Email Marketing Program”, Journal of Marketing Research 54(6) 2017, 10.1509/jmr.16.0210 · Sahni, “Effect of Temporal Spacing between Advertising Exposures”, Quantitative Marketing and Economics 13(3) 2015, 10.1007/s11129-015-9159-9 · Sahni, Wheeler, Chintagunta, “Personalization in Email Marketing”, Marketing Science 37(2) 2018, 10.1287/mksc.2017.1066 · Johnson, Lewis, Nubbemeyer, “Ghost Ads”, Journal of Marketing Research 54(6) 2017, 10.1509/jmr.15.0297.
Harvard Business Review: Chung, Huber, Devignes, Clauwaert, “How B2B Businesses Can Get Omnichannel Sales Right” (2022) · Protexter, Shumway, “Bridging the Gap Between Marketing and IT” (2016) · Nagle, Redman, Sammon, “Only 3% of Companies’ Data Meets Basic Quality Standards” (2017). Own illustrations; project statements are assessments from consulting practice and marked as such.