Product analytics in your warehouse

Kubit runs product analytics on clickstream events that already sit in your cloud data warehouse. Each report compiles to SQL for that warehouse, runs on your compute and returns only the aggregated result. No data silo to secure, and your events stay in your account. This page covers how that works on any supported warehouse. For a worked example on one stack, see the recipe RudderStack events on ClickHouse.

How Kubit reads your events

Kubit reads your event tables in place, over a connection you give it. A report goes through four stages:

Stage	What happens
Model	You map your tables to fact tables, subjects and fields once, in the Modeler.
Compile	Kubit turns a report (a funnel, say) into SQL in your warehouse’s dialect.
Run	The query runs on your warehouse, as the read-only user or role you created for Kubit.
Return	Only aggregated rows come back to Kubit. Event-level rows stay in your warehouse.

Kubit never writes to your event tables. Some features need a small helper database that Kubit owns, such as KUBIT in Snowflake or KUBIT_DB in ClickHouse. Each warehouse page lists it.

Ways to get events into your warehouse

Kubit supports two ways to give it clickstream events. Both end with Kubit querying a warehouse:

Path	Where events live	Set up with
Your own warehouse	Your Snowflake, BigQuery, Databricks, ClickHouse or Redshift	The page for your warehouse under Bring your own warehouse
CDP destination	A Kubit-hosted Snowflake account that your CDP loads	The page for your CDP under Data sources

If your CDP already loads your warehouse, use the first path. Your warehouse stays the single source of truth, and you skip a second pipeline and any event replay. Availability: Bring Your Own Warehouse is available on selected plans.

Supported warehouses

Warehouse	Direct connect	Data share
Snowflake	Yes	Yes (Secure Data Sharing)
BigQuery	Yes	Yes (dataset sharing)
Databricks	Yes	Yes (Delta Sharing)
ClickHouse	Yes	No
Redshift	Yes, through VPC access	No

With direct connect, Kubit logs in as a read-only user you create and runs queries on your compute. With a data share, you share tables or views with a Kubit account, and Kubit runs the queries on its side. Bring your own warehouse covers direct connect setup for each warehouse.

What Kubit needs from your tables

Kubit works best on event tables shaped as a star schema: one or more fact tables of events, joined to dimension tables such as users or plans.

Requirement	Why
One row per event, with an event name column	Reports filter and step through events by name
A user identifier on every event, for signed-in and anonymous users	The User subject counts people, so it needs an ID on every row
An event time stored as `timestamp` or `date`, not text	Time zone conversion at query time slows every report
Common properties stored on the event row (app version, platform, country)	Filters and group-bys on inline columns don’t need a join
A date clustering or partition key on large fact tables	Most reports filter by date first

CDP tables mostly fit already. RudderStack and Segment write one table per event plus aggregate tracks, pages and screens tables. Model the aggregate tables first, then add per-event tables for the properties you need.

Subjects for clickstream data

A subject is the identifier a report counts and groups by. A clickstream model needs at least two subjects:

Subject	What it is	Typical column
Event	One tracked action, page view or screen view	The event’s message ID
User	The person who sent the event, signed in or anonymous	The user ID, falling back to the anonymous ID

You can add subjects, such as an account or a device, in the Modeler. You can’t delete one once it’s created. When you add agent traces later, the Session, Trace and Span subjects join the same model. A user who chats with your agent and then upgrades on the web counts as one User. See Concepts for the trace subjects.

Analyze the data

Once the model exists, the same tools work on any warehouse:

Tool	Use it to	Page
Reports	Count, convert, retain and follow users across events	Reports overview
Dashboards	Put reports side by side and refresh them on a schedule	Dashboards
Lumos	Ask questions in plain language and get reports back	Lumos

MCP prompt examples

“How many users signed up each day last week?”

“Build a funnel from signup to project_created for the last 30 days, broken down by platform”

Bring your own warehouse: choose direct connect or a data share.
Data sources: load events from RudderStack, Segment, Snowplow or mParticle.
RudderStack events on ClickHouse: a full setup on one stack.

Start here

Agent Observability