https://definite.app/ Latest articles from Definite Mon, 12 Oct 2026 00:16:55 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en All rights reserved 2026 https://definite.app/blog/cloudera-alternatives https://definite.app/blog/cloudera-alternatives Mon, 06 Jul 2026 00:00:00 GMT hello@definite.app (Mike Ritchie) https://definite.app/blog/databricks-alternatives https://definite.app/blog/databricks-alternatives Mon, 06 Jul 2026 00:00:00 GMT hello@definite.app (Mike Ritchie) https://definite.app/blog/hipaa-compliant-analytics https://definite.app/blog/hipaa-compliant-analytics Mon, 06 Jul 2026 00:00:00 GMT hello@definite.app (Mike Ritchie) https://definite.app/blog/snowflake-migration-guide https://definite.app/blog/snowflake-migration-guide Mon, 06 Jul 2026 00:00:00 GMT dateadd(day, -30, current_timestamp()) group by 1 order by 3 desc; ``` Then break `query_history` down by user, and join it to the `sessions` view (its `client_application_id` column) to see which tool issued each query. Classify every workload into one of four buckets: 1. **BI dashboards.** Repeated, predictable queries from Looker, Metabase, Tableau, or whatever you run. Usually the majority of query volume and the easiest to port. 2. **Scheduled transformations.** dbt runs, Tasks, stored procedures. Port these as a dependency graph, not a pile of files. 3. **Ad hoc SQL.** Analysts poking around. Low risk; they follow the data. 4. **Applications.** Anything programmatic hitting Snowflake through a driver. Highest risk, migrate last. While you're in there, find the dead weight. `ACCESS_HISTORY` (Enterprise edition and up) shows which tables were actually read in the last 90 days. In our experience most accounts store far more than they query, and every table nobody reads is a table you don't have to migrate. The output of this step is a spreadsheet: every workload, its owner, its query volume, its latency expectation, and which bucket it falls in. Boring. Also the thing that separates a three-week migration from a six-month one. ## Step 2: Export to Parquet in your object store Your data leaves Snowflake through `COPY INTO`, landing as Parquet files in a bucket you own: ```sql copy into 's3://your-bucket/snowflake-export/orders/' from analytics.prod.orders storage_integration = your_s3_integration file_format = (type = parquet) header = true max_file_size = 262144000; ``` Three gotchas, all learned the hard way: - **Set `max_file_size`.** The default is 16 MB, which fragments a large table into thousands of tiny files that every downstream engine will hate. 250 MB to 1 GB per file is a good target (5 GB is the max). - **Keep `header = true`.** That's what preserves your column names in the Parquet schema instead of `col1, col2, col3`. - **Cast `TIMESTAMP_TZ` and `TIMESTAMP_LTZ` columns first.** Snowflake errors when unloading those types to Parquet. Cast to `TIMESTAMP_NTZ` (and store the zone separately if you need it) before the export. On cost: you pay normal compute for the unload queries, but data transfer is free when the destination bucket is in the same region and cloud as your Snowflake account. Put the bucket next to Snowflake. Cross-region or cross-cloud unloads pay a per-byte transfer fee. Export in this order: the tables your BI layer reads, then transformation sources, then everything else that survived the dead-weight cut. And note what you just did, because it matters beyond the migration: your data now exists in an open format, in your bucket, readable by any engine ever written. Even if the migration stalls at this step, that copy is the cheapest insurance in data engineering. ## Step 3: Stand up the lakehouse and catalog A [lakehouse](/blog/what-is-a-data-lakehouse) is three things: Parquet files in your object store (you just made those), a catalog that tracks tables, schemas, and snapshots, and a query engine that reads them. No idle warehouse meter, no per-credit billing. Storage costs whatever your cloud provider charges for the bucket. In Definite, this layer is DuckLake (the catalog) plus DuckDB (the engine), and the data stays in your object store as plain Parquet. Point the platform at your export bucket and register the tables. If you're assembling it yourself, the same architecture works with open-source parts; the catalog is the piece you can't skip, because without it you have a pile of files instead of tables with schema evolution and time travel. Here's how the concepts map: | Snowflake | Lakehouse equivalent | |-----------|---------------------| | Database / schema / table | Schema / table in the catalog | | Virtual warehouse | Query engine (DuckDB); no idle meter, no credits | | Time Travel | Catalog snapshots | | Stages | Your object store, directly | | Snowpipe | Connectors and streaming ingest | | Streams and Tasks | Scheduled transformations and automations | | RBAC | RBAC | | Secure Data Sharing | No direct equivalent (see Step 0) | The economics of this swap are worth a paragraph. Snowflake's list price for storage is roughly what object storage costs anyway, so storage isn't where you win. The win is compute: you stop paying per-credit rates ($2 to $6 per credit, [depending on edition and region](/blog/understanding-snowflake-pricing)) for a meter that runs whenever anything touches the data, and you stop paying the 60-second minimum every time a warehouse wakes up to serve one dashboard tile. ## Step 4: Port your models and semantic layer Your transformation SQL is the real migration surface. Good news: SQL dialects have converged, and DuckDB is close to Snowflake for analytics work. `QUALIFY` ports as-is. Window functions port as-is. Most dbt models port with light edits. The edits you'll actually make: - **JSON access.** Snowflake's `col:field::string` becomes DuckDB's arrow syntax, `col->>'field'`. - **`FLATTEN`** becomes `UNNEST`. - **`IFF(cond, a, b)`** becomes `IF(cond, a, b)` or a `CASE` expression. - **Date function signatures** differ slightly (`DATEADD` and `DATEDIFF` variants). Mechanical, not architectural. Port in dependency order: staging models, then marts, then the reporting layer. After each layer, validate against Snowflake with the same two queries on both systems: row counts per table, and a sum of your key measures grouped by month. Any drift gets fixed before you move up a layer. This is also the moment to rebuild your metric definitions in a semantic layer, once, instead of scattered across dashboard SQL. If revenue is defined in eleven places on Snowflake today, migrate one definition, not eleven. In Definite the semantic layer is built in and Fi, the AI analyst, works from it, so "which of these three revenue numbers is right" stops being a recurring meeting. ## Step 5: Repoint BI and cut over consumers Now work through the inventory from Step 1, lowest stakes first: 1. **Internal, low-traffic dashboards.** Repoint them, let the owners bang on them for a week. 2. **Scheduled reports and alerts.** Verify a full cycle of each (the Monday report on a Monday). 3. **High-visibility executive dashboards.** By now you've built trust with the earlier tiers. 4. **Applications and embedded analytics.** Last, because their failure modes are customer-facing. Do not decommission anything yet. Snowflake keeps running through this entire step. Every consumer you repoint is reversible in minutes if something looks wrong, which is exactly why you cut over consumers one at a time instead of flipping the whole company on a Friday. The typical experience at this step is that dashboards get faster. Dashboard queries that took seconds on a shared warehouse come back sub-second from DuckDB over partitioned Parquet. Your analysts will notice before you tell them. ## Step 6: Run both in parallel and compare Run both systems for at least one full billing cycle. This is the step impatient teams skip, and it's the one that turns a migration from a leap of faith into a decision with receipts. Track four things, weekly: | Metric | How | |--------|-----| | Cost | Snowflake invoice vs. object storage + platform cost | | Latency | p95 dashboard load times on both systems | | Parity | Row counts and key-metric sums, both systems, same day | | Failures | Job failures and their causes on the new system | The parity checks are non-negotiable. If numbers drift, you stop cutting over and fix the drift. A migration that ships wrong numbers fast is worse than no migration. The cost comparison at the end of the cycle is your actual business case, with real invoices instead of estimates. That's the document you show whoever signs the contracts. ## Step 7: Decommission The satisfying part, done in order: 1. **Check your contract dates.** If you're on a capacity contract, time the shutdown to the renewal. Prepaid credits you walk away from are real money. 2. **Freeze writes to Snowflake.** Pause the ingestion jobs feeding it. Anything still writing to Snowflake after your consumers left is paying to update tables nobody reads. 3. **Run a final export.** One last `COPY INTO` pass for anything that changed since Step 2. This snapshot is your archive, and it's already in the open format your new system reads. 4. **Export what history you need.** Time Travel versions don't come with you. If compliance needs specific historical states, export them now or keep the account read-only until the retention window lapses. 5. **Cancel per the contract.** Then turn off the extraction tooling, the credits, and the line item. Keep the final Parquet snapshot in cold storage indefinitely. It costs almost nothing and it's the complete record of your Snowflake era. ## The short version Inventory what you run. Export to Parquet in your own bucket. Stand up a lakehouse with a real catalog. Port models in dependency order with parity checks. Repoint consumers lowest-stakes first. Run parallel for a billing cycle. Decommission on your contract date, not before. Teams with straightforward analytics workloads get through this in weeks. The ones who shouldn't attempt it (heavy data sharing, extreme concurrency, dozens of Snowflake-native jobs) can find that out in Step 0, for free. ## FAQ **How long does a Snowflake migration take?** For a typical analytics workload (BI dashboards, scheduled transformations, ad hoc SQL), plan on a few weeks. The export and lakehouse setup take days. Porting models is the variable part, and the parallel run should cover at least one full billing cycle so you can compare real invoices. Six-month migrations happen when teams skip the inventory step and discover their dependencies one outage at a time. **Does exporting data from Snowflake cost anything?** You pay normal warehouse compute to run the `COPY INTO` unload. Data transfer is free if the destination bucket is in the same region and cloud as your Snowflake account. Cross-region or cross-cloud unloads incur a per-byte transfer fee, so put the export bucket next to your Snowflake deployment. **What happens to Time Travel history when we leave Snowflake?** It doesn't come with you. An export captures current table state, not historical versions. Going forward, a lakehouse catalog like DuckLake gives you snapshots and time travel on the new system. If you have a compliance need for old versions, export the specific historical states you need before you cancel, or keep the account read-only until the retention window lapses. **Can DuckDB really replace a Snowflake warehouse?** For most analytics workloads, yes. A tuned single-node engine handles workloads into the 100 TB range, with sub-second dashboard queries on well-partitioned Parquet. Where it doesn't fit: petabyte-scale distributed joins and thousands of concurrent queries hitting one endpoint. Snowflake's multi-cluster warehouses are genuinely good at massive concurrency, and if that's your shape, keep it. **What if we depend on Snowflake data sharing?** Secure Data Sharing is the strongest reason to stay. If partners consume your data through shares or Marketplace listings, there's no lakehouse equivalent that's zero-work for them. Some teams migrate internal analytics and keep a minimal Snowflake account serving the shares. If you control both sides, sharing Parquet in object storage works and is cheaper, but it's a real project for the consumers. --- If you want to see the target state before committing to Step 1, Definite stands up the whole destination: connectors, the DuckLake lakehouse on your object store, BI, semantic layer, and Fi, the AI analyst. It also [deploys into your own cloud](/platform/private-deployment) via a single Helm chart if the data can't live in ours. [Watch the recorded walkthrough](/video). ]]> hello@definite.app (Mike Ritchie) https://definite.app/blog/understanding-motherduck-pricing https://definite.app/blog/understanding-motherduck-pricing Mon, 06 Jul 2026 00:00:00 GMT hello@definite.app (Mike Ritchie) https://definite.app/blog/what-replaces-what-on-prem-data-stack https://definite.app/blog/what-replaces-what-on-prem-data-stack Mon, 06 Jul 2026 00:00:00 GMT What replaces what: the cloud data stack, mapped to Definite Layer You run today In Definite What actually ports Storage + query Snowflake, BigQuery, Databricks SQL Lakehouse: DuckLake tables on your object store, queried by DuckDB Analytical SQL, with dialect changes. Stored procedures and Spark jobs do not. Ingestion Fivetran, Airbyte Built-in connectors + scheduled syncs Nothing to port; it was configuration. Re-authenticate and backfill. Transformation dbt SQL datasets on a schedule Models port as SQL. Macros and tests need rework. Orchestration Airflow Scheduled syncs + Python pipelines Simple schedule-and-run DAGs map cleanly. Exotic DAGs need rework. BI Looker, Tableau, Power BI Definite dashboards Dashboards get rebuilt, not imported. The modeling underneath ports. Metrics LookML, Cube, dbt metrics Definite semantic layer (YAML) Dimensions, measures, and joins translate one-to-one. AI on your data Custom RAG / agent stack Fi, the AI analyst Replaces the build. You keep your model endpoint. Internal tools Streamlit apps Data apps Rebuilt on governed data. Heavy custom apps may stay as code. Now the nuance, row by row. ## Storage and query: Snowflake, BigQuery, and Databricks SQL The warehouse becomes a lakehouse: DuckLake tables on an S3-compatible object store you own, queried by DuckDB. Your data sits in open Parquet files in your own bucket, with the catalog in Postgres. Nothing about the storage layer is opaque or vendor-locked. Analytical SQL mostly ports. DuckDB speaks standard SQL plus the conveniences you actually use (window functions, QUALIFY, lateral joins). What does not port: Snowflake stored procedures, tasks, and streams; BigQuery scripting; anything written for Spark. Those get re-expressed as SQL datasets and Python pipelines, or they stay where they are. The other honest line: DuckDB is a single-node engine. A tuned single node with partition pruning covers the overwhelming majority of analytics workloads at sub-second latency, and it handles 100+ TB lakehouses. It does not cover petabyte-wide, shuffle-heavy Spark joins. If that is your daily work, keep Databricks for it. Worth knowing if you got here by searching for on-prem versions of these tools: [Snowflake cannot run on-premise](/blog/snowflake-on-premise) in any form, and [Databricks always keeps its control plane in its own SaaS](/blog/databricks-on-premise), even when your clusters run in your VPC. ## Ingestion: Fivetran and Airbyte Managed EL becomes built-in connectors with scheduled syncs. There is no code to port here because there never was code, just configuration. The migration work is re-authenticating sources and running backfills, not rewriting anything. The honest caveat is coverage. Common sources (Postgres, MySQL, Salesforce, HubSpot, Stripe, Shopify, the major ad platforms) are covered. If you depend on a long-tail SaaS connector, check your exact source list before you commit. Anything missing gets built as a Python pipeline inside the platform, calling the source API directly. That is more work than a checkbox, but the pipeline stays inside your boundary with everything else. ## Transformation: dbt dbt models are SELECT statements, and they port as SQL datasets: the same SQL, running on a schedule, with dependencies between datasets standing in for the dbt DAG. For most projects this is the smoothest row in the table. Three things need real rework. Jinja macros get expanded into plain SQL. Incremental materialization logic gets re-expressed. And dbt tests get re-authored (a not-null check is one line of SQL, but someone has to write it). A 40-model project moves in days. A 400-model project with a deep macro library moves in weeks, and you should budget for that honestly. ## Orchestration: Airflow Most Airflow usage in an analytics stack is a schedule: sync these sources, then run these transforms, then refresh these dashboards. That maps directly to scheduled syncs and Python pipelines with triggers, and it is the part of Airflow nobody enjoys operating anyway. The part that does not map: deeply customized DAGs. Custom operators, dynamic DAG generation, sensors watching external systems, DAGs that orchestrate work far outside analytics. Definite replaces analytics orchestration, not general-purpose workflow infrastructure. If Airflow does both jobs for you, split them: move the analytics schedule in, leave the rest where it is. ## BI: Looker, Tableau, and Power BI Dashboards get rebuilt, not imported. Nobody converts a Tableau workbook faithfully, including us, and you should be skeptical of anyone who says otherwise. Two things make the rebuild far cheaper than the original build. First, the modeling underneath ports (next row), and a dashboard on top of a good semantic layer is minutes of work, not weeks. Second, [Fi](/fi) does most of the rebuilding: describe the dashboard and it assembles the queries and charts from governed metrics. Credit where due: Tableau's visualization depth is real, and Power BI Pro comes bundled into Microsoft 365 E5, which is hard to argue with on price. What you get in exchange for the rebuild is one system instead of three, sub-second DuckDB-powered dashboards, and BI that lives inside the same boundary as the data. ## Metrics: LookML, Cube, and dbt metrics Definite's semantic layer is YAML: models, dimensions, measures, joins. If you have LookML or Cube definitions, the concepts map one-to-one and the rewrite is mechanical, closer to transcription than translation. dbt metrics port the same way, as measures. Mechanical does not mean free. Years of LookML with heavy Liquid templating hide business logic inside the templating layer, and that logic has to be made explicit on the way over. Most teams find the exercise overdue anyway. This layer matters more than it looks. In Definite the semantic layer is not optional: dashboards and Fi both read from it, so a metric means one thing everywhere, including to the AI. ## AI on your data: the custom RAG stack Over the last two years a lot of teams built the same internal project: a vector store, schema retrieval, a prompt pipeline, a SQL-writing agent, and a slowly growing eval suite, all so people can ask questions about company data. Fi replaces that build. It reads the semantic layer, writes SQL against the lakehouse, builds dashboards, and shows its work. Because this whole map is self-hosted, [Fi runs inside your tenant](/blog/private-ai-data-analyst) and calls a model endpoint you control: Amazon Bedrock, Azure OpenAI, Vertex, or self-hosted open weights. Schemas, prompts, and results stay inside your boundary. The scope caveat: Fi is a data analyst. If your agent stack also handles support triage or document search, that work is not replaced by this row. ## Internal tools: Streamlit Streamlit apps exist because dashboards stop at charts. Someone needed a filterable table, a small form, a tool for the ops team, so they wrote Python. Those become data apps: small internal apps built on the same governed data as everything else, and Fi can build them from a description. The caveat: an app with heavy custom components or write paths into external systems may deserve to stay as code you own. The common case (a lookup tool, an internal report, a one-screen workflow) moves. ## Where the map breaks Three things this platform does not replace, stated plainly: - **Petabyte-scale Spark.** DuckDB is a single-node engine. Wide, shuffle-heavy joins over petabytes belong on Databricks or your own Spark cluster. - **Event stream processing.** Kafka and Flink are a different category. Definite ingests continuously and on schedules for analytics; it is not a stream processor. - **General-purpose orchestration.** If Airflow also runs your ML training and your invoice processing, keep it for those jobs. Move the analytics schedule. If a vendor tells you their platform replaces everything with no residue, they are describing a slide, not a migration. ## One Helm chart, one boundary Everything above deploys as a single Helm chart into your Kubernetes: your cloud account, your data center, or fully air-gapped with a self-hosted model and zero required egress. There is no vendor control plane on the other end of a required connection, which is exactly the failure mode that pushes teams toward [a self-hostable stack](/blog/self-hostable-data-stack-private-cloud-ai-data-agent) in the first place. For the procurement checklist: SOC 2 Type II is complete (trust.definite.app), we sign HIPAA BAAs, and for public sector work Definite deploys into your FedRAMP-authorized environment. That is what "full-stack self-hosted data platform" means in practice. Not a query engine you assemble a stack around. Not a BI tool pointed at a warehouse someone else operates. Every layer in the table, one deployment, inside your boundary. ## FAQ **What replaces Snowflake, BigQuery, or Databricks SQL in a self-hosted stack?** A lakehouse: DuckLake tables on an object store you own, queried by DuckDB. Analytical SQL ports with dialect changes. Stored procedures, tasks, and Spark jobs do not port, and petabyte-scale shuffle-heavy Spark work should stay on Spark. **Do dbt models carry over to Definite?** Mostly yes. dbt models are SELECT statements and port as SQL datasets, with dependencies between datasets standing in for the dbt DAG. Jinja macros get expanded into plain SQL, incremental materialization logic gets re-expressed, and tests get re-authored. **What happens to our Airflow DAGs?** Schedule-and-run DAGs (sync these sources, run these transforms, refresh these dashboards) map to scheduled syncs and Python pipelines. Deeply customized DAGs with custom operators, dynamic generation, or non-analytics jobs need rework or should stay in Airflow. Definite replaces analytics orchestration, not general-purpose workflow infrastructure. **Do Looker or Tableau dashboards migrate automatically?** No, and no vendor does this faithfully. Dashboards get rebuilt. The rebuild is fast because the metric definitions port to the semantic layer first, and Fi can assemble dashboards from those governed metrics on request. **Can the whole platform run air-gapped?** Yes. Definite deploys as a single Helm chart into your Kubernetes, and Fi calls a model endpoint you control, including self-hosted open weights. A fully disconnected deployment with zero required egress is supported. **What about SOC 2, HIPAA, and FedRAMP?** SOC 2 Type II is complete (see trust.definite.app) and Definite signs HIPAA BAAs. For public sector work, Definite deploys into your FedRAMP-authorized environment rather than claiming its own authorization. If you want this map drawn on your actual stack, the deployment architecture is on the [private deployment](/platform/private-deployment) page, or [watch the recorded walkthrough](/video). ]]> hello@definite.app (Mike Ritchie) https://definite.app/blog/startup-product-analytics https://definite.app/blog/startup-product-analytics Sun, 28 Jun 2026 00:00:00 GMT hello@definite.app (Definite Team) https://definite.app/blog/metabase-alternatives https://definite.app/blog/metabase-alternatives Thu, 25 Jun 2026 00:00:00 GMT hello@definite.app (Mike Ritchie) https://definite.app/blog/startup-customer-success-analytics https://definite.app/blog/startup-customer-success-analytics Wed, 24 Jun 2026 00:00:00 GMT 3, set to yellow" — and miss compound signals. A customer can be green on support and red on usage simultaneously. Some CS platforms now offer ML-based scoring, but even these are limited to the data the platform can see. The combination across systems is what predicts churn, and [45% of CSM-assigned health ratings contradict actual usage data](https://churnzero.com/blog/four-step-strategy-customer-health-score-program/). - **Identity.** Stripe knows a `cus`_ ID. Your CRM knows an account name. Intercom knows an email address. Your CS platform knows its own contact record. With no shared identifier across all four, "retention by segment" means a human matching records every month — and getting it wrong more often than they realize. - **Grain.** An Intercom conversation is not a Stripe subscription is not a PostHog event. Each system's rows represent different things. Combining them without aligning what each row means is how the same quarter produces three different churn numbers. One CS leader we spoke with put it plainly: he was tackling churn — the highest-priority initiative at the company — and his first problem was that he was blind. Not because the data didn't exist, but because it was spread across systems that couldn't show him the correct way to look at it. His CS platform showed him day-to-day interactions. What he needed was cohort retention over time — logo, ARR gross, ARR net — and no single tool in his stack could produce it. The practitioner skepticism about this is widespread. A [ChurnZero study of 800 CS leaders](https://churnzero.com/guides/customer-revenue-study-2025/) found that 73% say their current health score doesn't reliably predict churn. Michael Goetz, a CS leader at Drata, put it more bluntly: health scores are horoscopes — vague enough to feel true, specific enough to be useless for actually predicting what happens next. He's not wrong about rules-based scoring from a single source. A health score built from cross-system data is a different instrument entirely. ## Step 1: Start from the retention decisions, not the data The oldest useful idea in measurement says you never start with available data — you start with the questions someone is actually going to ask. For a CS leader at a startup, those are: 1. **Which accounts are at risk of churning this quarter?** The save-or-lose decision that drives every Monday's priority list. 2. **Which accounts are ready to expand?** The growth signal your renewal pipeline depends on. 3. **What's our NRR, and is it trending up or down?** The number the board asks about. The one you need to calculate the same way every time. 4. **Why did we lose the accounts we lost last quarter?** The post-mortem that makes next quarter different. 5. **What should we present at the next QBR?** The account-level story that keeps the customer engaged — backed by data, not by a CSM's gut feeling about how the relationship is going. Notice what these questions have in common: none of them can be answered by a single data source. "At-risk accounts" requires billing + usage + support signals. "NRR by cohort" requires billing data matched to CRM segments. "Why did we lose them" requires connecting the cancellation event in Stripe to the support history in Intercom to the usage drop-off in PostHog. And before any of these questions can be answered reliably, there's a harder question underneath: *what counts as a customer?* One executive at a company building their retention analytics framed it this way — is a churned customer someone who stopped paying for one month, or two months? Is a new customer measured from contract signature or first login? If CS, finance, and the board each answer these differently, every retention number is a disagreement waiting to happen. The metric dictionary in Step 3 solves this, but only if you've decided what you need to measure first. ## Step 2: Build a health score from all four sources The technique that makes CS analytics work at a startup isn't a better algorithm — it's connecting data from four systems that each see part of the picture. Here's what each source reveals that the others can't: | Source | Signal type | What it reveals | Weight | | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------- | | **Billing** ([Stripe](/connector/stripe), Chargebee) | Payment failures, downgrades, contract end dates, MRR trend | Revenue risk — the most concrete lagging indicator of churn | Highest | | **Product usage** ([PostHog](/connector/posthog)) | Login frequency, feature depth, session duration, adoption milestones | Engagement risk — often the strongest *leading* indicator, visible weeks before the customer says anything | High | | **Support** ([Intercom](/connector/intercom), [Zendesk](/connector/zendesk-support)) | Ticket volume, sentiment shift, escalation patterns, resolution time | Satisfaction risk — qualitative signal that's hard to quantify alone | Medium | | **CRM** ([HubSpot](/connector/hubspot), Salesforce) | CSM last touch, champion changes, stakeholder departures, renewal date | Relationship risk — context no automated system captures | Context |  A customer whose billing is healthy, usage is steady, support tickets are low, and CSM relationship is active is almost certainly safe. A customer whose usage dropped 40% six weeks ago, who just had a payment failure, and whose champion left the company? That's churn forming — and your CS platform, seeing only the support signal (which looks fine), keeps them green. The CS leader who was building these cohort retention tables found the same thing: his CS platform worked for day-to-day interactions — tasks, playbooks, quick account checks — but for the lagging KPIs that the company and investors actually cared about, he needed a separate analytical layer that could see across all his data sources. It's the "day-to-day vs. lagging KPIs" distinction that most CS analytics guides skip entirely: your CS platform and your analytical layer do different jobs, and trying to make one do both is where the picture breaks. ## Step 3: Write the metric dictionary Every CS metric needs a single definition that CS, finance, and the board agree on. Without it, the most common failure mode is silent: your NRR number doesn't match the finance team's because you're counting churned customers differently, and nobody notices until a board meeting. The dictionary fixes this. | Metric | Formula | Cut by | Source | Owner | | --------------------------------- | ------------------------------------------------------------------ | --------------------- | ----------------- | ----------------- | | **Logo retention** | (Customers at start − churned) / customers at start | Segment, cohort, CSM | CRM + Billing | CS lead | | **Gross revenue retention (GRR)** | (Starting MRR − contraction − churn) / starting MRR | Segment, cohort | Billing | CS lead | | **Net revenue retention (NRR)** | (Starting MRR − contraction − churn + expansion) / starting MRR | Segment, cohort, plan | Billing + CRM | CS lead / Finance | | **Health score** | Composite: billing (40%) + usage (30%) + support (20%) + CRM (10%) | Account, segment | All four sources | CS lead | | **Time to value** | Days from contract start to first activation milestone | Plan, segment | Product + Billing | CS lead | | **Expansion rate** | % of accounts with ARR increase in period | Segment, plan, CSM | Billing + CRM | CS lead | | **CSM coverage** | Active accounts / CSM headcount | Segment | CRM | CS lead | The "Cut by" column is what separates a useful metric from a vanity number. NRR as a single company-wide figure is a board slide — and a [10-point NRR improvement translates to 20-30% valuation uplift](https://www.feinternational.com/blog/net-revenue-retention-saas-valuation/), which makes getting this number right directly tied to your exit value. NRR by cohort vintage — showing whether each quarterly cohort retains better or worse than the one before — is the decision tool. NRR by segment shows whether your mid-market customers retain differently from your SMB customers, and whether your pricing tiers align with retention patterns. The definitional question underneath the dictionary is harder than it looks. "What is a customer?" sounds simple until you realize Stripe has one answer (an entity with an active subscription), your CRM has another (an account with a signed contract), and your CS platform has a third (a contact who's been assigned a CSM). If a customer pauses their subscription for one month, did they churn? If they downgrade from annual to monthly, did they churn? The dictionary is where you write these answers down once — and the [semantic layer](/blog/semantic-layer-in-data-warehousing) is where you enforce them across every dashboard and query. ## Step 4: Map your sources and make them agree With definitions written, map each metric to the specific data source that can answer it and the join key that connects it to the others: | Question | Source | Join key | Gotcha | | ------------------------------ | ---------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------ | | Revenue churn this month? | Stripe subscriptions | `customer_id` → CRM account | Stripe subscription events vs. invoice events give different churn dates | | Which accounts dropped usage? | PostHog events | User email → CRM contact → account | Anonymous sessions inflate usage numbers if not filtered | | Support sentiment trending? | Intercom conversations | Contact email → CRM contact | Conversation volume ≠ severity — one escalation matters more than ten low-priority tickets | | Renewal pipeline this quarter? | CRM opportunities | Account ID | Only useful if renewal dates are maintained — most CRMs have stale ones | | NRR by cohort? | Stripe + CRM | `customer_id` → account → segment | Requires segment to be stable — a customer reclassified mid-period breaks the cohort | The real work is in the join keys. Stripe's `customer_id` is opaque. PostHog tracks by user email or anonymous ID. Intercom tracks by contact. HubSpot tracks by company. Making "revenue by account" work across these systems means establishing an identity resolution layer — matching records across systems to a single account identity. For most startups, this is the wall. One founder building analytics for their CS team described the experience: enabling tooling for customer success meant that a non-technical user needed to get insights from Postgres tables. That's the wrong abstraction — the CS team shouldn't need to know what a Postgres table is. The fix is a [semantic layer](/blog/semantic-layer-in-data-warehousing) that renames database columns to business terms ("`stripe_mrr`" becomes "Monthly Recurring Revenue"), resolves join keys automatically, and lets the CS team ask questions in their own vocabulary. The technical mapping between Stripe's `cus_` ID and the CRM's account name happens underneath, invisible to the person asking the question. ## Step 5: Build the dashboard last — distribute alerts where CSMs work The dashboard is the least important part of this system. Not because it's unnecessary — a [retention dashboard](/dashboards/retention) is genuinely useful for trend analysis and board reporting — but because CSMs don't work in dashboards. They work in Slack, email, their CS platform, and the CRM. If your retention analytics only exist in a BI tool that a CSM opens once a week, you've built a reporting system, not an early warning system. Distribution is the unlock: | What | Where | Frequency | | -------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------- | | Account moved from green to yellow/red | Slack channel #cs-alerts | Real-time | | Payment failure on an account | Slack DM to assigned CSM | Real-time | | Weekly book-of-business summary | Email to each CSM | Monday morning | | Account-level health score changes | Pushed to HubSpot/Salesforce | Daily sync | | Cohort retention trends | [Churn dashboard](/dashboards/churn), [Retention dashboard](/dashboards/retention) | CS lead reviews weekly | | Board-grade NRR + churn analysis | [Customer success dashboard](/dashboards/customer-success) | Quarterly | The dashboard pages — [churn](/dashboards/churn), [retention](/dashboards/retention), and [customer success](/dashboards/customer-success), each with source-specific views — exist for two audiences: the CS lead who reviews trends weekly, and the board who wants a quarterly retention picture. For everyone else — the CSMs doing the actual account work — the value is in the alerts and summaries that show up where they already are. ## Step 6: Weekly review cadence The system above produces data. Cadence turns data into decisions. | Cadence | What | Who | Action | | ------------- | ------------------------------------------------------------------------------------------------ | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | **Weekly** | Account-level health score changes — new at-risk accounts, accounts recovered, expansion signals | CS lead + CSMs | Prioritize outreach, assign saves, queue expansion conversations | | **Monthly** | Cohort retention analysis — logo, GRR, NRR by cohort vintage | CS lead | Identify trends: are newer cohorts retaining better? Is a specific segment churning faster? Adjust onboarding or pricing. | | **Quarterly** | Full retention review — NRR trend, churn reasons (categorized), expansion pipeline, QBR prep | CS lead + exec team | Board-grade reporting. Churn post-mortem: tag every lost account with a primary reason, look for patterns. Feed the renewal pipeline forecast. | The weekly review is the working view — it should take 30 minutes, not a morning. The monthly cohort analysis is where the real insight lives: a cohort retention table that shows logo, ARR gross, and ARR net by quarterly cohort, going back at least four quarters. If Q1 2025 cohort retains at 95% after twelve months but Q3 2025 cohort retains at 85% after six months, something changed in the product, the onboarding, or the customer mix — and you can see it before it hits the company-wide NRR number. The quarterly review is what you bring to the board and what you prepare for QBRs. It answers: "How is retention, and why?" Not with a single NRR number, but with the decomposition underneath it — which segments, which cohorts, which specific accounts drove the change. ## AI retention analytics: the startup version is a different problem Search "AI churn prediction" and everything you'll find assumes enterprise scale — thousands or millions of accounts, ML models trained on historical patterns, propensity-to-churn scores. That's real and useful if you're a telco with ten million subscribers. But full ML churn prediction requires more data than most early-stage startups have — logistic regression can work on smaller datasets, but gradient-boost models need hundreds of churn events to train reliably. And frankly, at 200 accounts, you know most of them by name. The startup version of AI retention analytics is simpler and more useful: AI as the analyst who connects your four data sources and surfaces the patterns you'd catch yourself if you had time to look. That means natural language queries: "Which accounts dropped usage by more than 30% this month and have a renewal in the next 90 days?" — a question that requires joining PostHog usage data to Stripe subscription data to CRM renewal dates. Without AI, that's a data request to engineering. With AI that understands your metric dictionary and source mapping, it's a question you ask on Monday morning. It means anomaly detection: flagging when billing, usage, and support signals diverge for the same account — payment is current but usage flatlined, or usage is strong but support tickets spiked. These compound patterns are what rules-based health scores miss, and they're exactly what a model pointed at cross-system data catches. But the condition that enterprise AI content never has to spell out: **AI is only as reliable as the definitions underneath it.** Pointed at four systems that disagree on what a customer is, AI confidently produces wrong numbers faster. Pointed at a metric dictionary over joined data, it does the work of the analyst you never hired. Steps 1–4 of this guide are, concretely, how you make AI retention analytics trustworthy. ## Doing this with Definite Definite is the system above, packaged. You get [500+ connectors](/connector-db) — [Stripe](/connector/stripe), [Intercom](/connector/intercom), [Zendesk](/connector/zendesk-support), [HubSpot](/connector/hubspot), [PostHog](/connector/posthog), and [every major CS data source](/connector-db) — with storage and modeling included. Your metric dictionary is implemented as governed definitions: NRR, health score, and churn calculated the same way in every dashboard, every query, every alert. [Fi](/fi), the AI analyst, answers CS questions in plain English — from those definitions, with inspectable SQL underneath. Alerts push to Slack when a health score changes. Weekly summaries go to email. The [churn](/dashboards/churn), [retention](/dashboards/retention), and [customer success](/dashboards/customer-success) dashboards give you the cohort retention views the board asks about. And Definite sits beside your CS platform — your CS tool handles day-to-day playbooks and tasks, Definite handles the analytical layer that connects everything. Pricing is one flat platform fee — $250/month, unlimited users ([pricing](/pricing)). If you'd rather assemble it yourself: a warehouse, an ingestion tool, a modeling layer, a BI tool, and the time to make them agree. The framework in this guide works either way. One of them is a weekend. → More on the CS setup specifically: [Definite for Customer Success teams](/for/customer-success). ## FAQ **What's the difference between logo retention and net revenue retention?** Logo retention is the percentage of customers you kept — it treats every customer equally. NRR weights by revenue and includes expansion: you can lose customers and still grow NRR if the remaining ones expand. You need both. Logo shows the breadth of your retention problem; NRR shows the revenue impact. A company with 90% logo retention and 120% NRR is losing small accounts and growing large ones — that's a very different situation from 90% logo and 95% NRR. **How do I build a health score that actually predicts churn?** Connect four data sources — billing ([Stripe](/connector/stripe)), product usage ([PostHog](/connector/posthog)), support ([Intercom](/connector/intercom) or [Zendesk](/connector/zendesk-support)), and CRM ([HubSpot](/connector/hubspot)). Weight billing signals heaviest: payment failures and downgrade requests are the strongest churn predictors. Rules-based scores from a single source miss compound signals — a customer can look healthy in your CS platform while their billing and usage tell a different story. **Do I need a data team for customer retention analytics?** No. An all-in-one data platform like [Definite](/signup) connects sources and defines metrics without SQL or data engineering. The framework in this guide can be set up in a weekend — connect your data sources, define your metrics once, and start getting answers. The assembled warehouse-and-pipelines approach is what you build when you have a data team that wants to own infrastructure. **How is this different from what my CS platform already does?** CS platforms — Vitally, Gainsight, ChurnZero — handle day-to-day ops: playbooks, tasks, in-app health scoring from their own data. They're essential tools. But they see a partial picture: whatever data they ingest natively. An analytical layer connects *all* your data sources for the retention questions your CS platform can't answer: cross-system health scores, cohort retention analysis by vintage, board-grade NRR that matches what finance reports. Think of it as your CS platform for the operational layer, the analytical platform for the strategic layer. **What metrics should a VP of Customer Success track?** Start with the dictionary in Step 3: NRR, logo retention, GRR, health score, expansion rate, time to value, and CSM coverage. NRR is what the board cares about. Logo retention is what tells you how many customers you're actually keeping. Health score is what lets you act before churn happens. The dictionary defines each with formulas and the dimensions you should cut them by — by segment, by cohort, by CSM — so the numbers tell you *where* to focus, not just *whether* things are good. --- If you're looking at the metrics themselves — what to track and how to report to the board — see our [investor reporting guide](/blog/investor-reporting-startup-metrics). For the financial layer of this system, see the [startup finance analytics guide](/blog/startup-finance-analytics). For the revenue pipeline that feeds retention, see the [RevOps analytics guide](/blog/startup-revops-analytics) and the [marketing analytics guide](/blog/startup-marketing-analytics). For the dashboard structure that holds all of it, see the [executive dashboard guide](/blog/startup-executive-dashboards). The framework is the starting point. **[Start building yours →](/signup)**]]> hello@definite.app (Definite Team) https://definite.app/blog/metabase-ai https://definite.app/blog/metabase-ai Mon, 22 Jun 2026 00:00:00 GMT hello@definite.app (Definite Team)