How We Built a Marketing Data Product (and What We Learned)

With nearly two decades in Marketing Operations, I’ve spent most of my career helping teams scale and automate go-to-market processes. But building a data product? That was new territory for me.

At the start of the quarter, each department at Alation was tasked with building its own data product. I was the lucky one tapped to lead the effort for marketing. I knew this would stretch me—and I hoped it would scale us.

At Alation, we believe the path to successful enterprise AI begins with data products. A data product transforms raw, distributed data into a curated, trusted, and reusable resource, giving teams a single place to find the answers they need. Done right, it doesn’t just make analysis faster—it makes AI smarter, because it’s powered by context-rich, well-governed metadata. Our Data Products Builder was designed to help organizations operationalize this approach, so teams like mine can go from scattered data to governed insights without writing endless queries.

What follows is a behind-the-scenes look at what we built, how we built it, and what we’re still learning. If you’re trying to build your first data product—or even just figuring out what a data product is—I hope this helps.

Step 1: Start with the questions

I didn’t begin with a roadmap. I began with Slack. Specifically, I looked at the recurring questions I’d get from the team:

• “Are my MQLs getting worked?”

• “How many meetings did we get from our Snowflake campaign?”

• “What’s causing the spike in web traffic?”

• “Is that traffic translating into pipeline?”

These are simple questions, but surprisingly tough to answer. The data lived across Marketo, Salesforce, Google Ads, LinkedIn, and Outreach, and no one system could provide the full story.

So I started documenting. Every time someone asked me something, I wrote it down. Answering these questions was enormously manual and time-consuming. If I could put in the work to build a reusable product, I knew it would pay off in the long term. I also kept in mind who this was for: marketing managers. While we have workarounds, these don’t scale, and they fail to deliver the full picture. 

As I collected questions, clear themes emerged: lead progression, campaign attribution, and optimization. These questions became the foundation of our data product.

Step 2: Identify the sources

Once we had the questions, we mapped them to the data sources.

For the MVP, we focused on Salesforce. But to answer our full set of questions, we needed to pull from several different tools, including Marketo, Google Analytics, LinkedIn, and Outreach.

This reinforced a core truth I’ve come to appreciate at Alation: trusted data isn’t just about data—it’s about connecting context across silos.

Step 3: Build the schema (with help from AI)

This was where things got real. I collaborated with product management to feed our core questions into an LLM, which recommended a set of schema tables:

• dim_person

• dim_account

• dim_campaign

• dim_channel

• dim_person_activity

From there, we had to define the fields, the logic, and the relationships. For example, we discovered duplicate records for the same person across systems. We created a “master” flag to determine which record took priority based on the most recent engagement.

This stage took the most time—and it pushed me into a new role. Beyond reconciling messy data, I had to step into the mindset of a data product manager, weighing design decisions that would shape how marketing would use the product for years to come. For example:

• Should filters be enforced at the schema level for consistency, or left in the Numbers Station interface for flexibility?

• Would building business logic directly into the schema make reporting simpler, or risk locking us into rules that might not scale?

Every choice carried downstream implications for usability, accuracy, and trust. Striking the right balance between technical precision and marketing practicality wasn’t glamorous, but it was essential.

Critically, I wasn’t making those choices alone. I leaned heavily on collaboration. Working with data engineering and product management as true partners was critical—they helped me think through feasibility, reusability, and long-term design tradeoffs. The overlap in roles wasn’t always clear, but that’s what made it work: we figured it out together.

Step 4: Test the data product with natural language

Once we had a working version of the schema, we connected it to Numbers Station—an AI-powered interface that lets users query data using natural language, and a company that Alation recently acquired.

We tested it live. First, we asked:

“What is the highest performing campaign in Q3?”

It ran the query across our data product and returned: PS 2020.06.24 Data Governance Methodology with 24,046 responses. Engagement was used as the metric because there was no revenue or conversion data at the campaign level. This was a win—it meant the connection between our data product and AI interface was working as intended.

Next, we asked:

“What campaign drove the highest number of MQLs this fiscal year?”

The AI returned Excluded from MQL Tagging, Scoring, and Lifecycle with 171,840 MQLs. While technically correct, it was a placeholder entry, not a true marketing campaign. The real issue? The AI didn’t understand our definition of “campaign performance.”

That was my aha moment: marketers think differently from data professionals. All those “little” decisions about definitions and context matter enormously. This test was a reminder that building the data product wasn’t just about clean tables; it was about aligning definitions to how marketing actually measures success.

Step 5: Define the knowledge layer

We realized we had to teach the AI what we meant.

It wasn’t enough to have clean data. We needed clear definitions. What’s an MQL? What’s a campaign? What counts as “performance”? What’s our fiscal year?

At first, I focused on definitions of entities. But as I tested results, I realized I also needed to define metrics—things like:

• How is velocity measured?

• How is click-through rate calculated?

That led me to create a marketing glossary, defining terms like:

• Lead

• Contact

• Campaign

• Lead score

• Attribution (marketing and sales)

• SQL, SAL 

• CPC, CPL

With support from Alation’s Professional Services team, we’re now integrating this glossary into our metadata layer (internally called AAA)—so future questions will return accurate, trusted answers.

This was a key learning:

AI only works when it understands your business—and that starts with well-defined metadata.

Step 6: Embrace the role of a product manager

Somewhere along the way, people started calling me the “data product manager.” At first, I laughed it off. But then I realized… that’s exactly what I’d become.

I was working alongside engineers (Bindu, Mahil), consultants (Chris and Naveen), and product managers to translate business needs into data logic. And it wasn’t easy. Marketing data is notoriously messy. The tools don’t always speak the same language—and neither do the people.

But that’s what made this project so valuable. I wasn’t just building a product. I was building a shared understanding.

What’s next

In just four weeks (mostly nights and weekends!), we built a functioning data product. It’s not final. We still need to complete the remaining tables and build out more definitions. But we’re getting there.

One of the hardest questions we wrestled with was: when is it ready to share? Should we wait until it was 100% accurate (which could take months), or release earlier, knowing it would need refinement?

We decided to ship once we could confidently answer the initial set of most common questions. Today, we’re about 70% there. It’s not perfect, but it’s already better than the manual workarounds we used before. That was an important lesson: a data product doesn’t need to be flawless to be valuable—it just needs to be a step change better than what came before.

In Part Two, I’ll share how we’re expanding the glossary, onboarding users, and preparing to publish this data product to the Alation Data Products Marketplace—so anyone on the team can ask smarter questions and get faster answers.

Final thoughts

Building a data product isn’t just a technical exercise. It’s about aligning people, systems, and semantics.

If you’re starting this journey, start with your questions. Be prepared to get messy with your data. And know that tools like Alation’s Data Products Builder Agent, glossary, and catalog can help you not just manage the chaos—but transform it into clarity.

You’ve got this!