Creating a unified list-building experience with a semantic layer

Key takeaways

• Demandbase built a unified list-building experience across third-party canonical universe data and first-party tenant data.
• The work was enabled by bringing the data into a shared analytical foundation, but the article focuses on what was built after that foundation was in place.
• A new semantic layer became the central architecture for data modeling, SQL generation, metric definitions, and query consistency.
• Customers can now analyze, filter, and build lists from a single experience instead of navigating fragmented data views.
• The semantic layer created a scalable base for future roadmap items across analytics, segmentation, audience building, and customer-facing insights.

The challenge: A unified experience needs unified semantics

Demandbase customers work with multiple types of data when building lists. Some data comes from the broader third-party canonical universe, while other data is specific to a customer’s own tenant.

Previously, these datasets were not experienced as one cohesive model. Even when the data became available in the same analytical environment, the product still needed a consistent way to define entities, relationships, fields, metrics, filters, and SQL behavior.

Without that layer, each new product surface risked creating its own interpretation of the data. A field could mean one thing in list building and something slightly different in analytics. Filters could be implemented differently across screens. SQL generation could become duplicated across services. New roadmap items would require repeated modeling work.

To deliver a truly unified list-building experience, we needed more than colocated data. We needed a shared semantic foundation.

What we built

After the third-party and first-party data were available in the OLAP layer, we built a unified list-building experience on top of a new semantic layer.

The semantic layer became the contract between the product experience and the underlying data model. Instead of having product workflows directly encode database-specific logic, they could rely on a consistent semantic representation of the data.

This layer handled:

• Data models
• Entity relationships
• Field definitions
• Filter behavior
• Metric definitions
• SQL generation
• Query templates
• Tenant-aware access patterns
• Reusable modeling logic for future use cases

This allowed the product to expose a single customer-facing experience while keeping the backend flexible and extensible

Why a semantic layer was needed

A unified UI alone does not create a unified experience.

Customers expect filters, counts, analytics, and list results to behave consistently across the product. If a customer applies an industry filter, views an account count, analyzes a segment, or exports a list, the meaning of those operations must remain stable.

The semantic layer helped ensure that consistency.

Instead of defining logic separately in each product area, the team created one reusable architecture for interpreting business concepts and converting them into SQL. This meant product teams could move faster while reducing the risk of inconsistent behavior.

For example, the semantic layer could define how a concept such as “account,” “industry,” “employee range,” “engagement,” or “tenant account” maps to the underlying OLAP tables. It could also define how filters combine, how joins are applied, and how analytics queries are generated.

This gave the list-building experience a stronger foundation than a custom query implementation would have provided.

The customer experience

The result was a single list-building experience where customers can explore and analyze data across both third-party and first-party sources.

Customers can now:

• Start from the broader canonical universe
• Overlay their own tenant-specific data
• Apply filters across both data types
• View analytics and counts in one place
• Build target account or contact lists from a unified workflow
• Analyze results without switching between disconnected views

From a customer’s perspective, the complexity of the underlying data architecture is hidden. They do not need to know which fields came from canonical universe data and which came from tenant-specific data. They simply get a cohesive experience for discovering, analyzing, and acting on the right audiences.

The architecture: Product experience over semantic modeling

The architecture was designed around a clear separation of concerns.

At the bottom, the OLAP database stores the analytical data needed for list building and analytics. Above that, the semantic layer defines how the data should be modeled, joined, filtered, and queried. The product experience then consumes the semantic layer rather than building SQL logic directly.

Conceptually, the architecture looks like this:

Customer Experience
↓
Unified List Builder
↓
Semantic Layer
↓
SQL Generation and Query Planning
↓
OLAP Data Models
↓
Third-Party Canonical Data + First-Party Tenant Data

This structure gave us a reusable foundation. The list builder was the first major customer-facing experience built on top of it, but the same architecture could support future roadmap items that need consistent data modeling and analytics.

Benefits of the semantic layer

The semantic layer became one of the most important parts of the system because it solved both immediate and long-term problems.

