What Should a Three Person Marketing Ops Stack Look Like?

What Does a Marketing Ops Stack Actually Need to Do?

Five jobs, not fifteen tools. Capture what happened, store it somewhere durable, join it to your pipeline, report it to people who make decisions, and act on it automatically where the action is obvious. A three person team can do all five, badly or well, with almost the same number of tools.

What separates the two is rarely the tool choice. It is a handful of configuration decisions made in week one that nobody revisits, and that quietly destroy the data a year later when someone finally asks a hard question.

This is the framework we use when a small B2B team asks what they should be running. It is organised by job, because organising by vendor is how stacks get bought twice.

What Are the Five Jobs, and Which Tool Does Each?

Capture, storage, identity, reporting, and activation. Most small teams have the first and fourth covered, nothing for the second and third, and buy tools for the fifth before they can measure whether the fifth is working.

Job	What it means	What a small team needs
Capture	Recording what visitors and leads did	One analytics property, configured deliberately, plus form capture
Storage	Keeping that record beyond the tool's retention window	An export destination, even a humble one
Identity	Joining a visitor to a lead to an account	Consistent campaign tagging and one identifier you keep everywhere
Reporting	Turning it into a number someone acts on	One weekly view, owned by a person, not a dashboard nobody opens
Activation	Doing something automatically with the data	Almost nothing, until the first four are reliable

The order matters. Activation built on unreliable capture produces automated decisions based on wrong numbers, which is worse than no automation. We have watched teams route leads by a source field that was broken for months.

Notice how few tools that list implies. One analytics property, your CRM, a place to put exports, and a spreadsheet. That is a complete stack for a team under about ten people, and it is more than most teams that own six tools actually operate.

Which Default Setting Will Cost You a Year of Data?

Data retention. If you are on Google Analytics, this is the single highest value setting in your entire stack and almost nobody changes it in week one.

Google's documentation lists the event data retention options as "2 months, 14 months, 26 months (360 only), 38 months (360 only), 50 months (360 only)," and user level data retention as either 2 months or 14 months. The longer windows are for the paid tier.

So on a standard property, the longest you can keep event level data is 14 months, and if the setting was never touched you may be keeping far less. There is also a size based restriction worth knowing: Google states that "large and XL properties are limited to 2 months."

Deletion is not recoverable. The documentation is plain that "when data reaches the end of the retention period, it is deleted automatically on a monthly basis," and that reducing the setting causes affected older data to be "deleted during the next monthly process."

The consequence for a B2B company is severe, because B2B sales cycles are long. A deal that took eleven months to close needs data from eleven months ago to be understood, and a 2 month window means that analysis is impossible. This is the whole reason storage is a separate job in the framework.

Why Does Your Report Say (other), and What Does It Hide?

Because you created too many distinct values in a dimension, and the tool gave up naming them individually. Google's documentation describes the row as one that "appears in a report, exploration, or Data API response when the number of rows in a table exceeds the table's row limit."

The threshold is more attainable than people expect. Google's guidance says "any dimension with more than 500 values should be considered a high-cardinality dimension, as it will significantly increase the cardinality of all the tables storing that dimension."

It also clarifies that this is not a hard cutoff. "The 500 values per dimension is not a limit, but a guidance," and the more values you collect, "the higher the risk of having data condensed in the (other) row." So the risk accumulates rather than switching on.

The reason this is a marketing ops problem rather than an analytics quirk is that marketing teams generate cardinality by accident. Every unique campaign name, every ad variant, every dynamically generated URL parameter adds values. A paid team running granular naming can pass 500 campaign names in a quarter without noticing.

How Should You Name Campaigns So the Data Survives?

With a small fixed vocabulary and the detail pushed into one field. Use the standard parameters, agree the allowed values, and write them down somewhere the whole team reads before launching anything.

Google's documentation names the available parameters: utm_id, utm_source, utm_medium, utm_campaign, utm_source_platform, utm_term, utm_content, utm_creative_format and utm_marketing_tactic. Its advice on the essential set is direct: "when you add parameters to a URL, you should always use utm_source, utm_medium, and utm_campaign."

