Checking data health…
How these figures are sourced
Revenue · AOV · churn · MRR are read from our database (recorded orders + subscriptions);
Purchase CVR · checkout completion come from PostHog. MRR subscriptions · Recovery rate
come from MySQL subscription_events (the active count prefers the Stripe-backed MRR figure, falling
back to lifecycle events only when MRR is unavailable). Database figures reflect what's been
recorded — they can read low (even $0) in local / non-production environments where the dev DB is
sparse, and may differ from the live-Stripe Sales card by webhook lag. Cross-check drift in
Reconciliation.
Revenue & Sales
Overlap Insights Stripe + PostHog + Meta + lifecycle
Revenue · last 30 days Stripe · daily gross
Conversion Funnel PostHog · events · proj 313971 · ◆ Vidalytics VSL
Attribution
Meta Ads Meta · spend & ROAS
Acquisition
Global visitor & purchase locations PostHog visitors × Stripe purchases
Subscriptions
Rebills Stripe · renewals · /v1/invoices
First-renewal rate Stripe · cycle 2 · first renewal
Rebills calendar Stripe · daily renewals · this month
Recovery Database · subscription_events
Churn Database · subscription_events
Retention & LTV Database · subscription_events
Email performance GoHighLevel · email · deliverability
Data quality
Reconciliation Stripe canonical ↔ DB · GHL · PostHog · Meta
Data sources & timezones UTC canonical
All windows are computed in Pacific (America/Los_Angeles). Current window: —
| Source | Native timezone | Window translation | Alignment |
|---|---|---|---|
| PostHog · funnel | project: America/Chicago | toDateTime('…Z') → UTC (verified) | ✓ UTC |
| Stripe · sales / payments | UTC (unix epoch) | created[gte/lt] = unix seconds | ✓ UTC |
| MySQL · orders / subscriptions | UTC (app writes UTC Dates) | window instants vs occurred_at | ✓ UTC |
| GoHighLevel · reconciliation | location timezone | opps by createdAt (ISO / UTC) | ✓ UTC |
| Vidalytics · VSL retention | account tz · day granularity | dateFrom/dateTo = UTC date | ~ ±1 day |
| Meta · reconciliation | ad-account tz (reporting) | unix start/end_time | ~ acct-tz |
Every source receives the same UTC instant range; each translates it to its own format. The two ~ rows are day- or account-tz-attributed and can differ by up to a day at window edges — treat them as approximate, not instant-precise. (The standalone /sales chat command uses America/Chicago day boundaries and is intentionally separate from this dashboard.)
Tracking
Front-end tracking setup First-party · script install
Identity event graph Database · identity_events
Live feed
client.js event feed Realtime · identity_events
Replays
Session replays First-party · session recorder
Heatmaps
Page heatmaps Derived · from replay recordings
Funnels
Funnel reports Database · mirrors · person-stitched
Connections