Agentic product analytics

Product analytics on the data you already own — with an AI analyst that investigates the why.

See how it works
01

The AI analyst

Every product team has more questions than analyst hours. This answers them — and shows its working, every time.

Watch it work

One question, asked the way a PM would ask it.

No SQL, no ticket, no waiting for someone to have a free afternoon. The analyst finds the drop, isolates the segment, names the likely cause — and shows you the chart it read.

1Detects the drop2Finds the segment and the step3Explains the likely cause — with the chart it came from
Who it is for, and what it does

Answers for everyone. Analysts for the hard problems.

Most questions a product team asks are simple — and still wait a week for an analyst. The AI analyst answers those in seconds, with receipts. Your analysts get their time back for the work that deserves it.

Ask In buildanswer · build · explain
Watch Nextmonitor · daily review
Dig Laterroot cause · test a hypothesis
WhereIn the productSlackMCP — Claude, Cursor, ChatGPT
Live todaydashboards · funnels · retention · trends · journeys · cohorts · chart narration

Shipping in this order: catalog → Ask → MCP → Watch → Dig. We'll tell you on the call exactly what's live the week you'd go in.

Everyone can askPMs, growth, founders. Plain language, no SQL, no ticket.
The queue disappearsThe trivial and the mid-complex answered in seconds, not a sprint.
Analysts move upOff the number-pulling, onto the strategy they were hired for.

Why you can trust the number

Verified, not guessedEvery answer resolves through one catalog of your metrics, cohorts and funnels — each checked against your real data and approved by a person before it's trusted.
Receipts on every answerThe chart it came from, the window, the segment. Check it in a glance; adjust it if the question wasn't quite what you meant.
It proposes, you approveReading and analysing run unattended. Saving a definition, or sending anything to other people, waits for you.
The catalog agent

Where do the definitions come from? Your data — checked by a person.

Point a language model at raw tables and it guesses: at the column that sounds right, at what “active” means, at a number nobody can check. Ours is never asked to. Every answer resolves through one catalog of your metrics, dimensions, cohorts and context — drafted from your own warehouse, then signed off by someone on your side.

01Indexer

The warehouse indexer reads what you have

Schemas, tables, columns, volumes, relationships and how they are actually populated — profiled where they already sit, read-only. It learns that plan_tier holds four real values, not that it sounds like a plan.

events1.4B rows · 212 types
users38 columns profiled
ordersjoins on user_id
02Agent

The catalog agent drafts your semantic layer

From that index plus your own docs, it proposes the metrics your team argues about, the dimensions each can legitimately be split by, the cohorts that matter, and the business context behind them. Every definition is run against real data before it is offered to you.

Activation ratesignup → first_order ≤ 24h
Checkout conversion5-step funnel
W4 retentionweekly cohorts
03Approval

A person on your side approves it

Your analyst edits the wording, fixes the edge case, rejects what is wrong. Nothing enters the catalog without that sign-off — and nothing outside the catalog ever becomes a number. Definitions stay readable text you can diff and revert.

12 definitions approvedby your analyst
2 sent backwording edited
1 rejectedwrong join
Key metrics One definition per metric, resolving to one query. Activation rate means the same thing in a dashboard, in Slack and in an answer — because there is only one of it.
Dimensions What each metric may be split by — platform, channel, plan, city — and, just as important, what it may not. A split that would produce a misleading number is not offered.
Important cohorts The audiences your team actually debates: new vs returning, by acquisition channel, by plan, power buyers, the ones who churned last quarter. Defined once, reusable everywhere.
Business & product context What each event means, which release shipped when, what counts as a good week, which numbers are seasonal. The context an analyst carries in their head, written down where the agent can read it.

Why this is what stops the hallucination

Nothing is inferred at question timeThe hard thinking — what a metric is, how it joins, what may be split by what — happened once, in the catalog, and a person approved it. The question only picks from what is already true.
Every answer ships its receiptThe chart, the window, the segment, the definition it resolved to. You are never asked to take a number on faith; checking it is a glance, not an investigation.
It is allowed to say noA question the catalog cannot answer comes back as exactly that, with what is missing. An analyst who says “I don't know” is worth more than one who is confidently wrong.
When it can't“I can't answer that yet — refund rate isn't in your catalog. I can draft it from refund_requested and order_placed for your analyst to approve.”
02

The product analytics UI

An AI analyst is only as good as the tool underneath it. This is the full product-analytics seat — the one your team already knows how to drive.

Dashboards

The weekly review your team already runs — on your own warehouse.

Trends, funnels, retention and journeys on one board, reading your events where they land. Nothing was re-instrumented and nothing was copied out to build this.

The tool

Everything your PMs use today — on your data.

A replacement for the product-analytics seat: funnels, retention, metrics, journeys, dynamic segments, alerts. Fluent on day one for a team that knows Mixpanel or Amplitude. Not session replay, not feature flags.

FunnelRetentionMetrics explorerJourneysDynamic segmentsAlerts & monitoring
03

How we deliver it

Privacy-first by construction, not by policy. The architecture that keeps your events in your cloud is the same one that takes 50–70% off the bill.

Privacy-first architecture

Why does your data have to leave to be analysed? It doesn't.

Today
Your cloud
Your warehouseevents land here
a second copy→
Vendor's serversAmplitude, Mixpanel$ billed by volume

A copy of every event leaves your cloud. You pay to store it twice — so you ration what you track.

→
With DepSmith
Your cloud / VPC
Your warehouseevents stay here
←reads in place
DepSmithdeployed here

The analytics moves to the data. No event data crosses the boundary.