Our rule is that source and medium have a closed list, decided once, that never grows without a conversation. Those two are the fields every report groups by, and they are the ones cardinality damage hurts most. Free text in a medium field is how you end up with email, Email, e-mail and newsletter as four separate channels.

Campaign can be more expressive, and variant detail belongs in content or term rather than being smuggled into the campaign name. That keeps the high cardinality in the fields you rarely group by.

None of this is glamorous and all of it compounds. Our piece on B2B SaaS attribution covers what you can actually conclude once the tagging is consistent.

Do You Need a Data Warehouse at This Size?

You need a destination, which is not the same as a warehouse. Given a retention ceiling of 14 months on a standard analytics property, something has to hold the history, and that something can start extremely simple.

A monthly export to a spreadsheet or a small database is a legitimate answer for a team of three. It is unfashionable, it costs nothing, and it means that in two years you can still answer a question about last year. A warehouse you never query is worth less than a spreadsheet you do.

What matters is that the export is scheduled and owned rather than done when someone remembers. An export that happened for four months and then stopped gives you a confusing gap, which is arguably worse than a consistent absence.

Graduate to real infrastructure when the questions genuinely need joins across systems, or when the spreadsheet stops fitting. Both of those are obvious when they arrive, and neither arrives in year one for most B2B companies.

What Should You Not Buy Yet?

Anything whose value depends on data you are not yet capturing reliably. That usually means attribution platforms, intent data, lead scoring, and personalisation. All four are real categories that work at the right stage, and all four are sold to teams at the wrong one.

The test we apply is whether you could answer the tool's core question manually today, slowly. If you cannot say which channel produced last quarter's pipeline using a spreadsheet and an afternoon, a tool that automates that answer will automate whatever is wrong with your data.

Server side tracking is a slightly different case, because it solves a real data quality problem rather than adding a layer on top. It is still work, and it is worth understanding before adopting. Our piece on server side tracking covers the trade offs.

Be honest about the budget line too. Tools bought for a capability nobody has time to operate are among the easiest things to cut, and finding them is usually worth more than the next purchase. Our piece on setting a B2B SaaS marketing budget covers where we look first.

Who Owns the Stack When Nobody Is a Marketing Engineer?

One named person, with two hours a week, and the authority to say no to a new tool. The role is not technical. It is custodial, and the main skill is refusing to let the naming conventions drift.

Without that person the stack does not collapse dramatically. It degrades. A field stops being filled, a new campaign uses a new medium value, an export breaks silently, and eighteen months later the data cannot answer anything. Every one of those is a five minute problem when it happens and unfixable later.

Write down the conventions in one page and treat it as part of the stack. Which parameters are used, what values are allowed, who to ask, what the retention setting is, and where the exports go. Most small teams have this knowledge in one person's head, which is the real single point of failure.

How Do You Know the Stack Is Working?

You can answer three questions without a project. Where did last month's pipeline come from, what is the trend over the last year, and which page did a specific closed deal touch first. If any of those takes more than an hour, the stack has a gap, and the framework tells you which one.

The first question tests identity and reporting. The second tests storage, because a 2 month window makes it unanswerable. The third tests capture, because it needs the campaign and page context to have travelled with the lead.

Run that test quarterly, with the actual questions, and fix whatever fails. It is a better health check than any dashboard, because it measures whether the stack answers questions rather than whether the tools are connected.

How Would We Build This From Scratch?

Day one, set the retention window to the longest your tier allows. It takes a minute and it is the only decision on this list you cannot make retroactively.

Week one, agree the closed list of sources and mediums, write it on one page, and make sure form submissions carry the campaign and page context into the CRM. Week two, schedule the export, however humble, and name its owner.

Then stop buying things until the three questions above are answerable. In our experience that takes a quarter, costs almost nothing, and puts a small team ahead of much larger ones with more expensive stacks.

If you want a second opinion on what your stack is actually capable of answering, we are happy to walk through it with you. You can find us at phoenix.studio.