MarTech Stack Architecture

A stack is a system, not a tool list

Most companies describe their MarTech stack as a list of vendor logos: GA4, HubSpot, Meta Ads, Klaviyo, Looker Studio. That's inventory, not architecture. A stack only functions as a *system* when data actually flows between those tools in a coherent, intentional direction — when a purchase event triggers a CRM update, which triggers a lifecycle email, which reports back into the same analytics dimensions used for ad attribution. The architect's job isn't picking tools; it's designing how data moves between them, where the single source of truth lives for each entity (customer, order, campaign), and what happens when two tools disagree about the same fact.

The standard layers

A mature MarTech stack organizes into distinct functional layers, each with a different job:

1. Collection layer — where raw behavioral and transactional data originates: website tags (GTM), app SDKs, POS systems, forms.
2. Identity/unification layer — a CDP or warehouse identity model that resolves collection-layer events into a single customer profile (see Customer Data Platforms).
3. System of record layer — CRM for relationships/deals, an ecommerce platform for orders, a data warehouse for the canonical historical dataset.
4. Analytics/measurement layer — GA4, BigQuery, Looker Studio: where data becomes reportable and queryable.
5. Activation layer — email/SMS automation (Klaviyo, Braze), ad platforms (Meta, Google Ads), personalization tools — where unified data is *used* to act on customers.

The architectural failure mode is treating these layers as interchangeable — e.g. letting the ad platform's own pixel become the de facto system of record for conversions, because no one built a clean path from the warehouse back out to it.

stack_data_flow.txt

text

[Website/App]  [POS]  [Support]  [Ad Platforms]
      \        |         |            /
       \       |         |           /
        v       v         v          v
          COLLECTION LAYER (GTM, SDKs, webhooks)
                     |
                     v
        IDENTITY LAYER (CDP or warehouse identity model)
                     |
        +------------+------------+
        v                         v
 SYSTEM OF RECORD           ANALYTICS LAYER
 (CRM, order DB)            (BigQuery, GA4, Looker)
        |                         |
        +------------+------------+
                     v
            ACTIVATION LAYER
   (Email/SMS automation, ad platform audience sync,
    personalization, sales handoff)

Every stack has exactly one source of truth per entity — or it has none

The most common architecture bug isn't a missing tool, it's an undecided source of truth. If revenue can be pulled from Shopify, Stripe, GA4, and the CRM, and no one has declared which number is canonical, every team quietly defaults to whichever number supports their argument. Architecture work is disproportionately about writing down and enforcing these decisions, not connecting APIs.

Build vs buy

The build-vs-buy decision recurs at every layer. Buying (a CDP, a pre-built integration, a managed ETL tool like Fivetran) trades ongoing subscription cost for speed and reduced engineering burden — appropriate when the capability is commodity and well-served by mature vendors (e.g. email deliverability infrastructure). Building trades engineering time for control and lower marginal cost at scale — appropriate when the data flow is core to the business's competitive differentiation, when vendor pricing scales punitively with data volume, or when no vendor's opinionated data model fits your actual business logic.

A useful heuristic: buy the layers that are genuinely undifferentiated infrastructure (email sending, ad delivery, base analytics collection); build or heavily customize the layers where your specific customer/product model doesn't fit anyone's off-the-shelf schema (often identity resolution logic and the activation rules built on top of it).

Build vs buy by layer

Layer	Usually buy	Consider building when
Collection	GTM, vendor SDKs	Highly custom event surfaces (IoT, native hardware)
Identity/CDP	Segment, RudderStack, warehouse reverse ETL	Unusual identity rules not served by vendor's model
System of record	CRM/ecommerce platform	Rarely — this is core infra, buy unless truly novel
Analytics	GA4 + BigQuery + Looker Studio	Custom modeling on top of warehouse data (build the SQL, not the platform)
Activation	Klaviyo, Braze, native ad platform tools	Complex cross-channel orchestration logic unique to the business

Data flow design principles

A few principles separate stacks that stay maintainable from ones that rot into a tangle of point-to-point integrations:

- Hub-and-spoke over point-to-point. Route data through a central identity layer or warehouse rather than connecting every tool directly to every other tool — N tools connected point-to-point needs up to N(N-1)/2 integrations; hub-and-spoke needs N.
- One-way data contracts per pipe. Each integration should have a clearly owned direction and schema; bidirectional syncs (CRM ↔ ecommerce platform, both writing the same field) are a frequent source of data corruption from conflicting writes.
- Event schemas versioned like code. Treat your event taxonomy as an interface contract, not a free-for-all — changing a field name breaks every downstream consumer silently.
- Latency requirements set the pattern, not the vendor. Decide whether a given flow needs real-time (checkout confirmation), near-real-time (abandoned cart trigger), or batch (weekly cohort report) *before* choosing the tool, since that decision dictates streaming vs. reverse-ETL architecture.

Point-to-point integrations are technical debt from day one

Connecting Klaviyo directly to Shopify, then Shopify directly to the CRM, then the CRM directly to the ad platform feels fast to set up but creates a web of fragile, undocumented dependencies. When one tool changes its API or data model, every direct connection touching it breaks independently, and no one has a single place to look to understand the full data flow.

What's next

With the layered architecture in mind, it's worth going deep on the identity/unification layer specifically, since it's the piece most often built wrong or skipped entirely.

Next: Customer Data Platforms (CDP) →