feat/mrr-d3
needs attentionviewing older commit742255e · incrementalpre-PRreviewed 2026-08-07 17:50 UTC1H · 4M · 5L · 6I- Purpose
- Add MRR D3 cross-reference PostHog analytics insights — product × org × plan breakdown using warehouse data rather than event aggregates, fixing a systematic undercount in the legacy base-plan-only dashboard.
- Goal
- Replace misleadingly-labeled 'MRR Total' tiles (base plan only, ~$65,900/day) with D3 insights that combine base + overage + subscription MRR from the warehouse; clean up permanently-empty tiles from events that were never emitted.
- Sub-goals
- D3.1 — mrr_by_product: total MRR per product (providers vs enterprise) from warehouse
- D3.2 — mrr_coverage_gap: highlight orgs missing from MRR snapshot
- D3.3 — payment_status breakdown: off-platform vs Stripe vs pending
- Cleanup — remove 4 permanently-empty insights + 1 disabled alert; re-label 5 base-plan insights as 'piso de plan (NO total real)'
- What
- This incremental commit (742255e7) is the cleanup phase: removes mrr_variable_usage, new_subscriptions, upgrades_downgrades insights (all events never observed), removes the disabled new_subscription alert, relabels mrr_total/mrr_by_plan/mrr_by_segment/churned_mrr/revenue_vs_target to clarify they show base-plan floor not total MRR, removes the 975k MXN goal line.
- Why
- The prior naming 'MRR Total (30d)' was actively misleading — it only captured the Stripe base-plan floor (~$65,900/day) and missed ~$93k of overage + subscription MRR. The D3 insights (added in fb7f6ffa) now show true total MRR; the old tiles needed re-labeling to prevent confusion. The empty tiles were dead weight that made the dashboard harder to read.
- Areas
- infra/posthog/alerts.tf+6−16infra/posthog/dashboards.tf+17−8infra/posthog/insights.tf+327−94
- Blast
- 3 files, +350/−118 lines. Pure PostHog IaC — no application code, no DB migrations, no API changes. Blast radius is dashboard appearance and alert configuration only.
Findings · 16
correctness3
Dashboard description still references removed 975k goal line
infra/posthog/dashboards.tf:156
The posthog_dashboard.revenue_mrr description still reads 'progress toward 975k MXN/month target' but the goal line was removed from the revenue_vs_target insight in this same cleanup. A reader following the dashboard description will look for a target line that no longer exists. Update the dashboard description to match the insight's new framing.
No dangling references — alert, dashboard layout, and depends_on chains are clean
infra/posthog/dashboards.tf
Confirmed: new_subscriptions, mrr_variable_usage, and upgrades_downgrades are fully removed from dashboard tiles, alerts, and depends_on chains. subscription_churned alert correctly references churned_mrr which is retained. Terraform plan should be clean.
Dashboard y-gap at row y=5 is cosmetic — PostHog auto-reflows in UI
infra/posthog/dashboards.tf:172
After removing new_subscriptions at x=0,y=5, the row has a 4-column blank on the left. PostHog auto-reflows tiles in the browser UI, so this is not a functional error — but the stored layout_json will show dead space if inspected directly.
security2
Approximate MXN revenue figures committed to version-controlled IaC
infra/posthog/insights.tf:1011
Rounded revenue estimates (~$65,900/día, ~$40k, ~$53k) are visible to anyone with repo read access. The figures are already displayed in PostHog to all dashboard viewers, so the exposure level doesn't increase — but hardcoding financial data in IaC is worth noting if repo access ever widens.
Removed new_subscription alert was disabled — no active monitoring regression
infra/posthog/alerts.tf
The alert had enabled=false and its event (revenue.subscription_started) was never observed. No live alerting path was lost. If the event is ever instrumented in production, the alert will need to be rebuilt from scratch rather than re-enabled.
conventions3
Tombstone prefix inconsistency: '# REMOVED' (alerts.tf) vs '# NOTE:' (insights.tf)
infra/posthog/alerts.tf:132
The established tombstone pattern in this file is '# NOTE:'. The removed alert uses '# REMOVED (MRR D3 cleanup, BAT-308):' while insights use '# NOTE: ... was REMOVED here'. Unify to '# NOTE:' throughout.
Missing Spanish accents in churned_mrr description (UI-rendered field)
infra/posthog/insights.tf:1484
'deberia' should be 'debería' and 'aqui' should be 'aquí'. These render visibly in the PostHog UI, so correctness matters more than in SQL comments.
Team member names in a UI-visible description field
infra/posthog/insights.tf:1523
revenue_vs_target description ends with 'per Diego/Javi'. No other description field in this file attributes decisions to named individuals. Move the attribution to an inline Terraform comment above the resource; keep the description self-contained.
tests2
CI runs terraform apply (dev) + plan (stg/prod) — adequate gate for this IaC-only change
.github/workflows/pr-checks.yml:259
The posthog-checks CI job detects changes under infra/posthog/ and runs terraform apply against dev, plus plan for stg and prod. Dangling resource references would cause a hard apply failure. No additional test scaffolding is needed for a pure remove/rename cleanup.
Tombstone event types still defined in events.ts — no test update required
The removed insights queried events (revenue.subscription_started, revenue.subscription_churned, revenue.plan_changed) that are still defined as event types in analytics code. No test files reference the now-removed insight queries, so nothing needs updating.
improvement6
Tombstone 'never emitted' may be inaccurate — check prod emission paths
infra/posthog/insights.tf:1047
The tombstones for mrr_variable_usage, new_subscriptions, and upgrades_downgrades say the events were 'never emitted'. If active code paths exist for revenue.usage_mrr_snapshot (mrr-sync §9), revenue.subscription_started, or revenue.plan_changed in production, the correct phrasing is 'zero events observed in PostHog (120d audit)' — not 'never emitted'. The distinction matters: if the instrumentation code fires but the events land silently with no insight, removing the insights doesn't decommission the emission. Verify whether the mrr-sync §9 Lambda is deployed and scheduled before merge; if it is, rephrase the tombstone and file a Linear issue to restore the insight once the event actually flows.
Two dead-space gaps in dashboard layout after tile removal
infra/posthog/dashboards.tf:173
Row y=5: removing new_subscriptions (x=0,w=4) leaves churned_mrr orphaned at x=4 with x=0..3 blank. Row y=15: removing upgrades_downgrades (x=0,w=6) leaves mrr_by_segment alone at x=6 with the entire left half empty. PostHog renders absolute coordinates so these show as dead space. Shift churned_mrr → x=0, mrr_by_segment → x=0 (or compact y-coordinates) to fill the gaps.
Hardcoded MXN revenue amounts in descriptions will become stale
infra/posthog/insights.tf:1011
mrr_total description cites '~$65,900/día', '~$40k' overage, '$53k' subs; mrr_by_plan and mrr_by_segment cite '~$66k'. These will mislead within months as the business grows. Either remove the specific figures (qualitative framing: 'flat base floor, see D3 for current totals') or append the audit date explicitly ('as of Aug-2026 audit: ~$65,900/día').
churned_mrr insight kept solely to anchor a permanently-disabled alert
infra/posthog/insights.tf
subscription_churned alert is disabled (BAT-286, inverted logic), churned_mrr has had no data since 2026-06-19 (5 total events), and the re-model has no tracked issue or timeline. Keeping a data-empty insight to anchor a disabled alert adds maintenance surface with no operational benefit. Open a Linear issue for the churn notification re-model, then remove both the alert and the insight in a follow-up.
Tombstone comments should be pruned post-merge
infra/posthog/insights.tf:1046
The three # NOTE: tombstones (mrr_variable_usage, new_subscriptions, upgrades_downgrades) are useful for the reviewer but become noise once the branch merges and the context lives in git history. Consider removing them post-merge or consolidating into a single block comment at the top of the Revenue section.
No Linear issue tracked for diagnosing why the three decommissioned event flows produced zero prod events
revenue.usage_mrr_snapshot (mrr-sync §9 Lambda), revenue.subscription_started, and revenue.plan_changed apparently produced zero PostHog events over 120 days. This may be a deployment/configuration gap. A Linear issue should diagnose why and decide whether to restore the insights once the events flow.