Four Gravities Shaping MarTech Decisions: Suite, CRM, Data and Engagement

Most MarTech platform decisions are presented as comparisons: Adobe versus Salesforce, Braze versus Bloomreach, CDP versus CEP, suite versus best-of-breed, composable versus integrated, warehouse-native versus platform-native.

The comparison is useful, up to a point. After a while, however, most feature matrices start to hide more than they reveal. They tell you whether two platforms both support segmentation, journey orchestration, experimentation or AI-assisted content, but not what each platform expects the rest of the architecture to become.

That difference matters because platforms are not neutral collections of features. Every major platform has a centre of gravity, and it pulls data, decisioning, governance, teams and budget toward the place where its worldview is strongest. Sometimes that centre is the experience suite, sometimes the CRM, sometimes the warehouse or lakehouse, and sometimes the customer engagement runtime where signals are received and actions are executed.

The practical question is therefore not only which platform has the strongest feature set. It is which gravity you want your architecture to obey. And that leads to the question that matters most of all:

What should own the customer decision?

Who decides that this customer should receive this message, on this channel, at this moment, with this offer, under these constraints? A suite, a CRM, a data platform and an engagement runtime can all answer that question, but they answer it differently, because each starts from a different form of context, creates a different operating model and fails in a different way.

Four gravities at a glance

Before going deeper, it helps to name the four forces and the shape of each one. The rest of the article works through them one at a time, so treat this as the map rather than the territory.

1. Suite Gravity

Primary objective: Experience coordination
Core context: Profiles, audiences, content, journeys, offers, experimentation and analytics
Typical anchors: Adobe Experience Platform, Adobe Journey Optimizer, Real-Time CDP, AEM, Customer Journey Analytics and Target
Natural operating owner: Experience, content and marketing operations teams
Principal risk: Implementation complexity and deep ecosystem dependency

2. CRM Gravity

Primary objective: Relationship lifecycle management
Core context: Customers, accounts, opportunities, contracts, cases, sales and service activity
Typical anchors: Salesforce CRM, Data Cloud, Marketing Cloud, Flow and Agentforce
Natural operating owner: CRM, sales operations, service operations and commercial teams
Principal risk: Engagement becoming too CRM-shaped and too slow for high-frequency behavioural contexts

3. Data Gravity

Primary objective: Centralised intelligence and governance
Core context: Enterprise data models, identity, consent, events, transactions, scores and analytical logic
Typical anchors: Databricks, Snowflake, BigQuery, Hightouch, Census, RudderStack and composable CDP patterns
Natural operating owner: Data engineering, analytics, MarTech architecture and data activation teams
Principal risk: Operational distance between intelligence and execution

4. Engagement Gravity

Primary objective: High-velocity customer interaction
Core context: Live behaviour, channel history, frequency, timing, content response and journey state
Typical anchors: Braze, Bloomreach, Iterable, Klaviyo, Insider One, MoEngage and similar customer engagement platforms
Natural operating owner: CRM marketing, growth, lifecycle, mobile and campaign operations teams
Principal risk: Fast local decisioning without enough enterprise context or cross-system governance

These four gravities are not mutually exclusive, and most large organisations need all of them. One often dominates the overall operating model, but different gravities may legitimately lead different layers of the customer decision. When those responsibilities are explicit, the architecture becomes easier to reason about. When they are left implicit, systems start competing for the same decisions.

Diagram: Four centres of gravitational pull affecting MarTech decisions: Suite, CRM, Data and Engagement

Why feature comparison is not enough

Feature comparison is still necessary, and I use it all the time. A platform evaluation needs to establish whether a product supports email, mobile push, in-app messaging, web personalisation, journey branching, experimentation, paid media activation, identity resolution, consent management, real-time APIs, reporting, AI assistance and the rest of the long list.

But a feature matrix is a starting point, not a strategy, and the mistake is treating capabilities with the same name as if they were architecturally equivalent.

Two platforms may both offer segmentation. In one, segmentation is a native layer on top of an experience profile. In another, it is computed from warehouse models. In another, it is tied to CRM records and account structures. In another, it is continuously updated from live interaction signals. The same is true of AI-assisted campaign creation: one platform generates assets inside a governed content supply chain, another acts from sales, service and account context, another optimises audiences from the enterprise data layer, and another adapts timing, channel and content from observed behaviour. The feature name is identical. The architectural meaning is not.

