What a MAP does
A Marketing Automation Platform is the system that executes marketing logic: it decides which message a specific contact receives, in which channel and at what moment. Everything else in it serves that task.
| Functional block | What it contains |
|---|---|
| Scenario builder | A visual sequence with branches, delays, conditions and event waits |
| Triggers | Starting a scenario on action or inaction: a site event, entry into a segment, a date, an attribute change |
| Channel orchestration | Choice of channel and order of contact, frequency capping, priority rules between campaigns |
| Campaign management | Calendar, audiences, approvals, launch and stop, control groups |
| Scoring | Rating a contact on actions and attributes — for prioritisation and branch selection |
| Reporting | Campaign and scenario metrics: deliverability, opens, clicks, conversions, revenue contribution |
The key word here is scenario. A one-off send to a list is not yet automation; a MAP begins where sequences that react to behaviour appear: drip campaigns, reactivation, work with abandoned actions, programmes organised by lifecycle stage.
Separating the classes of system
The most common confusion in a pre-sale is treating a MAP, a CDP, an ESP, a CRM and a personalization platform as alternatives to each other. They are different layers of one stack, and almost any mature e-commerce operation runs all five — sometimes inside a single product, sometimes as separate systems.
| What it stores | What it manages | Where the content lives | Typical owner | |
|---|---|---|---|---|
| MAP | Contacts, segments, scenario states, communication history | Communication logic: whom, when, under what condition | Message templates and scenarios inside the system | CRM marketer, head of CRM |
| CDP | Raw events, identifiers, unified profiles | Data: collection, identity resolution, segmentation, passing segments onward | No content — only data and audiences | Analyst, product manager, data team |
| ESP | Addresses, delivery statuses, unsubscribes, domain reputation | Transport: delivering the message into the channel | Email templates | CRM marketer, deliverability specialist |
| CRM | Customers, deals, tickets, relationship history | Relationships and sales rather than campaigns | Usually no marketing content | Sales, customer service |
| Personalization platform | Behavioural profile, view events, product catalogue | The experience on site and in app during the visit | Recommendation blocks, banners, popups, dialogues | Head of e-commerce, product manager, site marketing |
The difference between a CDP and a MAP fits in one phrase: a CDP answers who this is, a MAP answers what to do with them. The difference between a MAP and an ESP is simpler still: an ESP can send, a MAP decides what to send and when. The boundary moves, because vendors extend functionality in both directions, but when designing a stack it is useful to keep the roles separate even where they are technically implemented in one product.
How it fits together in a real stack
The standard data-flow diagram in e-commerce looks like this:
Site / app
| events: views, clicks, cart, order
v
CDP / data layer ---- segments ----> MAP ---- messages ----> ESP / channel
| |
| profile, audiences | contact state, campaign statuses
v v
Personalization platform CRM
| content, product order,
v recommendation blocks
Site / app
The direction of exchange matters more than the set of systems. Four connections work reliably in practice:
- Site events into the MAP. A user action starts a scenario. This is the classic event-based trigger: for it to be possible, the platform collecting site behaviour must be able to emit events outward.
- MAP segments into the site. Segment membership is used to choose site content — someone in the placed an order this week segment should not see the popup meant for new customers.
- The personalization profile into content for other channels. Personal product blocks are generated by the personalization platform and delivered by whichever system the company already runs.
- CRM orders into the MAP and the CDP. A purchase closes scenarios, updates segments and resets frequency counters.
Where conflicts arise
| Area | Symptom | What to do |
|---|---|---|
| Duplicated segmentation | The same segment is built in the CDP and in the MAP, and the numbers differ | Fix the source of truth for segments; the second system only receives finished audiences |
| Several event trackers | Different systems report different session and order counts | One event collection layer, with the other systems fed from it |
| Frequency conflict | The user receives several communications in a row from different scenarios | Shared frequency and priority rules at the orchestrator level, not inside each campaign |
| Disputed data ownership | The customer profile diverges between CRM, CDP and MAP | An explicit model: where the identifier is maintained, where contact details are, where consents are |
| Result attribution | Every system claims the revenue, and the total exceeds reality | One attribution model and shared control groups instead of each system’s internal reports |
Having a MAP does not remove the need for analytics, and having a CDP does not remove the need for a MAP. The sign of a healthy stack is not the minimum number of systems but the absence of entities maintained in two places at once.
The line with onsite personalization
This boundary is worth stating explicitly, because it is where false expectations most often appear during vendor selection.
A personalization platform does not substitute for a MAP. It is responsible for what happens to a person during the visit: the product order in a category, the contents of recommendation blocks, the content of banners and popups, the behaviour of the shopping assistant, the screens of the mobile app. Its horizon is the current session and the accumulated behavioural profile.
A MAP is responsible for what happens between visits — outbound communications, their sequence and their channels. That is a separate class of system with its own delivery infrastructure and its own consent requirements.
| Question | Who answers it |
|---|---|
| Which products to show in the block on a product page | Personalization platform |
| How to sort a category | Personalization platform |
| Whether to show a popup, and which one | Personalization platform |
| How many hours after an abandoned cart to remind, and in which channel | MAP |
| How to build a sequence by lifecycle stage | MAP |
| Who enters the audience of a scenario | CDP or MAP, depending on the architecture |
The overlap between the layers lies in data rather than features: site events feed scenarios, segments influence content, and content personalization works in both directions — on the site the personalization platform applies it, and for external channels it can hand ready-made personal blocks to whichever system serves those channels.
Checklist for designing the stack
- List entities, not systems. Profile, identifiers, consents, segments, events, templates, frequency rules — and name exactly one owning system against each.
- Check where the flow breaks. The most frequent gap is site events that go nowhere, leaving scenarios built on order data alone.
- Define frequency rules globally, not inside each campaign.
- Agree the attribution model before launch, otherwise the systems’ reports will collectively claim more revenue than exists.
- Build in control groups at the stack level — the only way to separate the effect of communications from the effect of onsite personalization.
- Do not buy duplicate functionality for the sake of one missing feature: it is usually cheaper to extend the data exchange between what is already in place.