Lantide Data
← Back to blog
Integrate with Lantide

Why Do You Still Need Lantide When Using PostHog?

PostHog excels at product events, funnels, and experiment significance. When local CRM or finance data should not move to the cloud, or you need reviewable SQL and a formal Report, use Lantide for local diagnosis.

If you use PostHog for product analytics, event collection, funnels, cohorts, and Experiments probably cover everyday monitoring. Its frequentist engine calculates Welch's t-test, p-values, and confidence intervals, and can enable sequential testing. Once external tables are in the Data Warehouse, they can also be joined in experiments or the SQL editor. See Frequentist statistics, Analyzing results, and Data Warehouse.

The next layer is where teams often get stuck: joining events with local CRM or finance tables that should not be synchronized to PostHog, or turning custom cleaning, metric definitions, and limitations into a rerunnable report that others can question. That is where Lantide works as a local diagnostic workstation.

When local diagnosis is useful

1. Sensitive business tables cannot enter the Data Warehouse

Suppose checkout_completed is rising in PostHog and you also want to know whether those users belong to a local CRM's enterprise discount tier. If privacy or compliance prevents syncing the CRM, teams often export a CSV and force the join in a spreadsheet. The problem is not that PostHog cannot JOIN; it is that the data should not move to the cloud.

2. Clean first, then test

The standard experiment UI is designed for predefined exposures and metrics. If you need to exclude test accounts, recalculate the denominator, join a local refunds table, and then run a proportion test or regression, the key question becomes whether another person can review the SQL and assumptions. HogQL / the SQL editor can write the query; Lantide keeps Plan approval, checkpoints, and Report limitations in one workflow.

3. A decision document is needed beyond a dashboard

A conclusion for a CFO or cross-functional meeting usually needs the decision question, definitions, evidence, limitations, and next steps, not just a screenshot. See A trustworthy AI analysis report.

How to combine PostHog and Lantide

Task Keep it in PostHog Bring it to Lantide
Instrumentation, funnels, standard experiments Yes Usually unnecessary
Cross-source queries over tables already in the warehouse Can finish there Usually no need to duplicate
Joining local or cloud-restricted business tables Constrained Local DuckDB join
A reviewable formal analysis contract Insight / Dashboard Plan, SQL evidence, Report

Cross-source SQL

Place exported PostHog events (CSV / Parquet) and the local CRM in the same workspace:

SELECT
    e.distinct_id,
    e.event,
    crm.annual_recurring_revenue,
    crm.custom_discount_tier
FROM "posthog_events.csv" e
INNER JOIN "enterprise_clients.csv" crm
    ON e.distinct_id = crm.user_guid
WHERE e.event = 'checkout_completed';

This is useful for ad hoc diagnostics and compliance-sensitive joins; it does not replace PostHog's continuous event collection. See Query Excel / CSV with SQL.

Running statistical tools

Lantide includes tools such as run_proportion_test, run_ttest, run_chi_square, and run_regression. The formal flow is: prepare a clean table with SQL → confirm parameters with ask_user → inject and execute the relevant run_* tool with activate_analysis. Planning does not run formal statistics. See USER_GUIDE §12.9.

Interpret results with sample size, effect size, multiple comparisons, and limitations in mind. PostHog also notes that multiple metrics increase the chance of at least one false positive and that multiple-comparison correction is not enabled by default. See Frequentist statistics.

Plan → Execute → Report

For an analysis likely to be questioned, define the denominator, event definition, and time window first. Execute only after approval, and link every number back to SQL evidence. See Why formal analysis starts with a Plan.

A practical three-step workflow

  1. Narrow the question in PostHog: use a funnel, cohort, or experiment to find the slice that needs deeper analysis. If the data is already in the Data Warehouse and policy allows it, finish there.
  2. Bring only the local join to Lantide: export the relevant events and join them with local CRM or finance tables; first run the CSV data quality checklist.
  3. Produce a reviewable report: confirm statistical parameters, run the test, document limitations, and use Source Run to rerun upstream work when needed.

Conclusion

PostHog is the primary radar for product events and experiments; Lantide handles local diagnostics beyond that radar when the result still needs to be reviewable. The combined value is not calculating the same p-value twice, but giving sensitive joins and formal definitions a place to be reviewed, rerun, and handed off.

Next steps

References