Predictive Lead Scoring That Works For Physical Product Brands

Predictive Lead Scoring That Works For Physical Product Brands

The DTC brand inherits a B2B playbook by accident. The marketing director took a HubSpot certification three years ago at a former job. The agency they hired runs lead scoring as a standard line item. The CRO recommends it because every CRO has heard "lead scoring" referenced enough times to assume it must be working somewhere. The brand sets up HubSpot's default lead scoring model, awards points for job title and company size on every email capture, and waits for the predicted conversions to arrive.

They do not arrive. The brand wonders why. The B2B scorecard is built for accounts that have job titles and company sizes. The DTC subscriber is a consumer. The job-title field is empty on 92 percent of records. The company-size field is empty on 96 percent of records. The model is scoring against features that do not exist for the population the model is being asked to score, and the predicted-likelihood-to-convert numbers are statistical noise rendered as decimals on a dashboard.

The Job Title Field That Does Not Exist In Your Database

The structural problem is that consumer behaviour does not look like B2B behaviour, and the features that predict B2B conversion are absent from a DTC database by design.

Klaviyo predictive docs sets the data-quality bar for predictive models in DTC bluntly: predictive analytics requires at least 500 customers with completed orders, 180 days of order history, and three purchases per qualifying customer to even build a useful CLV model. Read that requirement carefully. The vendor that lives inside the DTC tech stack is telling operators the prediction problem requires real behavioural data with three repeat purchases, not form-field demographics. The operators running HubSpot defaults on email captures and quiz takers are trying to solve the prediction problem with a thousandth of the signal Klaviyo says is required, and the predicted scores are delusional as a result.

HubSpot predictive scoring is HubSpot's own documentation of its predictive lead scoring, and the documentation is honest about what the model is built for. The features the model uses are skewed heavily toward firmographic and form-field data: company size, industry, job title, page views on B2B-style content, form completions. The skew is not an oversight. The model was built for the B2B sales motion HubSpot was designed to support. It works there. It does not work translated unmodified to a DTC subscriber base.

HubSpot scoring guide is HubSpot's lead-scoring instruction blog and is the B2B playbook the article is attacking. The playbook is well-written for the audience it was written for. The audience is B2B SaaS companies with sales teams running multi-week sales cycles against accounts with named buyers in defined roles. None of that translates to a Shopify-native consumer brand selling skincare or apparel or home goods to individuals making single-session, single-decision purchases that complete inside an hour.

Pedowitz HubSpot critique is the practitioner write-up of why HubSpot lead scoring breaks down even inside its native B2B context. The critique is useful for the article because it surfaces the failure modes that compound when the model is applied outside its native context: feature skew toward the easy-to-collect (form fields) and away from the predictive (behaviour), point allocations that drift over time as the team adds rules without removing them, and the absence of any feedback mechanism that ties the predicted score back to actual conversion outcomes.

The DTC translation makes every problem worse. The form-field data is mostly empty for consumer subscribers. The behavioural data, which is rich on a Shopify-native brand, is mostly ignored by the B2B model because the B2B model does not have features for session depth, product-view recency, or basket-build behaviour. The brand is paying for a scoring system that disregards the data it has and demands the data it does not have.

Octane AI analytics is the cleanest vendor framing of the alternative: zero-party data and quiz responses provide a stronger predictive signal for DTC brands than firmographic fields, because zero-party data captures intent at the moment it is offered rather than inferring it from job titles. The Octane framing matters because it names what the alternative looks like in practice: collect behavioural and stated-intent data, score on that data, ignore the firmographic fantasy.

The Buyer Probability Engine

The replacement is The Buyer Probability Engine. The principle is single-sentence simple: throw out the firmographic scorecard and train a gradient-boosted model on session depth, product-view recency, basket-build behaviour, and email engagement, scoring identified contacts only against the probability of first purchase within 30 days.

