Home/Solutions/Business Intelligence

Business Intelligence

Plain-language answers to genuinely hard questions, for people who do not write SQL.

Priori Lens is business intelligence over the context layer. Anyone on the team asks in plain language; an analysis engine backed by your ML models plans the query, runs it, and returns the chart with its trace. This page explains what Lens is, why it is more than a charting tool, and why the numbers can be trusted.

Priori Lens

A revenue dashboard in Lens: first versus repeat purchases, KPI tiles, and the monthly trend — A live dashboard in Lens, reading the context layer: first versus repeat revenue, the drop-off curve, and the monthly trend.

Why answers take days

The three-day ticket

Someone asks which offers held up after refunds. An analyst writes the query, checks the joins, and ships the chart three days later. The call was made on day one.

Dashboards answer old questions

A dashboard is a set of questions someone chose months ago. This week's question is a new slice, so it goes back into the ticket queue.

Text-to-SQL guesses

Generic natural-language BI writes SQL against a schema it does not understand. It joins the wrong tables with full confidence, and you cannot tell from the chart.

What Lens is

Lens is a natural-language interface, a query builder, and dashboards, all reading the context layer. The person asking never sees a schema. A question in plain language resolves against defined objects: revenue means the same purchases, net of the same refunds, every time anyone asks.

The query builder shows the resolution. You see which objects, relations, and filters produced the chart, and you can adjust any of them without writing SQL.

The query builder: the question, the objects it resolved to, and the chart.

Not a charting tool

A dashboard tool draws the columns you hand it. Lens sits on an intelligence layer. When a question takes several steps, it plans them: pull the cohorts, adjust for refunds, compare the periods, then chart the result. You ask once; the analysis happens behind the answer.

The ML layer is part of every question. Labpublishes its model scores back onto the objects, so chargeback risk, lifetime value, and churn probability are fields like any other. “LTV-weighted ROAS by creative” is one question, and a data-science project nowhere in sight. Sentry's learned baselines are queryable the same way, so “which of these dips are abnormal” gets an answer grounded in each metric's actual shape.

A viewer filter added once scopes every tile it can reach through the model. Your view rides in the link until you make it the default for everyone.

Hard questions

Questions from a normal week that a charting tool cannot touch.

Multi-step analysis. Take January's campaign cohorts, adjust revenue for refunds, and show week-by-week retention against December's cohorts. Lens plans the steps and returns one chart.
Situation modelling. Model net revenue if geo X traffic moves from offer A to offer B, using each offer's historical conversion and rebill rates. The scenario runs against the graph and comes back as baseline versus proposal.
Similarity search. Find sub-IDs behaving like the ones that took down MID-3 last spring. The comparison runs on object histories and model scores, and the shortlist is watchable from that moment.

The agent answering a spend reallocation question in Slack: ranked affiliate tiers with returns, thin-sample warnings, and stated assumptions — A reallocation question answered: ranked tiers, thin-sample warnings, and the assumptions stated.

Why you can trust the number

Trust comes from the layer underneath, and from being able to check. Joins are defined relations in the ontology, so the model cannot invent them. Metrics are shared definitions, so two people asking the same question get the same number. And every figure carries its trace: the objects it counted and the source rows behind them.

When a number looks wrong, you open the trace instead of re-deriving the query. Either the definition is wrong, in which case you fix it once for everyone, or the data is wrong, in which case lineage shows you which source.

The Generated SQL panel showing the exact statement behind a result — Show the work: any result compiles to the exact SQL that produced it, one click away.

The agent answering 'tell me how my affiliates are doing' with a chart, the defined fields the answer resolved to, and a link into the query builder — The answer names the fields it resolved to, with a link into the query builder.

How you use it

Ask, refine, pin. A question returns a chart. Follow-ups narrow it: by campaign, by MID, by week. When a view is worth keeping, pin it to a dashboard. Dashboards stay live because the context layer stays synced, so the Monday meeting reads this morning's state.

The data team stops being a ticket queue. Analysts define objects and metrics in the ontology; everyone else answers their own questions on top of those definitions.

Every chart the agent shows ran first. The platform refuses to render a picture whose query it did not just execute, so a chart in chat is a record of real rows, not an illustration.

A question in plain language. The agent runs the query, shows the chart with its caveats, and one click pins it to a dashboard or opens it in the query builder.

So what?

Non-technical users answer their own questions. No SQL, no schema, no ticket. The affiliate manager checks an offer's refund rate and moves budget the same morning.
Hard questions get answered the day they are asked. Multi-step analyses and scenario models come back as charts while the decision is still open, not after the spend is committed.
Decisions get modelled before they ship. Traffic moves and offer changes run as scenarios against the graph first, so a losing move shows up as a chart instead of a down week.
ML is in every question. Risk, LTV, and churn scores are fields anyone can query, so spend ranks affiliates by what their users are worth, not by who converts cheapest.

Book a demo All solutions