MarTech stack architecture: foundations & core concepts

If marketing is signing contracts faster than anyone can connect the tools, you do not have a stack. You have a pile. Scott Brinker's Marketing TechnologyMarketing TechnologyThe connected set of software tools a marketing team uses to plan, run, measure and automate campaigns across channels.View full definition → Landscape graphic passed 14,000 products in 2024, and Gartner's 2023 marketing technology survey found marketers using roughly a third of the capability they already pay for, down from 42 percent the year before. The distance between what you own and what you actually run is where budget disappears quietly.

This lesson does one job: it defines the object. What the layers are, which system holds the authoritative version of a fact and which holds a disposable copy, and how a customer record moves between them. The rest of the module (the selection method, the case study, the consolidation politics) assumes this vocabulary.

What a MarTech stack actually is

A MarTech stack is the connected set of software a marketing organisation uses to attract, engage, convert and retain customers. The word "stack" is doing work. It implies layers, and the layers have a direction: data is captured at the bottom, decided on in the middle, expressed to the customer at the top. Built deliberately, data moves down and back up cleanly and decisions happen in minutes. Assembled reactively, data sits in pockets, teams argue about whose number is right, and nobody can say what it cost to acquire a customer last quarter without a week of manual reconciliation.

One thing the org chart hides: the seams between layers are where ownership fights happen. Nobody argues about who owns the email tool. Everybody argues about who owns the field that decides whether a contact counts as a customer.

Key sub-concept 1: the three architectural layers

Layer one is the data foundation: the warehouse (Snowflake, BigQuery), analytics collection, the sales-side record system the CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition → foundations lesson describes, and the persistent unified profile its own foundations lesson covers. Nothing built above this layer is more trustworthy than what sits in it.

