Analytics & BI

Data Analytics Services for Teams Who Already Know Which Numbers They Need

You are on this page because the numbers you need either do not exist yet, or exist and cannot be trusted. Somebody exports a CSV every Monday. A dbt model broke in March and the dashboard has been quietly wrong since. Three systems each hold a version of revenue and reconciling them is a recurring manual exercise with somebody's name on it.

That is a build problem, and this is the build page. We design and build the ingestion layer, the warehouse, the transformation logic and the reporting on top of it — and then we operate that infrastructure as measured Agent Loops, so it does not decay the week after the implementation invoice closes.

If you are not yet sure what to measure, this is the wrong engagement. When two teams define the same metric differently, or nobody can say what a qualified lead is, building pipelines first produces faster disagreement. Start at Business Intelligence Consulting instead — that engagement is advisory, its deliverable is the definitions and the governance model, and it is a smaller piece of work than this one.

We took the human reader out of our own reporting, and had to rebuild the safety net

Facet's own delivery runs through Agent Loops under human command, and our content operation is the clearest example: agents pull performance data for a published piece, score it against the rubric the piece was briefed on, and feed the result into the next brief. Nobody opens a dashboard anywhere in that sequence. The number is read and acted on by something with no context and no memory of what it looked like last week.

That removed a safety net we had not noticed was load-bearing. A dashboard with a human reader has a smoke detector built in — sooner or later somebody says that looks wrong. Take the reader away and the detector goes with it. A pipeline producing zero rows looks exactly like a quiet week.

So we had to build the detection into the pipeline itself, and the loops described further down this page are the ones we run on our own. That is the whole of the Half A claim here, and it is narrow on purpose:

• We optimized against silent failure, not against ugly charts. Most reporting engagements are tuned to make the output look right. Ours had to be tuned to catch the output being wrong when nothing was going to look at it. That is a different set of checks and it is the set your pipeline actually needs.
• The expensive discovery was that "the job ran" is not the same as "the data arrived." An ingestion job returning success with zero rows is the single most common failure we have had to engineer against, on our own stack first.
• A person still owns every consequential call. Agents watch, check and route. A named Facet engineer decides what a failed check means, what gets republished, and whether a number goes on a dashboard at all.

The longer account is in We Run Our Own Business on Agents.

Why analytics builds stall

The pattern is consistent. The pipeline was built, the dashboards launched, and six months later somebody is exporting CSVs by hand again.

The reason is almost never the tools. BigQuery, Snowflake, Redshift, Looker, Power BI, Tableau, Metabase — all mature, all fine. Dashboards do not decay because the data changes. They decay because nobody owns the pipeline.

When a dbt model breaks because an upstream schema changed, somebody has to catch it. When a new channel launches and is not tagged in the warehouse, somebody has to add it. In a project-shaped engagement that somebody stops existing at go-live, and the decay starts the same week.

Work out your own number before you talk to anyone. Count the hours your team spent last week assembling reports by hand — exports, joins, reconciliation, the message asking finance which figure is right. Multiply by fifty-two. (Illustrative arithmetic on your own inputs, not a benchmark: six hours a week is a little over three hundred hours a year, and the scheduled refresh that replaces it runs in minutes.) The hours are the easy half of the argument. The harder half is that reporting arriving two weeks after a period closes cannot change a decision that was already made.

How could AI agents run your analytics operation? Book the data analytics audit — fixed scope, one to two weeks, against your real stack. You leave with your source inventory, a map of where the pipeline is currently breaking or silently wrong, a prioritized build sequence, and an honest read on which of the numbers you want your current data can actually support.

What we build

Data pipeline engineering and warehouse architecture. The ingestion layer, transformation logic and warehouse schema everything downstream depends on. We work across BigQuery, Snowflake and Redshift on the warehouse layer, dbt for transformation and metric definition, scheduled orchestration with alerting on failure and schema drift, and source connectors pulling from your CRM, ERP, marketing platform and finance systems into one schema.

Dashboard and reporting design. Reporting layers built for actual audiences — an executive summary, an operational view for the department head who needs daily numbers, a drill-down for the analyst doing root-cause work — all consuming from the same warehouse so the numbers agree regardless of who pulled them. We build on Looker, Power BI, Tableau and Metabase, and we have opinions: Metabase where self-serve matters more than governance, Looker's semantic layer where governance matters at scale, Power BI for organizations already living in Microsoft 365. We will tell you which fits.

Measurement instrumentation. Where the data you need does not exist yet, the honest first project is instrumentation rather than analysis — event tracking, source system configuration, the fields somebody has to start capturing. We would rather tell you that than build reporting on numbers that are not there.

What the loop actually does

After the build we do not hand off. Four loops run on a defined cadence, and each is agent work for the same unglamorous reason: continuous, mechanically checkable against a stated expectation, and finding nothing most of the time.

• Pipeline health. Ingestion jobs and dbt model runs are checked every cycle — not just for failure, but for success that produced nothing. A source API that starts returning an empty array surfaces the same day rather than at the next board meeting.
• Data quality. Row counts, null rates, referential integrity and metric range validation run as gates on every load. A failed check stops the number publishing instead of publishing it wrong, and routes it to a reviewer.
• Reporting cadence. Performance summaries, trend digests and board snapshots go to the right people on the schedule they were promised, without anybody on your team remembering to send them.
• Metrics governance. The data model is maintained as the business moves: new channels tagged, new product lines modelled, stale metrics deprecated. Definitions drift because businesses change, and something has to notice.