Teams compare capabilities horizontally, while platforms pull vertically, toward the place where they are strongest and where they expect the rest of the stack to align. Most demos are physics-free: they show the output without showing the friction of that pull. The job of architecture is to identify the friction before implementation makes it permanent.

Recent market signals: vendors are building gravity

Recent acquisitions and product announcements make this model less theoretical. Vendors are not only adding features. They are buying, building and defending control points around data, content, identity, decisioning and customer interaction.

Salesforce signed definitive agreements to acquire Contentful and Fin. Both transactions remain subject to closing conditions, but the direction is already clear. Contentful would strengthen Salesforce’s composable content layer, while Fin would extend customer-agent and service capabilities. CRM gravity is expanding beyond the customer record into the content, knowledge, workflow and autonomous interaction required to operate around that record.

Databricks introduced CustomerLake, currently available in private preview, as an agentic CDP built natively on the lakehouse. Databricks is positioning the data platform not only as the place where customer information is stored and governed, but as the place where identity resolution, audience creation, campaign logic, agents and activation can operate. That is a direct data-gravity signal.

Adobe completed its acquisition of Semrush and then introduced Adobe Brand Visibility, combining Semrush intelligence with Adobe’s content and customer experience capabilities. I read this as suite gravity extending earlier in the customer journey, into the AI and search surfaces where brands are increasingly discovered, interpreted and compared.

MoEngage acquired Aampe to bring individual-level agentic decisioning into its customer engagement platform. The signal is larger than another AI feature. Engagement platforms do not want to remain campaign builders or channel pipes. They want to own more of the decision layer at the moment of interaction.

Publicis agreed to acquire LiveRamp in a transaction expected to close by the end of 2026, subject to shareholder and regulatory approval. Axios later reported that Hightouch offered up to 1.2 billion dollars for selected LiveRamp identity and onboarding assets, reportedly setting a late-June deadline for a response, although no subsequent public outcome has been confirmed. The reported offer should not carry the same weight as a completed transaction, but the underlying tension is revealing. Identity and audience portability are no longer background plumbing. They are strategic infrastructure.

The common pattern is not that every vendor is becoming the same. It is that each vendor is trying to deepen its own gravity.

Suite Gravity

Suite gravity is the force exerted by a broad enterprise platform that wants more of the customer experience architecture to live inside its ecosystem. Adobe is the clearest example in the experience space. Adobe Experience Platform, Real-Time CDP, Journey Optimizer, Target, Customer Journey Analytics, AEM and the wider content supply chain support a model in which customer data, content, decisioning, experimentation, journey orchestration and analytics are coordinated inside one experience architecture.

The strongest argument for suite gravity is not convenience. It is coordination. Large enterprises rarely have a single-channel customer experience problem. Email, mobile, web, paid media, commerce, contact centres, loyalty, conversational surfaces and sales interactions all need to respond to the same customer reality, but often do so through disconnected tools and rules. A well-implemented suite reduces that fragmentation: profiles become audiences, audiences drive journeys, journeys use governed content and offers, experimentation informs personalisation, analytics closes the loop, and AI assistance can work across several operational surfaces rather than remaining trapped inside one execution tool.

This becomes more important as content volume grows. Agentic marketing does not remove the content problem. It increases the need for structured content, approved assets, brand rules, metadata, rights, localisation and performance feedback. Adobe’s recent moves broaden the argument further: brand visibility extends the experience model beyond owned channels into the AI and search environments where a customer may first encounter a company, receive a summarised recommendation, compare alternatives inside a conversational interface and reach the brand’s website only later. Discoverability is becoming part of experience architecture.

Its risk is that the suite becomes the answer to every question. The more value an organisation extracts from the suite, the more its architecture depends on the suite being coherent, correctly implemented and organisationally adopted. A weak data foundation does not become strong because a suite has been licensed. A flawed profile design is inherited by journey orchestration. Fragmented content governance remains fragmented even when AI can generate more content. Suite gravity works when the organisation accepts the suite as an architectural centre, not merely as a collection of products bought under one contract, and that is a much larger commitment than a licensing decision.

CRM Gravity