ClickHouseSnowflakeDatabricksBigQueryRedshiftS3Postgres
Solid = live today · dashed = on request
→
How it benefits you
0copies of your data outside your cloud
50–70%lower price — you pay for software, not for storing what you already store

If your events don't land in a warehouse yet, there is a collection path — we'll tell you which one you're on before the call ends.  ·  Prefer not to operate anything? There is a hosted option, with a different trade-off on where the data sits — deployment options →

Security & data residency

What can we see? Almost nothing — by construction.

Deployed in your cloudThe whole thing runs in your account, under your IAM. There is no DepSmith-side environment holding your events.
No copy of your event dataRead-only against the store you already run. Nothing is replicated out; there is nothing on our side to breach.
Your credentials, your access controlsWarehouse credentials never leave your perimeter. Who can see what is your existing access model, not a new one.
The AI model boundaryRaw rows stay in your VPC. What the model receives, which provider runs it, and whether you can bring your own key — stated precisely on the Security page. [confirm: provider · what crosses · BYO key · no-training terms]

No compliance badges until we hold them. DPDP-ready because of the shape of the system; SOC 2 status on the Security page. Full Security page →

Pricing

Where does the saving actually come from?

Today
Vendor bill — grows with events held
With DepSmith
Vendor billYour warehouse — already paidDepSmith software
You already pay for the warehouse. The vendor bill is the second copy — and it is the part that goes.
How we charge
  • Not per event. Track everything; the bill does not decide what you measure.
  • No charge for retention. We don't store your data, so we don't bill you for holding it.
  • You pay for the software. Storage and compute are yours and already paid for.

Design-partner pricing on the call. [confirm: unit — per workspace · per seat · flat tier]

50–70% is against incumbent list pricing at your event volume; the worked example with assumptions is on the call.

How the options compare

How is this different from what you use today?

Mixpanel / AmplitudeSelf-hosted OSS (e.g. PostHog)Build it in-houseDepSmith
Where your event data livesTheir serversYours, if you operate itYoursYours
Infrastructure you operateNoneThe full stack — ClickHouse, Kafka, the restAll of itNone — deployed into your cloud
What you are billed forData retentionInfrastructure and the team to run itA platform teamThe software
Data residency under your control✗✓✓✓
AI analystAssistant over their copy of your data✗Build itVerified catalog, in your cloud — app · Slack · MCP

On building it yourself. It works — teams have done it. The price is a dedicated platform team, the better part of a year, and a standing capability gap versus the tool their PMs had before. That team is the cost.

Bring your warehouse. One real question answered from your data, in 30 minutes.
Who this is for

Is this a fit for you yet?

A good fit if

  • You are a consumer product at real scale.
  • Your event data already lands somewhere you control.
  • Your analytics bill is a line item someone asks about.
  • Your team already knows what they want out of a product analytics tool.

Not yet a fit if

  • Data residency isn't a requirement for you.
  • You are early enough that an incumbent's free tier is genuinely fine.
  • Analytics is an insignificant line item for you, and budget is not a worry.

We will tell you so on the call.

How to get started

What happens after you say yes?

1

Connect

Read-only, to where your events already land. Inside your cloud.

prod_eventsread-only ✓
2

The catalog is proposed

The analyst reads your events and your docs and drafts your metrics, cohorts and funnels — each verified against real data.

Activation rateverified ✓
Checkout conversionverified ✓
W4 retentionverified ✓
3

You approve

A person on your side signs off each definition. Nothing becomes a number without this step.

12 definitions approvedby your analyst
4

Ask

Dashboards on day one; questions in the product, Slack or MCP as each ships.

Why was activation down yesterday?
−22% · iOS · OTP step · since 14:20

Typical: days, not a quarter, when your events already land in a warehouse you control. Your history is queryable from the first day — nothing is backfilled.

Questions we get on every call

The practical questions

Does our data leave our cloud?

No. DepSmith is deployed inside your cloud account and reads your events where they already land. We never take a copy and never hold your data. What the AI layer sees, and which model runs it, is on the Security page. [confirm: provider, BYO-key option, what leaves the VPC]

We don't have a warehouse yet — can we still use it?

Yes, with one more step. If your events don't already land somewhere you control, there is a collection path that gets them there first. We'll tell you which path you're on before the first call ends.

Does our historical data work on day one?

Yes, when your events already land in a warehouse you control — we read what you hold, so there is no backfill and no gap. If your history lives only inside Mixpanel or Amplitude, there is an import step; we'll confirm the path for your setup on the call.

Is this a replacement for Mixpanel or Amplitude?

For the product analytics your PMs use daily — funnels, retention, trends, journeys, cohorts, dashboards — yes. It is built to be fluent on day one for a team that knows those tools. It is not session replay or feature flags.

Who builds the metric catalog?

The AI analyst proposes it from your data and your docs — metrics, dimensions, cohorts, funnels — and verifies each against real data. A person on your side approves before anything is trusted. Nothing becomes a number without that step.

How is this different from self-hosting an open-source tool?

Self-hosting solves residency and hands you a stack to operate — ClickHouse, Kafka, the rest — plus their SDK to adopt. Here you operate nothing and the data doesn't move. The comparison table above has it row by row.

How long to go live?

Days, for the common case where your events already land in a warehouse. The setup path with time-to-live per step is on the How it works page. [confirm: steps and durations]

What if we want to leave?

Nothing to export. The data was always yours, in your cloud; the catalog definitions are readable text. You switch off the deployment.

See it running on your own data.

Bring your warehouse. In thirty minutes we'll answer one real question from your data, look at where your events live today, and tell you honestly whether this is a fit yet.

Not ready to talk? Leave an email and we will send you the occasional real update — no drip sequence.