The Engine has three feature families. Behavioural depth captures sessions, time on site, PDP views, scroll depth on product pages, and add-to-cart events without checkout. Recency signals capture last visit date, last cart event date, last email-click date, last quiz completion date. Engagement signals capture email opens and clicks over a rolling 30-day window, SMS subscribe status, quiz completion with the response payload, and product-list page interaction.

The model is gradient boosting, typically XGBoost or LightGBM, trained against the 30-day-first-purchase label using the brand's own historical data. The training set requires at least six months of email-captured contacts with their downstream purchase outcomes. Below six months, the training set does not have enough conversion events to support a reliable model. Above six months, the model can be trained, validated on a holdout slice, and deployed against the active contact base.

The hard rule of the Engine is identified contacts only. No anonymous-traffic scoring. The temptation to score anonymous web traffic is real, because anonymous traffic is the largest share of total traffic and a "score" on anonymous traffic feels like it should produce leaner retargeting spend. The reality is that anonymous-traffic scoring inflates the model with noise, blows up the retargeting budget, and produces predictions on populations that cannot be acted on with any precision. The Engine refuses anonymous-traffic scoring and the brand stops paying for retargeting against signal that is not there.

I have walked operators through the Engine on enough Shopify Plus brands now that the failure mode is predictable. The team wants to score everything. The Engine refuses. Identified contacts only. Behavioural features only. The discipline is what makes the model precision-at-top-decile actually outperform the HubSpot scorecard, because the model is finally being asked to predict something it has the data to predict.

Phase 1: Feature Engineering On Shopify Event Data (Days 1-30)

The first 30 days are about pulling clean behavioural features out of the brand's own event data. No model yet. Just the feature pipeline.

Week 1: pull six months of Shopify event data plus the matching Klaviyo profile properties for every identified contact. Get them into a single table with one row per contact and time-series columns for sessions, page views, PDP views, add-to-cart events, email opens, email clicks, and order events. Stitch the events to the customer identity so anonymous-then-identified sessions get back-stitched to the contact's record.

Week 2: engineer the feature set. Behavioural depth features are calculated as rolling 30-day counts and rolling 7-day counts (sessions, page views, PDP views, scroll depth, add-to-cart events without checkout). Recency features are calculated as days-since-last-event for each event type. Engagement features are calculated as 30-day open rate, 30-day click rate, SMS subscribe flag, quiz completion flag with response payload one-hot encoded.

Week 3: define the prediction target. The label is 30-day-first-purchase: did this contact place a first order within 30 days of the feature snapshot date. The label has to be calculated against historical data with full lookback so the training set is honest. Build a labelled training set of at least 5,000 contacts with at least 200 positives. Below those minimums the model cannot be trained reliably.

Week 4: validate the feature pipeline. Pull 50 contacts at random, recalculate their features by hand from the source events, and compare to the pipeline output. Discrepancies are usually broken event-stream stitching or wrong feature definitions. Fix until 48 of 50 match. Below that the pipeline is not ready for the model and the next phase will produce noise.

Klaviyo CLV dashboard is the vendor doc for Historic and Predicted CLV and is useful for the Phase 1 feature taxonomy because the Klaviyo features map cleanly to the Engine's feature families. The Engine is not replacing Klaviyo's CLV dashboard. The Engine is replacing the HubSpot scorecard that sits on top of it, with a model that uses the Klaviyo behavioural features as inputs rather than ignoring them in favour of empty firmographic fields.

The deliverable at end of Phase 1 is a feature table and a labelled training set. No predictions yet. Just clean, validated data the model can be trained against.

Phase 2: Model Calibration And Deployment (Month 2-6)

Phase 2 is where the trained model replaces the HubSpot scorecard and the retargeting spend starts working harder.

Month 2: train the model. Run XGBoost or LightGBM with five-fold cross-validation on the labelled training set. Tune the hyperparameters against the validation set, not against the training set. Target precision-at-top-decile of 0.4 or better, meaning 40 percent of the model's top-decile predicted buyers actually convert within 30 days. Below 0.4, the feature set is too thin and you need to extend the lookback or add features. At or above 0.4, the model is ready to deploy.