CRM gravity starts from a different place: the operational record of the customer relationship. In many organisations, Salesforce is not simply a database of contacts and opportunities. It is the operating system for sales, service, account management, pipeline, contracts, customer interactions and internal commercial workflows.

When marketing is pulled into that environment, its logic changes. Customer engagement becomes connected to sales context, service history, account ownership, opportunity stage, contract status, support issues and customer value as understood by the commercial organisation. This matters most in B2B, financial services, insurance, automotive, utilities and other relationship-led businesses, where a customer is not only a behavioural profile but may also be an account, a policy, a household, a contract, an opportunity, a branch relationship, a service case or a renewal risk. CRM gravity makes those contexts operational.

Salesforce’s proposed acquisitions of Contentful and Fin reinforce this direction. The intended model is broader than CRM plus marketing. It is a relationship operating environment in which data, content, service, workflow and agents converge around customer work. That convergence matters in an agentic architecture, because an agent supporting account nurturing, next-best action, service escalation or lifecycle coordination needs relationship context, approved content, service knowledge, workflow controls and clear limits on what it may change.

Its weakness appears when every engagement problem is forced into a CRM-shaped model. Not every behavioural signal belongs inside a CRM object. Not every interaction should wait for synchronisation with the CRM. Anonymous and semi-known users do not always fit comfortably into classic customer records, and mobile, product and commerce interactions can occur at a frequency and speed the CRM was never designed to mediate. CRM gravity can therefore be highly effective around known customers, relationship management and commercial coordination, while becoming heavy around live behavioural response. The problem is not that CRM is a legacy constraint, because in many organisations it is the richest source of operational intelligence. The question is whether it should be the centre of the customer engagement architecture, or one essential context feeding systems that operate at a different speed.

Data Gravity

For years, many MarTech architectures placed customer intelligence inside marketing applications. A CDP or CEP collected events, unified profiles, created segments and managed activation logic, while the warehouse remained downstream for reporting and historical analysis. That model is changing. As organisations invest in Databricks, Snowflake, BigQuery and modern data platforms, the warehouse or lakehouse increasingly becomes the system of truth for customer, product, transaction, consent, behavioural and operational data. At the same time, composable CDP and warehouse-native activation patterns make it possible to compute identities, traits, scores, audiences and eligibility rules close to the data, then distribute activation instructions to downstream systems.

Databricks CustomerLake makes this ambition explicit. Although the product is still in private preview, its positioning matters, because Databricks is arguing that customer profiles, identity resolution, AI models, agents and activation can all be built where enterprise data and governance already live. The positive case is straightforward: if the most complete, trusted and governed customer data already lives in the enterprise data platform, why reproduce partial intelligence inside every marketing application? In a data-gravity architecture, the data layer masters customer identity, consent, lifetime value, product affinity, propensity, eligibility and enterprise rules, and engagement systems consume that intelligence to execute across email, push, SMS, WhatsApp, web, app, advertising, sales and service channels. This becomes more attractive as AI agents enter the stack, because agents require a reliable reality layer: they need to know which customer, product, policy, transaction and consent records can be trusted, and which rules constrain an action.

Its main risk is distance from execution. The best place to compute intelligence is not automatically the best place to orchestrate a journey, and channel constraints, frequency policies, content operations, deliverability, mobile SDK behaviour, experimentation and immediate response often remain closer to the engagement runtime. Data gravity can also create operational abstraction, where data teams understand the model but not the campaign, and marketers understand the campaign but not the model. A technically elegant architecture can still be slow if business teams cannot see, challenge or safely use the intelligence produced for them. Latency is a further concern, although less absolute than it once was: modern data platforms and activation tools are faster, but not every interaction should be routed through the warehouse. The better form of data gravity is not “put everything in the warehouse”. It is to master enterprise intelligence where the data is strongest, then expose that intelligence through operational surfaces that teams can use, govern and trust.

Engagement Gravity

Engagement gravity is the pull exerted by platforms closest to the customer interaction. Braze, Bloomreach, Iterable, Klaviyo, Insider One, MoEngage and similar platforms are not always trying to become the enterprise system of truth. Their power comes from live signals, channel depth, journey state, experimentation, frequency, timing and the ability to act while customer intent is still relevant. If a mobile event fires, the engagement runtime may be the right place to decide whether to send a push notification, change an in-app experience, suppress a message, adjust frequency or move a customer into a different journey. If a commerce signal indicates intent, the runtime may be where recommendation, offer, content, timing and channel can be combined quickly enough to matter.

