Validates HubSpot’s lifecycle truth against commerce reality. Spots ‘customer’ contacts who never actually placed an order.
At a glance
Validates HubSpot’s lifecycle truth against commerce reality. Each lifecycle-stage cohort is matched against commerce-platform first-order data to produce a true “stage-to-first-purchase” conversion rate. Surfaces “customer” lifecycle contacts who never actually placed a commerce order, and “SQL” contacts who became customers without a HubSpot deal record.
| What it counts | For each lifecycle stage cohort entering in the window, the % who placed a first commerce order within 180 days. Cohorts: subscriber, lead, MQL, SQL. Outcomes joined via email match against commerce.customer.first_order_date. |
| Numerator | Distinct contacts in cohort whose email matches a commerce customer with first_order_date >= cohort_entry_date. |
| Denominator | Distinct contacts who entered the cohort in the window (i.e., whose lifecyclestage transitioned to that stage in the period). |
| HubSpot Hub scope | All Hubs. Lifecycle stage is a contact property; the cross-channel join uses commerce-platform customer data. |
| Email-match scope | Exact email match. Sub-aliases are not matched unless explicitly normalised. |
| Cohort entry vs current state | Uses lifecyclestage_history to anchor cohort entry, not current state. A contact who progressed Subscriber→Lead→MQL is counted in each cohort at the time they entered it. |
| First-purchase window | 180 days from cohort entry. Configurable per portal. Long enough to capture mid-cycle B2B conversions and seasonal DTC purchases. |
| Self-serve checkout customers | Counted on the commerce side, regardless of whether they ever reached a HubSpot lifecycle stage. The “Customer-stage but never bought” gap is what makes this card high-signal. |
| Currency | n/a (rate). |
| Time window | 90D. The cohort-entry window; first-purchase window extends 180 days beyond. |
| Alert trigger | SQL→customer <30%. SQLs that never become commerce customers usually mean lifecycle backfill ran without commerce data, or contracts closed-won were not invoiced. |
| Roles | marketing, sales |
Calculation
Calculated automatically from your HubSpot data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A B2C-with-sales-assist DTC brand. The 90-day cohort entry window is 14 Jan 26 to 13 Apr 26; first-purchase window extends to 14 Sep 26 (180 days post-cohort).| Cohort entered | Contacts | Placed first order within 180D | Conversion |
|---|---|---|---|
| Subscriber | 8,400 | 1,260 | 15.0% |
| Lead | 3,200 | 870 | 27.2% |
| MQL | 1,140 | 480 | 42.1% |
| SQL | 380 | 162 | 42.6% |
| HubSpot lifecyclestage = Customer (status check) | 4,800 | 4,400 | 91.7% |
- 400 contacts are flagged “customer” in HubSpot but never placed a commerce order. That is 8.3% of the customer-stage cohort. Most-common cause: a workflow that backfilled customer-stage based on a Stripe-trial-conversion event without checking actual order history. Audit HS08 surfaces these contacts for cleanup.
- SQL→customer at 42.6% is healthy. Above the 30% alert threshold. SQL contacts represent contacts a sales rep tagged worth pursuing; nearly half become commerce customers within 180 days, indicating sales is qualifying correctly.
- Subscriber→customer at 15.0% is the top-of-funnel attrition picture. 85% of subscribers never buy. For DTC this is normal; the subscriber list is wide and shallow. For B2B SaaS the same number would indicate poor product-market-fit signal in the subscribe-pop-up.
- MQL→customer at 42.1% essentially matches SQL→customer at 42.6%. That suggests the SQL handoff is not adding value, sales is not improving conversion over what marketing already qualified. Review lead scoring and SDR criteria; an SQL that converts no better than an MQL is a bureaucratic stage rather than a real qualification gate.
- The 8.3% phantom customers ($1.6M+ historical revenue when scaled across the portal’s lifetime) is the cleanup priority. Each phantom customer occupies a Marketing-Hub seat (paying tier-pricing) and skews lifecycle-stage retention metrics. Audit HS08 fires on this scenario.
Sibling cards merchants should reference together
This card is the lifecycle truth-test. Pair with these:| Card | Why pair it with Lifecycle to First Purchase |
|---|---|
| Lifecycle Stage Distribution | The current-stock view. Useful denominator for lifetime retention rates. |
| Lead to MQL Conversion % | The within-HubSpot conversion rate. Compare against this card’s lead→customer rate to see where lifecycle inflation is happening. |
| SQL to Customer Conversion % | The within-HubSpot SQL→customer rate. Should approximate this card’s number; big gaps mean lifecyclestage is moving without commerce evidence. |
| Top Customers Without HubSpot Contact | The inverse: commerce customers who are not in HubSpot at all. Sales-team blind spot. |
| Pipeline-vs-Realised Revenue Gap | The B2B sister: closed-won deals without realised revenue. Both surface lifecycle inflation. |
| Email-Attributed Commerce Revenue | The marketing-side companion. High email-attribution with low Subscriber→customer rate suggests the wrong people are in your subscriber list. |
| Stripe MRR | For SaaS, MRR-paying customers are the truest “customer” definition. Compare against the customer-stage cohort. |
| Shopify Distinct Customers | For DTC, the realised customer count. The 91.7% match rate (or whatever your portal shows) is the data-quality measure. |
Reconciling against the vendor’s own dashboard
Where to look in HubSpot: HubSpot does not natively expose this cross-channel rate; it requires commerce data. Closest views:HubSpot → Reports → Analytics tools → Contacts analytics (Lifecycle Stage transition history) Shopify Admin → Customers / Stripe Dashboard → Customers (the commerce-side customer list)This card automates the email-match join between the two. Why our number may legitimately differ from the merchant’s expectation:
| Reason | Direction | Why |
|---|---|---|
| Email-mismatch | Conversion lower | A subscriber who later bought using a different email is not matched. Apply email-normalisation (lower-case, strip Gmail aliases) to improve match rate. |
| 180D first-purchase window | Conversion lower for long-cycle | Long-cycle B2B customers may purchase 8-12 months after MQL. Configurable to 365D. |
| Cohort-entry timing | Either | Lifecycle backfills compress many cohort entries into a single date; the Subscriber→customer rate may look inflated for that day’s cohort. |
| Lifecycle reset | Conversion lower | Some portals reset lifecyclestage to lead when a customer cancels and re-subscribes. The customer-cohort then drops; this card uses entry-event, so re-entries count. |
| Multi-portal customers | Either | A customer in two portals is counted once per portal. |
| Refunded orders | Conversion higher | First-order is counted regardless of subsequent refund. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
| Shopify Distinct Customers | The “Customer-stage” cohort with first_order should approximate Shopify customer count for connected stores | Self-serve customers never reach lifecycle, gap is reported in Top Customers Without HubSpot Contact. |
| Stripe Active Subscribers | The MRR-paying customer subset should match the Customer-stage with first_order | Trial customers may be at customer-stage in HubSpot before Stripe sees the first paid charge. |
Known limitations / merchant FAQs
Why does HubSpot show 4,800 customer-stage contacts but the commerce platform shows 4,400 distinct customers? The 400 difference is the “phantom customers” pattern. Most-common cause is a workflow that backfilledlifecyclestage = customer based on a HubSpot deal-closedwon event without verifying a corresponding commerce order. Less-common: a contact merge collapsed two contacts where only one had ever bought, or a CSV import set lifecyclestage manually for prospects in error. Audit HS08 surfaces the offenders by name.
My SQL→customer rate is 18%, what is wrong?
Three usual causes: (a) lifecycle-stage backfill ran without commerce data, contacts went straight from SQL to closed-lost without ever becoming customer, but were never demoted. The cohort-entry counts but the first_order never lands. (b) Sales is qualifying too loosely; SDRs accept anything as SQL to hit a quota. (c) Long sales cycle, the 180-day window is too short. For enterprise B2B with 9-12 month cycles, extend the first-purchase window to 365D.
Lifecycle-stage backfill, what is the lag and why does it matter here?
HubSpot processes lifecycle-stage changes on a workflow basis, typically within 5-15 minutes for event-driven transitions, but bulk backfills (CSV imports, list-based workflow-action) can take 4-24 hours to settle. Mid-backfill the cohort denominators shift, so a reading on backfill day looks volatile. Vortex IQ uses lifecyclestage_history snapshots taken at the cohort-entry timestamp, so post-backfill cohort sizes stabilise.
List-segment refresh lag, does it affect this?
Indirectly. If the workflow that promotes contacts uses list-membership as a trigger, list-refresh delay (typically 15-60 minutes for active lists, longer for static) propagates into cohort-entry timestamps. The 90D rolling window absorbs most of this; daily-resolution views may show artificial “spike days” on bulk-list-refresh.
Multi-portal aggregation, how does it work?
One card per portal. A contact in two portals (e.g. parent-portal plus sandbox, or pre/post-merger portals) counts in each independently. Cross-portal email-deduping is not supported because HubSpot’s contact-id is portal-scoped. Agencies running multi-portal architectures should pin the parent-portal as primary and treat the rest as supplementary.
HubSpot lifecyclestage = customer vs Stripe MRR-paying, who is right?
For revenue recognition, the commerce/billing platform is right. HubSpot lifecyclestage is a CRM operational state used to drive workflows; it can drift. This card uses commerce-platform first_order_date as the truth and lifecyclestage as the cohort-entry. When the two disagree, the commerce side wins.
What is a healthy SQL→customer rate?
B2B SaaS: 30-50%. B2C-with-sales-assist DTC: 25-40%. Pure self-serve (no sales touch on customers): the SQL stage should be empty or near-empty; if SQLs are appearing without any commerce conversion, the lead-scoring rules are broken. Below 30% triggers the alert and prompts a lead-scoring review.
Today-volatility, why does this swing?
Cohort-entry events fire when reps or workflows transition contacts; commerce first_order events fire when buyers complete checkout. A single SQL-cohort with 12 contacts entered today shows zero conversion until those contacts buy (180-day window). The 90D rolling cohort window smooths most volatility, but newly-entered cohorts always start at 0% conversion and climb over the 180D maturation window.
Action playbook on alert (SQL→customer <30%):
- Run Audit HS08 to list “lifecyclestage = customer with no first_order” contacts.
- For each, check whether they have a closed-won deal in HubSpot; if yes, this is the pipeline-vs-realised pattern (see that card).
- Review SDR qualification criteria over the last 90 days.
- If extending sales cycle, extend the first-purchase window to 365D and re-baseline.
- Add a workflow rule: do not auto-promote to customer-stage without a commerce-order webhook.