A lead scoring model is a mathematical system. Put garbage in, get confident wrong answers out.
This is the part of lead scoring that most implementations skip. The MQL threshold gets set, the behavioral signals get weighted, the workflows get configured — and nobody audits the data the model is scoring against. Three months later, a contact who works at a university on a free Gmail account has a score of 85. A VP of Operations at a target account has a score of 12 because half her engagement history is split across a duplicate record.
The model looks broken. It is not. The data is broken. And fixing the model without fixing the data produces a faster path to the same wrong answers.
The dangerous thing about bad data inputs is that a scoring model does not know it is working with bad data. It scores what it can see. A contact with a personal email domain and a generic "Manager" title at a 10-person company can accumulate behavioral points for visiting five pages and downloading two assets. The model sees engagement and produces a score. The score triggers an MQL. Sales calls the number and gets a student doing research.
Poor data inputs ruin lead scoring accuracy not by producing obviously wrong results, but by producing plausible-looking results that are wrong in ways that are hard to trace. The score looks reasonable. The workflow fired correctly. Only the sales call reveals the problem.
By the time sales has rejected a dozen of these, they have stopped trusting the queue entirely. The model did not fail. The inputs failed. But the model takes the blame.
1. Missing or inconsistent job titles. Firmographic scoring depends on title matching. If your forms capture free-text job titles and contacts enter "VP", "Vice President", "VP Ops", "VP of Operations", and "VP Operations" — your scoring rules treat these as five different values, most of which match nothing. Dropdown or mapped title fields at the point of capture are the only preventative solution.
2. Duplicate contact records. When a contact submits two forms under slightly different email addresses, HubSpot creates two records. The engagement history splits. Each record carries partial scores. The model never sees the full picture. CRM hygiene connects directly to scoring success because duplicate records are the most common cause of artificially suppressed scores on high-value contacts.
3. Personal email domains passing form validation. A Gmail or Yahoo address is not a disqualifying signal by itself — some buyers use personal addresses for business research. But without negative scoring on personal email domains, the model cannot distinguish a researcher at a Fortune 500 who uses Gmail from a student doing a class project. Negative scoring on personal domains, combined with firmographic fit criteria, is the standard correction.
4. Missing UTM parameters and source tracking. If Original Source and UTM data are not captured consistently at every form submission, the model cannot weight channel-specific engagement accurately, and attribution reporting cannot connect scoring to campaign performance. Validating scoring inputs with real buyer journeys requires complete source tracking at every capture point.
Behavioral data tells you what someone is doing. Firmographic data tells you who they are. Either one alone produces a model that scores the wrong people confidently.
A purely behavioral model surfaces anyone who engages with content — including students, competitors, and consultants doing research. A purely firmographic model scores contacts based on fit without any signal that they are actually considering a purchase. The contacts who should convert fastest are the ones who are both the right fit and actively exhibiting buying behavior.
Including both firmographic and behavioral data in a hybrid model is not a best practice recommendation. It is the architecture that produces the highest MQL-to-SQL conversion rates. Firmographic fit sets the ceiling: a contact outside your ICP cannot score above a qualifying floor regardless of behavior. Behavioral signals determine where within that range a contact sits. The combination surfaces the contacts worth calling.
A false positive is a contact who scores above the MQL threshold but is not actually sales-ready. False positives are the primary reason sales stops trusting the scoring queue.
Incomplete data creates false positives in two ways. First, when negative scoring rules cannot fire because the data they need is missing. A competitor domain gets a negative score only if the contact's company domain is captured and matches the exclusion list. If the domain field is blank, the rule cannot fire. Second, when positive behavioral scores accumulate on contacts who should be disqualified — because the disqualifying firmographic attribute was never captured.
The solution is a data completeness audit before model launch. For every scoring rule, ask: what contact property does this rule depend on? What percentage of contacts in your database have a value for that property? If a property that drives significant scoring weight has more than 20% null values, either fix the capture mechanism or restructure the rule to not depend on that property.
Before configuring a single scoring rule in HubSpot, TPG runs a data input audit covering four areas: form field standardization (consistent property types and dropdown values across all capture points), duplicate detection (rules and merge protocols at the time of record creation), source tracking validation (UTM parameter capture and Original Source population at every form), and data completeness scoring (identifying which properties have unacceptable null rates for the scoring rules that depend on them).
TPG ensures clean, reliable scoring data as the foundation of every scoring engagement. A scoring model built on clean data produces accurate, trustworthy scores. A model built on dirty data produces confident wrong answers — which is worse than no scoring at all.
If your scoring model is producing high MQL volume with poor sales acceptance rates, start with the data. Talk to TPG about a scoring data audit before rebuilding the model.