This is why engagement platforms are moving deeper into decisioning. If intelligence moves entirely into the data platform, they risk becoming channel pipes; if it moves entirely into the suite or CRM, they risk losing their advantage around behavioural speed and interaction context. MoEngage’s acquisition of Aampe is a particularly clear signal, because the platform is not only adding AI assistance for marketers. It is moving toward individual-level agents that make decisions within goals and guardrails, learn from responses and adapt future actions.

Its risk is local optimisation without enough enterprise context. The runtime may know that a customer has just viewed a product three times, but not that the customer has an unresolved complaint, a contractual restriction or an eligibility status mastered elsewhere. It may optimise message response while missing a broader commercial objective, learning quickly but from an incomplete view of the customer. Engagement gravity becomes dangerous when speed is mistaken for truth. Its value is highest when the runtime is trusted to make interaction-level decisions within enterprise constraints supplied by the data, CRM and governance layers, which is not a weaker role but a more precise one.

What should own the customer decision?

The central architectural question is not only where the customer profile lives. It is where the customer decision lives. Who determines the audience, action, channel, timing, offer and constraints for a specific interaction? Each gravity produces a different answer, and the cleanest way to see it is to hold a single business request against all four.

Consider a reactivation programme. A suite-centred approach constructs a cross-channel journey using governed content, offers, experimentation and coordinated measurement. A CRM-centred approach excludes customers with open service issues, distinguishes account owners, incorporates lifecycle stage and coordinates actions with sales or service teams. A data-centred approach begins with churn risk, expected value, product propensity, eligibility and profitability calculated across enterprise data. An engagement-centred approach continuously adjusts timing, channel, frequency and content from individual responses. The business request is the same. The operating model is not, and none of the four is universally superior or interchangeable with the others.

AI agents make this distinction more important, because an agent needs to know where to read, what to trust, what it may change and which system represents the current truth for the decision it is making. An agent inside a suite reasons from the suite’s profile, content and journey model. An agent inside CRM reasons from customer records, accounts, cases and commercial workflows. An agent near the data layer reasons from governed models, scores, consent, identity and analytical logic. An agent inside the engagement runtime reasons from live behaviour, channel history and observed response. Agentic marketing does not remove architectural choice. It exposes it.

How to choose a dominant gravity

Before choosing a platform, I would want clear answers to five questions.

1. Where is the most reliable customer truth today?

Not where the roadmap says it will be, but where it actually is. If the enterprise data platform holds the cleanest and most governed customer view, ignoring data gravity is artificial. If Salesforce is the operational reality of customer relationships, ignoring CRM gravity creates a different form of artificiality. If Adobe Experience Platform already supports the organisation’s profile and experience model, introducing another centre may create duplication. If the engagement platform contains the freshest actionable behaviour, treating it as a simple channel pipe may be equally misleading.

2. What decisions need to be made most often?

A real-time mobile decision is not the same as B2B account nurturing. A product recommendation is not a service escalation. A churn prevention action is not a promotional campaign. Brand visibility in AI search is not a next-best-action rule. Different decisions require different context, latency and governance, so the dominant gravity should reflect the decisions that matter most, not the category name the organisation originally set out to buy.

3. Who needs to operate the system?

A mature data activation team can support a different model from a regional marketing team that needs templates, speed and guardrails. Business autonomy is not simply the ability to click buttons. It is the ability to act safely, understand the inputs and challenge the outputs without rebuilding the architecture. The best theoretical model can fail if it assumes an operating organisation that does not exist.

4. How much governance is required?

Regulated industries need stronger controls around consent, eligibility, approvals, auditability and explainability. This does not automatically favour a suite, CRM, data platform or engagement runtime, but it changes how much decision-making can be distributed to local tools and how much must be mastered centrally. The relevant question is not which platform has a consent feature. It is where consent becomes enforceable across all decision and execution layers.

5. How important is reversibility?

