The SaaS Marketing Analytics Stack

Every marketing team has the same argument eventually. The CRM says 62 opportunities came from content, the ad platform claims 41, product analytics shows a different signup count entirely, and the board deck picks whichever number is kindest. That argument is an architecture problem, not a reporting problem. This is how the data physically travels from a click to a board slide, what to buy at each stage, and the order to build it in.

What are the six layers of a marketing analytics stack?

Six layers, each with a distinct job. Most companies buy tools for layers one and six and leave the middle four to chance, which is exactly where the disagreements come from.

Transformation is the layer teams skip most and the one that causes the disagreement they complain about. When “marketing qualified account” is defined in a dbt model, there is one definition. When it is defined in three dashboards, there are three, and they drift within weeks of anyone changing a filter.

What should you buy at each ARR band?

Three bands, three quite different answers. Building the 20 million dollar stack at 2 million dollars ARR is a common and expensive mistake, usually made by a first analytics hire who wants the architecture they had at their last job.

ARR band	Stack	Rough annual tooling cost	Who runs it
Under $3M	Product analytics plus CRM reporting, strict tracking plan, spreadsheet for blended numbers	$5K to $15K	Marketing ops, part time
$3M to $20M	RudderStack or Segment, Fivetran, BigQuery or Snowflake, dbt, Metabase, Hightouch	$40K to $90K	One analytics engineer or a fractional data partner
$20M plus	Full warehouse native stack, Looker or Omni, governed semantic layer, dedicated pipelines	$120K to $400K	Data team of two to five, with an embedded marketing analyst

Under 3 million dollars ARR, the highest return investment is not a tool at all. It is a written tracking plan that says what every event is called, when it fires and what properties it carries. The marketing tracking plan template is genuinely the cheapest thing on this page and prevents the most expensive problem.

Between 3 and 20 million, the stack above is close to a default, and the debate worth having is BigQuery versus Snowflake. BigQuery is cheaper to start and easier if you are already in Google Cloud. Snowflake is easier to govern as more teams start querying. Either is fine; changing your mind in year three is not.

Why does the identity spine break, and who owns it?

Four identifiers have to chain together: anonymous ID from the first visit, user ID once someone logs in, account ID in the product, and the CRM record ID. Every question you care about, from which content produced pipeline to which campaign touched an expansion, depends on that chain holding end to end.

Three points of failure, in order of how often I see them.

Anonymous to user stitching fails when someone reads three blog posts on mobile, signs up on desktop, and your CDP treats them as two people. Partially solvable with identity resolution in the CDP, never fully solvable, and worth knowing the error rate rather than pretending it is zero.

Lead to account matching is the worst one. A person signs up with a personal Gmail address, or the company is Example Company in your CRM and Example Companyoration in the signup form, or the enterprise has fourteen domains. Untreated match rates commonly sit between 60 and 80 percent, which means a fifth of your pipeline is invisible to any content attribution you run. Fix it with a domain mapping table you maintain deliberately, plus an enrichment provider, plus a monthly exception review.

CRM to warehouse sync breaks quietly when someone adds a custom field and nobody updates the pipeline. Schema change alerts solve this in an afternoon and almost nobody sets them up.

Name an owner for the identity spine. Not a team, a person. This is the single most influential governance decision in the whole stack, because unowned joins degrade silently and you only discover it during a board prep at 11pm.

What does reverse ETL actually unlock for marketing?

It closes the loop between product behaviour and campaigns, which is the thing marketing automation platforms have promised for a decade and never delivered on their own.

Concrete plays that need it:

• Accounts whose weekly active users dropped more than 40 percent over 30 days, synced to a CS alert and a re-engagement sequence.
• Warehouse computed product qualified lead scores pushed into Salesforce so sellers see them next to the record.
• Customers using two of five modules, synced to an expansion campaign for the third.
• Suppression lists built from actual product usage rather than an email platform’s stale tags.

Each of those requires a metric defined once in dbt and delivered wherever it is needed, which is the entire argument for warehouse native marketing. The alternative is a marketing ops person exporting CSVs on Friday afternoons, which works until they take a holiday. These plays are also the mechanism behind most of the expansion levers that move NRR.

What build order produces numbers in 60 days?

This sequence assumes one competent analytics engineer or a good fractional partner, and it produces defensible numbers before the quarter ends.

The discipline that makes this work is limiting scope. Ten metrics, one dashboard. Teams that try to model everything in the first quarter ship nothing usable in the first year, and the credibility cost of that is hard to recover.

Where should attribution sit in all this?

Last, and possibly nowhere. An attribution product applies a model to data you already own. If your capture is inconsistent and your account matching sits at 70 percent, the tool will produce a confident number derived from broken joins, and it will be believed because it came from a specialist tool with a nice interface.

Build the warehouse first, then decide. Plenty of teams find that once they have clean first touch, last touch and full path views in dbt plus a self reported attribution field on the demo form, the dedicated product adds a model preference rather than information. That is a legitimate purchase, just a much smaller one than the category’s pricing implies.

Whatever you conclude, report multiple views to the board rather than one. First touch, last touch, and self reported, side by side, with the disagreement visible. Executives trust a range with an honest error bar more than a single number they suspect was chosen. The board reporting playbook covers how to present that without losing the room.

What this costs beyond the tools

The uncomfortable part. Tooling is the cheap half. An analytics engineer costs 130,000 to 180,000 dollars in the US, and without one the stack decays: pipelines break, definitions drift, and within nine months you are back to arguing about whose number is right while paying 60,000 dollars a year for the privilege.

Two more honest limits. A warehouse does not make attribution true, it makes it consistent, and consistency is worth a great deal but it is not causality. And self service analytics is largely a myth in marketing teams under about 50 people. Someone will still build the queries. Plan for that person rather than budgeting for a tool that promises to remove them.

Start with an audit, not a purchase

Before buying anything, run the marketing analytics audit checklist and write down your current lead to account match rate. That single number tells you whether your problem is tooling or plumbing, and for most teams it is plumbing.

Then pick the band that matches your ARR and build in the order above. The marketing analytics platforms roundup compares the presentation layer options, Mixpanel versus Amplitude covers the product analytics choice specifically, and the SaaS marketing dashboard template gives you a starting layout for that one dashboard. The wider SaaS metrics hub covers what the numbers should mean once you can trust them.