Count Metrics: A Semantic Layer to Power Business Improvement

Here at Count, we firmly believe that BI should really stand for Business Improvement, and that traditional BI tools poorly serve that broader ambition.

To be BI or not be BI. That has been the question on our mind as we have helped customers both supplement their BI tooling to unlock the power of their data teams, and move fully to Count to bring those teams closer to the rest of the business.

But there are elements of that legacy BI approach that can further accelerate the exploratory and collaborative organizational data-culture we are helping our customers move to. One of which is the “semantic layer”.

I mean, who wouldn’t want consistency, reusability, and governance around core metric definitions?

However, when we looked across the rest of the market, we didn’t see an integration opportunity that wouldn’t tether us back to old-BI, or one that could take advantage of Count’s unique advantages such as the use of DuckDB to drive data warehouse compute costs down.

So we’ve been building our own take on a semantic layer. One that lets us consider not just metrics, but the relationships between them, and make the canvas a true jumping off point for exploration.

It’s called Count Metrics. It’s available today. On all paid tiers. Right now.

• For a more leisurely introduction, here is longer tutorial video walking you though end-to-end.
• For a more doc-y introduction, check out our product documentation.
• For a more Ollie introduction, join him for a webinar looking at how Count Metrics and other semantic layers drive real business value.

Count Metrics 101

Like all semantic layers, Count Metrics is a collection of defined metrics, views, and datasets, presented together as a catalog.

Ours is defined in flat YAML files, allowing us to hold it version-controlled in Git, with the usual affordances of rolling back and atomic, documented commits.

Here you can control caching, formatting, and aggregations, and see the impact of changes straight away in the canvas.

Catalogs present themselves as just another data source in the canvas. Similarly, you can have many catalogs, and use them to segregate data access by project, so that users are restricted to the data assigned to them. Maybe marketing don’t need access to Big Query after all…

No-code. The Count Metrics way

Count Metrics comes into its own with Count’s no-code cells. You can now construct tables and cells built from your catalog, with easy access to any predefined aggregations, and all the while trusting that metrics will be presented in the correct format (no more “is that 0.1% or 10%?”).

Oh, but a cell built from the semantic layer is still just a cell. So you can continue to connect it to Python and SQL cells down-stream.

'We see Count's semantic layer as a fundamental investment of our time and effort as a data team. It's helping us to multiply the value of our models by diminishing SQL-literacy as a bottleneck to data-driven decisions. Non-technical stakeholders now have a simple interface to retrieve answers and iterate rudimentary analysis in confidence.

‍—Aadam Sarkar, Senior Analytics Engineer @ Intruder.io

Dive in and Explore from a cell

The Canvas has always been a powerful way of bringing operational clarity to organizations. Laying out metrics alongside onboarding funnels, customer journeys, or just in metric trees has enabled teams to see data in context and make faster decisions.

With the introduction of Count Metrics, we can go further here.

‍

Every visualization or table built upon catalogs can be “Explored” with a single click. Bringing you into our familiar no-code Explore environment where you edit the visualization without impacting the original canvas, and then either walk away, or save it into a new canvas, ready to build upon collaborate, and present back.

Move fast and break (fewer) things

Catalogs are best built over time and through use—iteration driven by real user. That’s how we’ve been building our own internal catalogs at Count: moving complex SQL into Count Metrics canvas-by-canvas, metric-by-metric. Even the most deft SQL-crafters among us rarely need to stray beyond these shared definitions.

To make this process seamless, Count validates every proposed catalog change, and identifies every cell across your workspace which will break as a result. As you build on changes, it’ll also show you which cells will be fixed, and which ones will sadly remain broken.

Count Metric's validation checker catches broken reports before catalog changes are committed, flagging errors early to prevent bad data from reaching users. By identifying issues before they become problems, it keeps reports accurate, consistent, and reliable—reducing last-minute fixes and building trust in the data.

Looking forwards

We’ve been building Count Metrics along with customers and feel it covers each core use-case we have tested it against. As we move forward from today, we’ll continue to improve it. Upcoming features include:

• dbt and External Version Control Integration - Seamlessly integrate Count Metrics with dbt and popular Git providers (GitHub, GitLab, Bitbucket). Automatically validate, synchronize, and deploy updates across these tools without downtime or friction.
• Hot Reloading - Instantly see metric and semantic model updates reflected as you edit, enabling faster iteration, testing, and validation of your metric definitions.
• Staging and Branch Environments - Safely preview and test your metric and semantic layer changes against existing reports and visualizations, ensuring reliability before pushing changes to production.
• Advanced Metric Relationship Modeling - Model complex interdependencies between metrics, enabling richer visualizations and deeper analytic insights.
• Public API Access - Leverage your metrics externally through a robust public API. Count Metrics definitions won't remain locked within our platform—integrate them seamlessly across your entire analytics ecosystem.