1. Consistent definitions

Fields, filters, metrics, and relationships are defined centrally. This avoids different product areas interpreting the same data differently.

2. Reusable SQL generation

Instead of manually writing query logic for each use case, product workflows can rely on the semantic layer to generate the right SQL based on the requested fields, filters, and analytics.

3. Faster roadmap execution

New product capabilities can build on existing semantic definitions rather than starting from scratch. This reduces repeated engineering work and makes future features easier to deliver.

4. Better customer trust

When counts, filters, and analytics behave consistently, customers gain more confidence in the results they see.

5. Cleaner product architecture

The UI and API layers do not need to understand every database detail. They interact with business-level concepts, while the semantic layer handles translation to the underlying data model.

Performance and cost benefits of the OLAP foundation

The unified experience was not only a product improvement. It was also a performance and cost improvement.

List building is an analytical workload. Customers are not simply looking up one record at a time. They are filtering across large datasets, applying multiple conditions, calculating counts, joining third-party and first-party data, and expecting the page to load quickly.

That pattern is a natural fit for an OLAP analytical database.

By building the unified experience on top of CelerData, powered by StarRocks, we were able to take advantage of capabilities that are designed for high-scale analytical access:

• Columnar storage
• Fast scans over large datasets
• SQL-based joins
• Aggregations across millions of records
• Query optimization for analytical workloads
• Better separation between modeling, querying, and serving

This helped improve page-load performance for list-building workflows. Customers could interact with large datasets with lower latency, making the experience feel faster and more responsive.

The OLAP foundation also reduced system complexity and cost. Instead of maintaining separate query paths and stitching results across multiple systems, the platform could rely on a single analytical serving layer. That reduced duplication, simplified engineering effort, and created a more cost-efficient architecture for large-scale data exploration.

In the earlier migration work, Demandbase consolidated Elasticsearch and CelerData serving paths to support faster joins, reduce costs, and maintain low-latency search behavior. That migration created the foundation this unified list-building experience could build on. The details of that migration are covered separately in Elasticsearch to CelerData Migration for B2B Data, which explains how Demandbase moved firmographic workloads from Elasticsearch to CelerData, enabled joins across large datasets, and optimized latency and infrastructure usage.

Building for future roadmap use cases

Although the unified list builder was the immediate outcome, the semantic layer was designed as a base architecture for future roadmap initiatives.

Any future experience that needs analytical querying, audience segmentation, account discovery, reporting, or customer-facing insights can reuse the same semantic foundation.

This creates a path for capabilities such as:

• Advanced audience building
• Segment analytics
• Account discovery
• Unified reporting
• Cross-dataset filtering
• AI-assisted query experiences
• Customer-specific data exploration
• Reusable analytics components across the product

The important architectural decision was to avoid solving list building as a one-off feature. Instead, we created a modeling and query layer that can support many future product experiences.

Lessons learned

The biggest lesson was that unified data does not automatically create a unified product experience.

Even after data is available in the same analytical system, teams still need a consistent way to model that data and expose it to customers. Without a semantic layer, every new workflow risks becoming its own custom interpretation of the data.

A semantic layer creates leverage. It lets product teams move faster, gives engineering a cleaner query architecture, and helps customers see consistent results across the platform.

Another lesson was that architecture should be shaped by future product direction, not only immediate feature needs. By investing in reusable modeling and SQL generation, the team created a foundation that can support much more than the initial list-building experience.

The unified list-building experience was not just a UI improvement. It was the result of a deeper architectural shift.

Once third-party canonical universe data and first-party tenant data were available in a shared analytical foundation, Demandbase introduced a semantic layer to model the data, generate SQL, and provide consistent definitions across the product.

That semantic layer enabled customers to build, filter, analyze, and understand lists from a single view. More importantly, it became the base architecture for future roadmap work across analytics, segmentation, audience discovery, and unified customer insights.

By investing in semantics, not just storage, Demandbase created a scalable foundation for the next generation of data-driven product experiences.