Two reports, one population, two different answers
- Client
- Braustin Homes
- Industry
- Manufactured housing retail
- Engagement
- Fractional RevOps, contract
- Duration
- Ongoing since December 2025
- Stack
- HubSpot Marketing and Sales Hub, CallRail, Meta Ads, Google Ads
What Braustin Homes was facing
Braustin sells manufactured and tiny homes across Texas, with an inside sales team fed by paid and organic social. Leadership wanted one number from reporting: what share of social leads turn into buyers. Two existing HubSpot reports answered that question differently, so the honest answer was that nobody knew.
The problem
The custom report builder said 81 contacts reached SQL. The journey funnel builder said 360. Same population, same window, same CRM. When two reports disagree by a factor of four, every number downstream becomes negotiable, and the conversation stops being about performance and starts being about whose report is right.
What I did
-
Reconciled the two reports before rebuilding either one
The custom report bucketed contacts by their current lifecycle stage, which makes the groups mutually exclusive. The journey builder counted stage entry events, so a contact who passed through SQL and moved on still counts at SQL. Neither report was broken. They were answering different questions and nobody had noticed. -
Found two further causes
The reports used different date anchors, create date against event timestamp, so a contact created in 2025 who became SQL in 2026 appeared in one report and vanished from the other. Separately, 128 contacts went from Lead straight to Opportunity and skipped SQL entirely, which a stage bucketed bar chart cannot represent at all. -
Redefined the metric as a cohort measure
Of all contacts created in a given month, what share ever reached Opportunity or beyond. Cumulative rather than current state, anchored on a single date, and unaffected by skipped stages. -
Built it with summary measures rather than a dataset
Aggregate math inside the custom report builder, with conditional blocks combined so that reaching Opportunity or beyond counts everyone who passed through rather than only those currently sitting there. Because summary measures respect the report dimension, each month returns its own denominator without a workaround. -
Delivered a monthly trend instead of a blended year to date
A single annual rate hides maturation bias. Monthly cohorts make it visible and arguable.
Results
-
81 vs 360
Two reports on the same population disagreed at SQL by a factor of four. Both are now explainable, and one is the published measure.
-
1.4% to 10.7%
The monthly conversion range hidden inside a single blended 3.76%. January and February carried 69% of the year's volume at the worst rates despite having the most time to mature, pointing to a Q1 lead quality event rather than a declining funnel.
-
77 minutes
Average time from SQL to Opportunity, evidence the stage was being stamped by automation rather than earned. Flagged as not reportable until the stage logic is fixed.