Layer two is intelligence and activation: marketing automationmarketing automationUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → and messaging platforms (Klaviyo in consumer commerce, Adobe's Marketo Engage in B2B), paid mediapaid mediaVisitors arriving via paid ads or sponsored placements, where you pay a platform to display your message rather than earning visits organically.View full definition → management, audience building, experimentation. This layer decides who gets what, and when.

Layer three is experience: the CMS that controls what appears on the site, the personalisation engine, chat, social publishing. Customers only ever touch layer three. Its quality is set entirely by the two layers underneath.

Counting matters here. A mid-market consumer brand runs a dozen to twenty tools. Large enterprises commonly count theirs in the low hundreds once regional teams and brand-level purchases are included. The layer model is what makes that number legible, because it turns "we have 140 tools" into "we have four products doing the same job in layer two and nobody owning identity in layer one".

Key sub-concept 2: integration architecture models

How tools talk to each other matters as much as which tools you buy.

Point-to-point means Tool A sends data straight to Tool B. Fast to set up, fragile at scale. Twenty tools connected to each other is up to 190 links, each with its own credentials, field mapping and silent failure mode. They are rarely documented, and the person who built them eventually leaves.

Hub-and-spoke puts one platform in the middle, usually a unified profile store or an integration platform such as MuleSoft or Workato. Twenty tools becomes twenty connections. The price you pay: the hub's data model becomes your data model, and an outage there is an outage everywhere.

Event-driven publishes each customer action once as an event, and tools subscribe to what they care about. It scales best and lets you add a tool without rebuilding pipelines. It also demands a stable event schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →, which most marketing teams do not have on day one. Rename "Add to Cart" to "add_to_cart" without telling anyone and every downstream subscriber stops matching, with no error message.

Two failure modes worth naming now. Bidirectional sync loops: two systems write the same field, each reads the other's update as new, and a fresh unsubscribe gets overwritten by a stale record. Decide per field which system wins, in writing. And rate limits: most SaaS APIs meter calls in a rolling window, so a bulk backfill can starve your live triggers for hours.

Key sub-concept 3: systems of record versus systems of engagement

This distinction is the one most stacks get wrong.

A system of record holds the authoritative version of a fact and keeps its history: orders placed, contract terms, consent given and withdrawn, the identity graph. It changes slowly, it is audited, and you would rebuild the business around it if everything else burned down.

A system of engagement holds fast-moving, largely disposable state: campaign membership, send frequency caps, session behaviour, who is currently in a nurture flow. Write volume is high, the data ages out in weeks, and switching vendors should not be an existential event.

The test: if you replaced this tool next quarter, what would you lose forever? Anything on that list belongs in the record layer, with a copy pushed into the engagement tool rather than the reverse. Consent is the sharp case. Under GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → you must be able to demonstrate consent, including when and how it was given. If the only evidence lives in the messaging platform, a vendor migration turns your legal position into a data export problem.

Data flowData flowAn automated sequence of steps that moves data from source to destination: ingestion, transformation, validation, and loading, so it arrives clean and ready to use.View full definition → between the two runs on two clocks. Triggered messages need seconds: an abandoned checkout email from Klaviyo fires off a live event stream from the store. Reporting needs completeness, not speed, so the same events land in the warehouse in batches and get reconciled against orders and refunds. Mature stacks then push warehouse-computed audiences back into activation tools, the pattern usually called reverse ETLreverse ETLThe practice of copying data from your central data warehouse back into everyday business tools like CRM, ad platforms and support desks so teams can act on it.View full definition →. The predictable failure is that the two paths disagree, the real-time count says 41,000 and the warehouse says 38,600, and nobody can say which is right. Fix it by declaring jurisdiction: the stream arbitrates triggering, the warehouse arbitrates reporting.

Key sub-concept 4: data governance in the stack

Governance means who owns each field, who may read it, how it was collected, how long it is kept, and which system arbitrates when copies disagree. Treat it as an operating cost, not a legal checkbox.

Two concrete consequences. A GDPR erasure request has to be honoured within one month, and it has to reach every copy, so each unmanaged replica you created is another place someone must remember to delete. And per-profile pricing turns identity hygiene into a line item: Klaviyo bills on active profiles and Adobe licences Real-Time CDP on profile volume (both are vendors in this category, so read their guidance accordingly). A duplicate identity is billed twice, targeted twice, and reported twice.

Real world cases

Case one: Adobe's own build order. Adobe bought Marketo in 2018 for 4.75 billion dollars and Magento the same year, then spent the following years putting Experience Platform underneath them so a profile could be shared across the pieces. The instructive part is the sequence. Buying activation tools, even from one vendor, does not make them share a customer. The shared data layer has to be built or bought separately, and Adobe (which sells that layer) has spent years and billions doing exactly that inside its own product line. If it takes a software company that long, an assumption that two acquired tools will "just integrate" in your stack is optimistic.

Case two: the commerce pattern around Klaviyo. The store platform is the system of record for orders; Klaviyo consumes events and holds engagement state. Where it breaks is the join key. A customer buys once as a guest with a work address, then creates an account with a personal address. You now hold two profiles, each with half the purchase history. One gets a welcome flow a week after the customer spent 300 dollars, the other never qualifies for the VIP segment because its spend is split. Both are billed. No tool fixes this; an identity rule in layer one does.

Case three: a counter-example on letting a measurement tool become a record. Google stopped processing data in Universal Analytics on 1 July 2023 and later deleted that historical data, and teams whose only copy of their web behaviour history lived in that product lost the ability to compare year on year through the migration. Anyone who had been landing raw events in a warehouse kept their history and changed only their reporting tool.

CMO action items

• Audit the stack in three layers this quarter. List every active tool, assign it to a layer, and draw how data actually moves, not how the vendor diagram says it should. Most teams find three to five redundancies in layer two and a gap in layer one.
• Label every tool as record or engagement, and for each record system name the fields it owns exclusively. Anything claimed by two systems needs a written precedence rule before it needs a new integration.
• Demand one source for four numbers: acquisition cost, lifetime value, marketing-sourced pipeline and channel attribution. If your team cannot produce all four from one system within 24 hours, that is architecture, not strategy.
• Gate new purchases behind a written integration plan: which layer, what it reads, what it writes, what it replaces, and what breaks if it is switched off in year three.

Common mistakes that kill results

Mistake one: buying the top layer before the bottom one is solid. A personalisation engine is only as smart as the data feeding it. Adobe Target serving content off fragmented, duplicated records does not produce better experiences, it produces confidently wrong ones, and at higher cost than the generic page it replaced.

Mistake two: letting each channel team own its own tools. Paid media on one data model, email on another, web on a third, and cross-channel measurement becomes impossible. You default to last-click, because it is the only model that does not need data you never collected. That systematically undervalues brand and upper-funnel work, so those budgets get cut, which is the second-order damage.

Mistake three: treating architecture as a project rather than a standing practice. Thousands of products enter the market every year and enterprise contracts commonly auto-renew unless notice is given weeks in advance. Teams that keep control review the stack formally twice a year, hold a renewal calendar, and score new tools against the existing architecture rather than against a demo.

Key takeaways

• A stack is layers with a direction: data foundation, intelligence and activation, experience. What the customer touches is only as good as what sits underneath.
• Systems of record hold authoritative history; systems of engagement hold fast, disposable state. Ask what you would lose forever if a tool were replaced next quarter, and move anything on that list down a layer.
• Integration model matters as much as tool choice. Point-to-point breaks at scale (20 tools, up to 190 links), hub-and-spoke centralises the risk, event-driven scales best but needs schema discipline.
• Run two clocks on purpose: a live event stream for triggering, batch reconciliation in the warehouse for reporting, and a written rule for which one arbitrates.
• Governance is money, not paperwork: duplicate identities are billed twice under per-profile pricing, and every uncontrolled copy of a profile is another place an erasure request must reach within a month.