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.
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).
Five things this picture reveals:
- 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:Reconciling against the vendor’s own dashboard
Where to look in HubSpot: HubSpot does not natively expose this cross-platform 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:
Cross-connector reconciliation:
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.