The six layers of a modern martech stack
The word "martech" covers everything from a basic email newsletter tool to a seven-figure enterprise data infrastructure. Before evaluating anything, the marketing leader needs a clear map of the layers and the job each one does. Without that map, vendor demos collapse into feature comparisons with no structural logic.
Six layers make up the functional architecture of a modern stack:
| Layer | What it does | You need it when | Common tool categories |
|---|---|---|---|
| CRM | Stores named contacts, accounts, deal stages, and sales activity | You have a sales team managing named accounts or a pipeline of any length | Salesforce, HubSpot, Pipedrive, Microsoft Dynamics |
| CDP (customer data platform) | Ingests event streams, resolves identity across touchpoints, serves unified segments | You have digital events across web + app + email and need them joined to one profile | Segment, mParticle, Tealium, Amplitude, Adobe Real-Time CDP |
| Marketing automation + ESP | Orchestrates lifecycle sequences, executes email delivery, manages consent and suppression | You send more than a simple newsletter or need behavioural triggers | Klaviyo, Braze, Iterable, Marketo, ActiveCampaign |
| Analytics and attribution | Measures campaign performance, models channel contribution, reports on revenue impact | You spend on paid media or need to justify marketing investment to a finance audience | GA4, Mixpanel, Heap, AppsFlyer, Adjust, Triple Whale, Northbeam |
| Tag management + consent | Controls what tracking fires under which consent state; centralises pixel and SDK deployment | You operate in any jurisdiction with a privacy law (all five of leapbuzz's markets qualify) | Google Tag Manager, Tealium iQ, OneTrust, Sourcepoint, Cookiebot |
| AI and agent layer | Predictive scoring, generative content, autonomous bid or send-time optimisation | You have enough data volume that rule-based logic is the binding constraint on performance | Embedded AI in above platforms; specialist tools like Persado, Jasper, 6sense, Demandbase |
A few things stand out in that table. First, the CRM and the CDP are different tools solving different problems. A CRM is a relationship record. A CDP is a behavioural data bus. Teams that try to run a CDP use case through their CRM hit limits on event volume, identity resolution, and segment refresh speed that no amount of configuration will fix.
Second, the AI and agent layer is not a seventh system you add on top. It is a capability that the other layers increasingly embed. Bid optimisation is inside Google Ads and Meta Advantage+. Predictive churn scoring is inside Braze and Klaviyo. Generative copy tools are inside many email platforms. The "AI tool" procurement exercise is shrinking as AI becomes table-stakes inside the tools you already buy.
Third, tag management and consent management are not optional. All five of leapbuzz's target markets (Singapore, Malaysia, Australia, Canada, the US) have active privacy legislation. A stack with no consent management platform is not a lean stack; it is a non-compliant one. See the five-market section below for jurisdiction specifics.
Data model first: the discipline most teams skip
The most common martech selection failure pattern: a team shortlists three vendors, attends demos, negotiates pricing, signs a contract, then discovers six months later that the tool cannot ingest their event data in the format it is actually produced. The vendor demo showed what the tool could do with clean data. The reality was messier.
The fix is simple in principle and consistently skipped in practice: map your data model before opening a single vendor conversation. The data model has three components.
Entities. Who are the objects in your system? In B2C, it is typically person plus household plus device. In B2B, it is person plus account plus opportunity plus product. In insurance, it is policyholder plus policy plus claim. The entity model determines the CRM and CDP architecture. A tool built for B2C person-level identity resolution does not work well for B2B account hierarchy management, and vice versa.
Events. What actions matter, and where do they happen? An e-commerce site might track page view, product view, add to cart, checkout initiation, purchase, refund, and support ticket. A SaaS product tracks login, feature activation, session depth, and subscription change. Each event needs a schema: a defined set of properties that travel with every event occurrence. The event schema is what the CDP ingests, what the marketing automation platform uses to trigger sequences, and what the analytics layer reports on. If the schema is inconsistent across platforms (the web sends "userId" in one field, the app sends "user_id" in another), identity resolution fails silently.
Identifiers. What are the stable IDs that let you join data across systems? Email address, phone number, device ID, first-party cookie ID, loyalty account number. The more identifiers you have and can join reliably, the more useful your CDP becomes. The fewer you have, the less identity resolution matters, and you may not need a CDP at all.
The data model also determines your integration architecture. If you have a central data warehouse (BigQuery, Snowflake, Databricks) as the source of truth, you need tools that can read from and write to it via standard connectors. A tool with no warehouse integration forces you to rebuild data pipelines from scratch, adding engineering cost and data quality risk. Tools that support reverse ETL (writing audience segments from the warehouse back into marketing execution tools) are significantly more valuable in a modern stack than tools that require you to build that plumbing yourself.
The selection framework: jobs-to-be-done
After the data model is mapped, tool evaluation runs on a jobs-to-be-done frame. For each layer in the stack, identify the specific jobs the tool must do, then score candidates against those jobs rather than against a generic feature matrix pulled from a review site.
The jobs-to-be-done frame surfaces requirements that feature lists obscure. "Marketing automation" as a feature is present in dozens of tools. "Marketing automation that can trigger an email within 90 seconds of a cart abandonment event, with a fallback to SMS if the email is unopened at 4 hours, using a segment that excludes subscribers with more than 3 emails in the last 7 days" is a job that only some tools can do reliably. The specificity is the filter.
For each candidate tool, run five evaluation passes:
- Data ingestion test. Can it accept your event schema in your current format? Ask for a technical integration brief, not a sales promise. If they cannot produce one, the integration will be harder than sold.
- Segmentation depth test. Can it segment on calculated attributes, not just static fields? Calculated attributes (average order value in the last 90 days, predicted churn probability, days since last engagement) are what make lifecycle programmes work. A tool that can only filter on "purchased: yes/no" is a batch tool pretending to be a lifecycle tool.
- Scale test. What happens at 10x your current contact volume? Ask for reference customers at your target scale. Platforms that work well at 100,000 contacts sometimes have architectural bottlenecks at 2 million that only appear under load.
- Compliance controls test. Does it support per-region suppression lists, consent state flags, and audit logs? For CASL compliance in Canada specifically, you need a timestamp and source for every consent record. The tool needs to store and expose that, not just your team's spreadsheet.
- Exit test. How do you get your data out if you switch? What format is the data export? What is the standard migration process? A vendor that cannot give a clear answer to this question is signalling that leaving is designed to be difficult.
The exit test is the one most teams skip. It is the single most predictive question for total cost of ownership. Tools with clean, standards-based data exports are cheap to replace. Tools with proprietary data formats are not.
Consolidation vs best-of-breed: the decision matrix
The martech industry has been in a consolidation cycle since roughly 2022, when rising interest rates made large independent SaaS valuations harder to sustain and the acquisition rate accelerated. The result is that suite vendors (Salesforce, Adobe, HubSpot, Oracle) now offer broader coverage across more layers than they did three years ago, while specialist best-of-breed vendors have responded with deeper native integrations to compete.
Neither approach wins universally. The decision matrix has four variables:
| Variable | Points toward consolidation | Points toward best-of-breed |
|---|---|---|
| Integration capacity | Small team, no dedicated integration engineers, complex integrations have historically failed | Dedicated data engineering team, clear data warehouse strategy, integration backlog is manageable |
| Capability gap | Suite covers 80%+ of required jobs adequately; the 20% gaps are not business-critical | Suite covers required jobs at 60% quality; the 40% gaps are in high-value, high-volume workflows |
| Data complexity | Linear customer journey, single channel, standard event schema | Multi-channel, multi-market, complex identity graph, non-standard events |
| Switching cost appetite | Low tolerance for disruption; team is mid-migration from a legacy stack already | High tolerance; previous best-of-breed stack was well-maintained; migration is planned and resourced |
The failure mode for consolidation is paying suite pricing for a tool you use at 40% of its capability. The failure mode for best-of-breed is having five disconnected tools that each believe they are the source of truth for customer identity, none of which agree on contact counts or event attribution.
A hybrid approach works when the core data infrastructure (warehouse, CDP, identity resolution) is built on best-of-breed specialist tools, while execution layers (email, SMS, ad platform integrations) sit on a consolidated platform that reads from the shared data source. This separates the data architecture decision (where specialist depth matters most) from the execution decision (where convenience and breadth matter more).
For teams in Singapore and the broader APAC region, vendor availability is a real constraint. Best-of-breed tools headquartered in the US may not have Singapore data residency options, which creates PDPA exposure for financial services and healthcare clients. Check data residency commitments in the contract, not in the sales presentation. The sales team and the contract may say different things.
What AI genuinely changes about the stack
Three changes are real. Several others are vendor marketing dressed as architectural shifts.
New tool categories appear. AI-native tools have emerged in the last 24 months that did not exist in the previous vendor landscape. Predictive lead scoring has moved from expensive add-on to embedded feature in mid-market CRMs. Generative creative tools that connect directly to Meta's ad system or Google's asset pipeline are now a distinct tool category, not a feature of design software. AI agents that can autonomously execute bid adjustments, pause underperforming ad sets, or adjust send timing based on real-time engagement signals are commercially available. These are not incremental upgrades. They are new jobs that require evaluation from scratch, without carrying forward assumptions from equivalent legacy tools.
Data residency becomes a selection criterion. When a tool uses your customer data to train or personalise its AI outputs, the question of where that data goes matters. A US-based vendor AI that routes Singapore financial services customer data through shared model infrastructure may violate MAS Technology Risk Management guidelines, which require financial institutions to maintain control over customer data processed by third parties. This is not theoretical. Several enterprise martech contracts signed in 2024 required renegotiation in 2025 when legal teams reviewed the AI data processing terms. Check the data processing agreement (DPA), not the marketing deck.
API surface quality is now a primary criterion. In the pre-AI era, integration quality mattered but was often secondary to features. In the AI era, the value of a tool depends largely on whether it can receive data from and send data to AI systems in real time. A CRM that batch-exports once per day cannot power real-time AI personalisation. A marketing automation platform with no webhook support cannot receive AI-generated content at send time. The API is the product now. Evaluate the API documentation and the integration catalogue with the same rigour you apply to the feature matrix.
The hype layer in AI martech is substantial. "AI-powered" appears on vendor landing pages for tools that use a decision tree plus a large language model wrapper and call the combination artificial intelligence. The discriminating questions are: what specifically does the AI predict or generate? What training data was used? What is the model's accuracy on your customer population, not the vendor's benchmark population? If the vendor cannot answer those three questions in specifics, the AI claim is marketing, not architecture.
For a deeper look at how AI tools integrate into the lifecycle execution layer specifically, see our email and lifecycle marketing guide. For the analytics and attribution layer, the SaaS user behaviour analytics stack post covers the product analytics tooling decision in depth. And our work on neobank attribution analytics walks through the full measurement stack for a regulated financial product.
Total cost of ownership: the real calculation
The licence fee is the number that appears in the budget. It is usually the smallest component of total cost of ownership (TCO) for any tool that sits in a complex stack. The full calculation has five lines.
- Licence or subscription cost. The visible number. Easy to compare across vendors, which is why vendors compete heavily on it. Often discounted 20-40% off list in negotiation, especially for multi-year terms.
- Integration build cost. Engineering time to connect the tool to your data warehouse, CRM, and other stack layers. For a well-documented tool with standard connectors, this might be two to four weeks of engineering time. For a tool with proprietary connectors and sparse API documentation, it can be three to six months. This cost is almost never in the vendor's onboarding estimate.
- Data quality maintenance. The ongoing work of keeping identity records clean, event schemas consistent, and suppression lists current. This is a people cost, not a tool cost. Automations fail silently when data quality degrades. Someone has to own the data quality monitoring. If no one owns it, the tool's value degrades over time regardless of the licence renewed each year.
- Training and adoption. A complex platform takes 90 to 180 days before a marketing team uses it at 50% of capability. This cost is the lost opportunity from the old tool being turned off before the new tool is actually running. It is also the risk of the team defaulting to the features they understand rather than the features the tool was bought to deliver.
- Switching cost. The cost if you decide to leave in 24 to 36 months. Data migration, automation rebuild, team retraining. Tools with proprietary data formats, non-exportable automation logic, or closed API surfaces carry switching costs that can equal or exceed the total licence fees paid. This is how vendors sustain pricing power beyond the initial contract. Gartner's 2023 Marketing Technology Survey found that 25% of enterprise marketing teams planned to replace a major martech tool in the next 12 months; the average replacement project took 14 months and cost significantly more than planned.
The switching cost calculation should determine your contract length. If switching cost is high (proprietary data, complex automations, no clean export), negotiate a shorter initial term (12 months) to preserve optionality, even at a higher per-month rate. If switching cost is low (open API, standard data formats, clean export documented in the contract), a multi-year commitment for a lower rate is the right trade.
Five-market read: compliance configuration, not tool replacement
leapbuzz operates across Singapore, Malaysia, Australia, Canada, and the United States. The compliance picture varies by jurisdiction, but the tool stack itself does not need to differ market by market. What changes is configuration.
| Market | Key law | Consent standard for email | Data residency note |
|---|---|---|---|
| Singapore | Personal Data Protection Act (PDPA) 2012, amended 2021 | Express consent or legitimate interest; opt-out must be honoured within 10 business days | No strict residency requirement for most sectors; MAS-regulated entities must comply with MAS TRM guidelines for outsourced processing |
| Malaysia | Personal Data Protection Act 2010 | Consent required; data must not be transferred outside Malaysia without equivalent protection | Data localisation provisions apply; verify cloud provider agreement covers Malaysia PDPA transfer requirements |
| Australia | Privacy Act 1988, Spam Act 2003 | Express or inferred consent; unsubscribe must function within 5 business days | No general data localisation law; Australian Privacy Principle 8 covers overseas disclosure requirements |
| Canada | CASL (Canada's Anti-Spam Legislation), PIPEDA | Express consent required in most cases; 2-year implied consent window for existing commercial relationships | PIPEDA requires accountability for data transferred to third parties, including processors outside Canada |
| United States | CAN-SPAM Act; state-level: CCPA, CPRA (California), others emerging | Opt-out model federally; California's CCPA adds opt-in for sensitive categories | No federal data localisation; California Consumer Privacy Act creates deletion and access rights that require suppression list controls |
The practical implication: configure your consent management platform per jurisdiction, not per tool. A single OneTrust or Sourcepoint instance can carry separate consent policies for each market. The downstream martech tools (email, CRM, CDP) receive consent flags from the CMP layer and act on them. You do not need five separate email platforms for five markets. You need one email platform that respects the suppression flags your CMP sends.
The CASL requirement is the most operationally demanding. Express consent with timestamp and source recorded in a queryable system is not negotiable. If your CRM or marketing automation platform cannot store and report on consent provenance at the individual contact level, you need to add a consent record layer before you can legally email into Canada with express-consent requirements.
For insurance-sector martech specifically, the intersection of sector regulation and data privacy law adds another dimension. Singapore's MAS Notices on business conduct for life insurers and MAS TRM guidelines both carry implications for how customer data is processed in automated marketing systems. The insurance martech and CRM guide covers this configuration in detail for that vertical.
leapbuzz advises on martech selection as part of analytics and insights engagements and AI marketing strategy engagements. The vendor-neutral frame is not a positioning claim; it is a methodological requirement. We are paid to get the answer right for the client's data model, not to have a preferred vendor referral arrangement.