Month 3: deploy the model behind a scoring service. Every identified contact gets re-scored daily against their current feature snapshot. The score is written back to the Klaviyo profile as a custom property. The retargeting audiences pull from the score property: the top-decile audience goes to high-budget retargeting; the second-decile goes to a lower-budget retargeting flow; the bottom-eight-deciles goes to organic email only and no paid retargeting at all. The reallocation is the immediate payoff.

Month 4: tune the email and SMS flow logic. The model score becomes a flow-trigger condition. The welcome flow's third email is now conditioned on the score: high-score contacts get a hard offer, mid-score contacts get a soft offer with social proof, low-score contacts get content-led nurture. The flow logic does not require new flows. The flow logic requires the existing flows to be re-conditioned on the model score instead of on RFM bucket or recency-only triggers.

Month 5: integrate quiz completion into the model as a strong feature. Octane AI case studies is the operator case-study library showing 42 percent quiz opt-in rates and the conversion lifts that follow. Quiz completion is the strongest behavioural signal a DTC brand collects, because quiz completion captures stated intent at the moment it is offered. Brands running the Engine with quiz responses as a feature see precision-at-top-decile climb meaningfully over brands running the Engine on browse-and-cart features alone.

Month 6: re-train and audit. The model decays as the brand's product mix and customer base shift. Re-train quarterly on the rolling six-month labelled set. Audit precision-at-top-decile against the prior quarter; if precision is dropping, the feature set needs work, not the model. Klaviyo CLV segmentation is the vendor doc for segmenting on predicted CLV and is useful for the Phase 2 deployment because the Klaviyo segments can act as the production audience layer for the model's outputs.

The team running the Engine is small. One growth or analytics lead owns the feature pipeline. One analyst trains and re-trains the model. The retention and acquisition leads each act on the score in their respective channels. Four named roles. One model. One score. Three retargeting tiers. That is the entire build.

The North Star: Precision At Top Decile, Not Gross Lead Count

The standard B2B lead-scoring KPI is gross-lead-count or marketing-qualified-lead volume, and both are the wrong metric for a DTC brand because both reward the wrong behaviour. Counting leads incentivises the team to lower the qualification bar, which fills the database with noise and degrades the predictive model further. The metric the Buyer Probability Engine drives against is precision-at-top-decile.

Precision-at-top-decile is the percentage of the model's top-decile predicted buyers who actually convert within 30 days. The metric is honest because it measures the model's predictive performance directly, against the action the brand actually takes (retargeting the top decile). Brands running the Engine well land precision-at-top-decile in the 0.4 to 0.6 band. Brands running HubSpot defaults land it below 0.1, which is statistical noise dressed up as a score.

The lift from running the Engine is concentrated in the retargeting budget. Brands that move from HubSpot defaults to the Engine typically see retargeting CAC drop materially, because the budget is no longer spent against contacts the model knows will not convert. The Engine cuts paid retargeting spend on cold leads, redirects it to high-probability buyers, and stops subsidising a B2B playbook that was never built for consumer goods.

You do not need a more expensive marketing automation platform. You need to stop running a B2B scorecard against a DTC subscriber base and start training a model on the behavioural data your brand already collects. The Buyer Probability Engine is the discipline that gets the brand from a scorecard producing noise to a model producing actionable retargeting tiers, and the only thing it requires is treating prediction as a data problem instead of a points-based template inherited from a different business model.

The brands I have watched run the Engine for two full quarters share a common pattern: their retargeting CAC drops, their welcome-flow conversion rate lifts, and their team stops paying attention to the HubSpot lead-score field that nobody trusted in the first place. The scorecard was always wrong for the population it was scoring. The Engine replaces it with a model trained on the data the brand actually has, and the predicted scores finally agree with the conversions the brand actually sees.