What a person still decides

The loops produce evidence and stop. They do not decide what is true.

• What a failed check means. A quality gate firing on a twelve percent null rate is a fact. Whether that is a broken integration or a sales team that started using a field differently is an interpretation, and a Facet engineer makes it before anything is republished.
• What goes on a dashboard at all. A number that cannot be described — what it counts, what it excludes, where it comes from, how fresh it is, who owns it — does not get published. That is an editorial decision, and holding it is most of the job.
• What the thresholds are worth interrupting for. Set them tight and the alerting becomes the channel nobody reads within a quarter. How much interruption your business will absorb is a judgment, revisited as history accumulates.
• What to do about the number. Reporting narrows the options. It does not choose between them, and an engagement quietly hoping the data will make an unmade decision ends badly.

Where analytics and BI go next

A ladder, not a bundle. A trustworthy pipeline that never goes further is a complete outcome.

• Business Intelligence Consulting — the advisory rung, either before this one or alongside it, when the constraint turns out to be that nobody has settled what the metrics mean.
• Information Architecture Analysis — for when the naming and structure underneath the data are the actual problem.
• Data Managed Services — the ongoing run layer for the data platform itself.
• Agentic Engineering and AI Managed Services — the rungs above, for when a defined metric should trigger work rather than get read. That is the step where a threshold breach opens the work item with context attached instead of appearing in a weekly review. The Agentic Operating System explainer covers the shape while those service pages are in production.

Why Facet

Facet Interactive has been a boutique systems integrator since 2014, and CIOReview named us a Top 10 Digital Transformation Services Company in 2021. Our team of 40 spans 9 timezones and 6 continents, backed by a network of 500+ open-source, data and IT specialists.

We are open-source centric and take no vendor referral fees, so the platform recommendation is about fit rather than margin. Our standard is dbt for the transformation layer, because version control, testing, documentation and lineage are what let somebody you hire next year work out what a number means without asking you.

Start with a data analytics audit

How could AI agents run your analytics operation? Book the data analytics audit — fixed scope, one to two weeks, against your real stack. We inventory your sources, test what your current pipeline is actually producing, identify where it is silently wrong, and hand back a prioritized build sequence with the risks named. The findings are yours whether or not you engage Facet for the build.

Sometimes the audit says do not build this. If your reporting problem turns out to be a definition disagreement rather than an infrastructure gap, the right answer is a smaller advisory engagement and no pipeline work at all — and if the data you need was never captured, the honest finding is instrumentation, not analysis. Both answers cost us the larger build, which is why they are worth more to you before the engagement than during it.

How pricing works. The audit is fixed-fee. The build is scoped and quoted after it, priced on source count, data quality and reporting complexity. Ongoing loop operations are a monthly retainer, revisited as your stack changes. Facet's project range starts at $6,000; there is no standard price list, because no two data estates are the same.

FAQ

How is this different from your business intelligence consulting?

This page is implementation-forward and that one is advisory-forward, and the distinction is about what you already know. If you can state the numbers you need and the problem is that the pipelines do not exist or cannot be trusted, you are in the right place. If two teams would define those numbers differently, or nobody can say who owns them, Business Intelligence Consulting is a smaller and more useful engagement first — its deliverable is the metric definitions and the governance model, not a warehouse.

Do we have to migrate off our existing tools?

Not necessarily, and we will not recommend it reflexively. We evaluate the current stack first. If it is fundamentally sound we build on top of it. If it is genuinely the source of the problem, we will say so and scope what a migration requires. We do not earn referral fees on any of it.

How long until we get something usable?

First working reporting typically lands in weeks rather than months, because we scope to a small set of decisions rather than modelling the whole business at once. Full implementation through stable operations usually runs six to twelve weeks depending on source count and data quality. Multi-source environments with historical quality problems take longer, and we flag the specific risks likely to extend the timeline during the audit rather than discovering them in week eight.

What happens when a pipeline breaks after go-live?

That is what the pipeline health and data quality loops are for. A failed check stops the affected number from publishing rather than letting it publish wrong, routes it to a named engineer, and produces a record of what was found and what was done. You hear about it from us, with a resolution attached, rather than from somebody in a meeting.

Every other system you own tells you when it breaks

A website goes down and the phone rings. An application throws an error and somebody sees a stack trace. A server runs out of disk and alarms. The entire discipline of operations is built on the assumption that failure is loud.

Data infrastructure is the exception, and it is the only one. A broken pipeline does not stop. It keeps producing output, on schedule, in the right format, looking exactly like it did last week — and the output gets used. The failure is not the downtime. The failure is the set of decisions made off a number that was wrong for six weeks: the spend that was not reallocated, the price that was not changed, the channel that was quietly defunded on figures that had stopped arriving.

Those decisions are not re-made when the pipeline is fixed. That is what makes this different from every other system in your business, and it is the reason the unglamorous half of this work — the checks, the gates, the thing that notices zero rows — is the half worth paying for.