Gravity creates switching costs. The deeper the organisation embeds profiles, logic, content models, workflows, identity and AI agents into one ecosystem, the harder future change becomes. That is not a reason to avoid commitment, because architectures that refuse all commitment often produce the worst complexity of all. It is a reason to be explicit about which dependencies are strategic and which should remain portable.

Where I tend to land

The five questions are deliberately neutral, but after enough of these programmes I do have a lean, and it is worth stating plainly rather than hiding behind “it depends”. In the regulated, relationship-led businesses I work with most, insurance, financial services, utilities and the more considered end of retail, I keep arriving at the same shape: the data layer masters customer truth, identity, consent and the durable scores, and the engagement runtime owns interaction-level decisions inside the constraints that layer supplies. The suite or the CRM then leads wherever it already holds the real operating model, experience coordination for the first, relationship and commercial process for the second, rather than being asked to become the customer brain for everything. What I try to avoid is the arrangement where all four are treated as equal decision-makers, because that is the configuration that quietly generates the most cost. In my experience, a dominant gravity that is imperfect but explicit is usually easier to govern and correct than four gravities that are each partly right and never reconciled.

Gravitational turbulence

Most real architectures are mixed. A company may use Salesforce as CRM, Databricks as the enterprise data platform, Braze as the engagement runtime, Adobe Analytics for digital measurement and a separate experimentation tool for web. Another may use Adobe Experience Platform as the profile layer, Journey Optimizer for orchestration, Target for personalisation, Salesforce for sales and service, and Snowflake for enterprise analytics. The existence of multiple gravities is not the problem. The problem is allowing them to compete without deciding which one leads for each kind of decision.

When Adobe, Salesforce, the data platform and the CEP are all treated as equal customer brains, the organisation does not automatically receive the best of every platform. It often receives duplicated audiences, mismatched consent rules, competing journey priorities, contradictory customer states and unclear ownership. The stack starts to negotiate with itself. One audience is calculated in the warehouse, another in the CDP and a third in the CEP. Sales and marketing apply different definitions of lifecycle stage. Consent is mastered centrally but interpreted locally. A service event should suppress a campaign, but the engagement runtime never receives it. AI assistants answer from partial context because no one has defined which system has authority for which question.

The solution is not necessarily to centralise everything. It is to make the dominant gravity explicit for each layer of the customer decision:

Which system masters customer and account identity?
Which system owns consent and eligibility?
Which system computes durable customer intelligence?
Which system coordinates journeys across channels?
Which system can make interaction-level decisions?
Which system owns content and brand governance?
Which system records the outcome?
Which agents may read or change each layer?

Answered explicitly, these questions produce an architecture in which several gravities coexist without pretending they are interchangeable.

The architecture tells the truth

A vendor roadmap shows where a platform wants to go. A demo shows what the platform wants you to see. A feature matrix shows what exists. The architecture shows what will happen after implementation.

If the warehouse is the real system of truth, customer intelligence will eventually move closer to the data layer. If Salesforce is the real operating environment for the customer relationship, marketing will continue to be pulled toward CRM context. If Adobe is the experience backbone, orchestration, content, personalisation and analytics will increasingly align with the suite. If the engagement platform holds the freshest behavioural context, real-time interaction decisions will move toward the runtime. These forces can be resisted for a while through exports, custom logic, duplicated audiences and governance meetings, but eventually the cost of resisting the dominant gravity becomes visible.

This is not a criticism of any platform, because every platform is built around a worldview: coordinated experience for Adobe, customer relationship and business process for Salesforce, data and intelligence as the control plane for the warehouse and composable players, and the interaction moment for the engagement runtimes. The work is not to decide which worldview is universally right. It is to decide which one fits the organisation, which decisions each layer should own and where the boundaries between them need to remain visible.

The next generation of MarTech decisions will not be won by the longest feature checklist. They will be won by the clearest architectural fit. You do not only choose a vendor. You choose where customer truth is mastered, where intelligence is computed, where content is governed, where decisions are made, where agents operate and which team holds the keys to the operating model. Once a platform is implemented, its gravity works every day, shaping the roadmap, the integrations, the skills the team needs and what becomes easy, difficult or expensive.

The architecture always wins. The only choice you really have is whether you decided, in advance, which gravity it would obey.

Four Gravities Shaping MarTech Decisions: Suite, CRM, Data and Engagement