One Semantic Layer, Twenty Clients

Agencies sell the same build twenty times

An agency that runs reporting for twenty clients has built roughly the same stack twenty times, and billed it as setup twenty times. Ad spend from Meta and Google, GA4 sessions, orders from the store, a blended ROAS view, a channel dashboard, a monthly deck. The names on the invoices differ. The definitions barely do. Which points at where the real margin in agency analytics sits: not in building each stack faster, but in not rebuilding it at all. One canonical model of marketing data, versioned like software, instantiated per client on that client's own data.

Most agencies know this, in the sense that everyone copies last quarter's dashboard and find-replaces the client name. Copying is where the trouble starts. A copy is a fork, and twenty forks drift.

What the per-client rebuild costs

Setup time is the visible cost. Three to six weeks of a senior analyst per onboarding is typical for a proper build: connect sources, model spend and orders, reconcile the numbers the client already distrusts, assemble the views. It gets billed once and maintained forever, and maintenance is where the copies hurt. Twenty slightly different stacks means every GA4 schema change, every attribution adjustment, every bug fix has to be applied twenty times by hand. Some of the twenty get skipped. Nobody knows which.

Definition drift is the quiet cost. ROAS means something slightly different in every deck: gross revenue in one, net of refunds in another, a third including the agency fee in the cost base. Then a new marketing lead arrives at client B from client A, both yours, and asks why the same agency reports the same metric two different ways. There is no good answer to that question, and the footnote explaining the methodology difference convinces nobody. Drift also breaks the agency's own benchmarking, since its twenty ROAS columns are quietly twenty different metrics.

The last cost is the people. The analysts hired to interpret numbers spend their weeks assembling them, and the good ones leave over exactly this. Reporting stays a cost center: hours rise linearly with client count while the retainer does not.

The template pattern

A semantic layer template is a canonical, versioned model of marketing data. Spend by channel, campaign, and day. Sessions. Orders and customers. The blended metrics on top, blended ROAS, CAC, new versus returning revenue, each with one tested definition. The transform side is versionable with tools like SQLMesh or dbt; the semantic layer adds the business definitions that dashboards and AI consume.

Per client, you instantiate rather than rebuild. Connectors and account IDs differ; the model does not. Whatever is truly specific to a client, a marketplace channel, a wholesale arm, a custom margin input, becomes an explicit extension layered on the core instead of a fork of it.

In practice the template also pins down the tedious parts that eat onboarding weeks: channel taxonomy, UTM conventions, currency conversion, timezone handling, and the data tests that catch a broken spend import before the client does. None of that is intellectually interesting, which is the best reason to solve it once.

Versioning is what makes the pattern compound. Improve the payback model, fix an attribution bug, add a metric, and you roll the template version forward across the whole book of clients. The fix propagates once. And drift ends, not because analysts became more disciplined, but because deviating from the canonical definition now requires writing an explicit extension that shows up in review.

Client isolation is a selling point

The instinct to resist is pooling client data in one agency-owned database, which makes multi-tenancy someone's security problem and every offboarding a negotiation. Run it the other way: each client's stack lives in its own warehouse project, ideally a BigQuery project under the client's own billing and IAM. Nothing is commingled. Client B's data cannot leak into client C's dashboard because no query can reach both.

This changes pitches more than architecture. "If you ever leave us, you keep the warehouse, the raw data, and all the history" is a sentence most agencies cannot say, and prospects notice, because they have all been burned by a vendor or agency that held the data hostage on exit. The full argument for client-side ownership is here: You Should Own Your Marketing Data Warehouse. Most Vendors Disagree.

Workspaces finish the setup. Each client team logs into a workspace that contains their data and nothing else, while agency staff work across all of them from one place.

What changes commercially

Onboarding drops from weeks to days: instantiate the template, connect the client's sources, map whatever extensions their business needs. The first monthly meeting shows live numbers instead of screenshots of a work in progress.

Reporting stops being a monthly deliverable and becomes an always-on service. The deck was always a snapshot of questions the client asked last quarter; a living dashboard plus answers on demand replaces it, which is the same shift we describe for in-house teams in Your Dashboards Are Answering Last Quarter's Questions. The monthly meeting changes character too. Less reading numbers aloud, more deciding what to do about them, which is the part the client is actually paying a senior person to attend.

And analyst time moves up the stack. When assembly is templated, the billable hours that remain are interpretation, and interpretation is both higher value and harder for the client to take in-house. Setup revenue shrinks. Margin on everything after setup grows with every client added to the same template. That trade is worth taking.

Packaging follows the same logic: a small fixed onboarding fee, because the setup really is small now, and a monthly reporting and insight retainer that no longer has to smuggle rebuild hours inside it. Priced against the client's alternative of hiring half a data analyst, it holds up well.

Where Verity fits

Verity matches this shape of work directly: the semantic layer and models run per client on the client's own BigQuery, workspaces keep each client's team inside their own data, and unlimited users mean the agency and every client stakeholder log in without a per-seat bill. Dashboards instantiate from the same governed definitions, so the fix an analyst ships on Tuesday is live for every client by Wednesday.

Frequently asked questions

Does a shared template mean every client gets identical reporting?

The core definitions are identical on purpose: spend, sessions, orders, and blended metrics mean the same thing across the book. What each client sees is their own data, plus extensions for whatever is specific to their business. Sameness of definitions is the feature; the presentation on top can differ as much as each client needs.

What happens to the stack when a client leaves?

The warehouse, the raw data, and the modeled history stay with the client, because they were in the client's project from day one. The agency revokes its own access and hands over documentation for the extensions. Offboarding this clean is rare enough that it belongs in the pitch deck.

How much per-client customization is too much?

A useful rule: the first time an extension is needed, build it for that client; the third time, promote it into the template. If a prospect's business does not fit the canonical model, marketplace-only sellers and long-cycle B2B pipelines are the usual cases, it is better to price that as custom work at the pitch stage than to discover it during onboarding.