Measurement plumbing and identity: joining data without lying

Before any dashboard can credit a channel, something in the stack has to decide that this ad click, this form fill and this closed deal all belong to the same buyer. That decision is the join, and when it is wrong the report comes out clean and confident and still wrong. Changing the attribution model does not save it. Understanding identity resolution in B2B means checking which identifiers connect the records, how reliable the match is and what decisions it can support.

Why your attribution breaks before it reports

RevSure, LayerFive and others have made the point for two years: attribution outputs are only as good as the data model beneath them. Identity itself rests on correct data at capture: source, consent, account, contact, timestamp and validation state recorded before the record reaches the CRM. That is data truth at the point of capture. A smarter attribution model cannot repair a record that was wrong on the way in.

An attribution model decides how to allocate credit. It cannot, by itself, establish whether a contact was assigned to the right account or whether an event belongs to that person. You cannot measure what you have not identified, or identify what you never validated when it arrived. Everything above the join inherits what happened at the join.

What you can join: first-party versus third-party identity

A join is only as good as the material it is made from, and first-party and third-party identity are not the same material.

First-party identity is what the buyer gives you directly and with consent: an email on a form, a logged-in session or an account ID already in your CRM. It is the part you can trust. It covers only part of the journey. Third-party identity comes from outside: firmographics, intent feeds, IP-to-company lookups, enrichment bought from a vendor. It reaches into the anonymous majority of the journey at lower confidence, and that confidence varies more than vendors admit.

Browser restrictions and user choices make cross-site tracking incomplete. Google retained Chrome’s existing approach to third-party cookie choice in April 2025; cookies have not universally disappeared.

RevSure’s cookieless guide lays out the replacement pattern: a first-party JavaScript pixel for on-site behaviour, server-side tracking to keep events flowing when the browser blocks client-side scripts, and configurable fingerprinting at graded precision where nothing better is available. None of those is a straight swap for the cookie. Each one buys coverage by giving up a little certainty, in its own way.

There is also a shift worth watching. The big platforms are starting to run their own B2B identity layers, with LinkedIn’s the clearest example so far (The B2B Stack, 16 May 2026). That pulls identity resolution further inside closed platforms you do not control, which is the strongest practical reason to own a first-party capture layer now rather than lease your identity from someone else’s graph later.

How confidently you can join it: join keys and matching methods

The source of an identifier and the method used to match it answer different questions. Blurring them produces overconfident numbers.

A join key is whatever two records have in common that lets you call them the same thing: an email, a company domain, a hashed identifier, an account ID. What separates the matching methods is how they use those keys. Deterministic matching uses an exact shared identifier and treats the result as certain. Probabilistic matching has no exact key, so it infers the match from patterns. The third method, the one most account-identification platforms actually run, is usually sold as “ML” but is better called ML-assisted graph matching, because it is not a clean category at all. It layers deterministic seeds, probabilistic inference, a graph of related identifiers and behavioural signals into a single confidence score. Underneath, it relies on deterministic anchors like the other methods. Calling it the “ML option” does not explain how those layers work together.

What you are really trading is confidence against coverage. The numbers below are ranges reported by Treasure Data, not laws; they shift with the data set, the traffic source, the region and how the match was validated. Use these distinctions to decide which matches may influence which decisions.

Bands reported by Treasure Data, 31 March 2026. Coverage is expressed as a share of records; the source gives no person-versus-account level or evaluation method for the bands. Treat them as ranges, and use them to govern what each class of match may influence, not to pick a vendor.

Each method fails in its own way. Deterministic matching misses anonymous and cross-device activity. Probabilistic matching produces confident matches that are simply wrong. ML-assisted graph matching is opaque enough that a bad merge is hard to spot. The rule that comes out of the table, generalising Treasure Data’s own, is short enough to keep: deterministic for action, probabilistic and ML-assisted for insight. Named, direct action requires a deterministic match whose provenance, consent and freshness checks pass. A probabilistic or ML-assisted match tells you something useful about the shape of demand and should not be the reason you do something irreversible to a named person.

It helps to see where two well-known tools sit, because they are not rivals. Segment lives in the customer-data-infrastructure layer, doing deterministic profile unification on first-party data you already hold. 6sense lives in the intent layer, running ML account identification and de-anonymisation against mostly anonymous third-party signals. Most B2B teams run both. The quick test for which is which: if the question is ‘who is this known customer, across the properties we own’, that is Segment’s job; if it is ‘which unknown accounts are in market right now’, that is 6sense’s. The backbone they both lean on is what Mike Harty calls the account knowledge graph (The B2B Stack), the structure that maps identifiers, office locations, hashed emails and platform IDs onto one account.

Checking whether fields agree is the cheapest sanity check available. A record claiming a buyer in a postcode where your business has never sold anything deserves a second look; a record from a postcode with three existing customers is more believable. The fields have to agree with each other, not just each be valid on its own.

Lawful basis is an attribution-eligibility rule

A record can be perfectly joinable and still off-limits for measurement.

Treasure Data’s action-versus-insight distinction matters because an automated system acting on a bad probabilistic merge does so at speed, with nobody checking. Consent provenance belongs in the join logic. A record whose lawful basis is missing, expired or granted for a different purpose is not eligible for measurement that acts on a person, however clean the match looks.

In practical data-governance terms, a wrong probabilistic merge can become inaccurate processing under GDPR Article 5(1)(d) once it is stored or acted on as fact. An overconfident join can therefore create a measurement error and a compliance problem together.

Treat consent provenance as a field the join reads, not a document filed away. LeadScale’s Engine holds ISO 27001 certification (18666) for the security side of that; the principle holds whether or not a given stack is certified.

Lossy joins: where the lying happens

Most attribution dishonesty is not fraud. It is leakage. Lossy joins are the failure modes that let identity fidelity bleed away between capture and report, and four of them do most of the damage.

Lead-to-account failure. The lead never lands on the right account, so account-level activity scatters across duplicates and the rollup over- or under-credits. Openprise’s worked example makes the mechanics obvious: matching six event leads to accounts on exact company name alone resolved two; standardising the names got it to three; matching on domain after standardisation resolved all six. Nothing there was a modelling breakthrough. It was cleaner data, with standardised names and a domain key.

Anonymous-visitor blind spots. A champion does their early research from home, or from behind a corporate VPN that hides the company domain, so the high-intent visits never attach to an account until a form fill weeks later. The stretch of the journey that mattered most is the stretch the join never saw, which throws you back on ML graph matching exactly where certainty is thinnest.

Probabilistic-join overconfidence. This is the quiet one. Vendors quote match rates north of ninety percent, but those are usually account-level numbers. Person-level identification in tests described by the vendor Prospeo comes in far lower, single digits into the low double digits against the same headline claims (Prospeo, 2026, separating person-level from account-level resolution). Feed an attribution model account-level matches as if they were person-level certainties and it will hand you precision the join cannot actually support.

Capture-to-reconciliation decay. Fidelity also drains in the gap between the moment a signal is captured on the site and the moment a CRM batch sync reconciles it. Records move, sessions expire, contact data rots. How fast is genuinely disputed, and the honest thing is to say so: Landbase’s compilation cites SMARTe’s estimate of about 22.5% annual B2B data decay and a Forbes Business Council article reporting up to 70.3% annual contact decay. Landbase says variation depends on data type, industry and how quickly organisations change. Some vendors cite a tighter 30-40% (Prospeo). That is at least a fifth a year, often a lot more. Set freshness thresholds against the bad end of the range, not the middle.

All four happen above the model’s head. You can swap attribution models all week and never touch any of them.

How to audit the identity join beneath your attribution

If you want to know whether your attribution is worth trusting, audit the join, not the dashboard. Run the checklist below against a sample of the records currently feeding your reports. Each line is a per-record test. A record that fails any fatal check (consent, identity, account, confidence or freshness) must not drive action-grade decisions. Whoever owns this in your shop is usually RevOps or marketing ops, with legal on consent and data on schema.

Count the records that fail any fatal check and divide by the sampled records. That proportion is roughly the share of measurement that is, at best, an estimate being reported as fact.

The honest measurement plumbing

Once the join holds up, the plumbing runs in two directions, and they are easy to mix up.

Feeding the bidding engines

The first direction is outward, to the ad platforms. Validated conversions can reach them through server-side event interfaces, including a Conversions API or a server-side Google Tag Manager configuration. In practice a raw form fill hits a server container, gets validated and scored, is suppressed or enriched, and only then goes to the ad-network endpoint as an event the platform can optimise against. The caveat matters more than the mechanism. A Conversions API and server-side GTM move events more reliably; they do not turn a weak join into a true one. Send a confidently mislabelled conversion faster and all you have done is teach the algorithm the wrong lesson at scale.

The reverse ETL pattern syncs warehouse data into operational tools. It can support conversion feedback and only delivers value if the join beneath it holds. Server-side event interfaces provide the collection and transmission route.

Mapping the buying journey

The second direction is inward, to the account. Account progression modelling tracks how a buying group’s activity builds across first- and third-party layers and how the account moves through stages, instead of pinning everything on one conversion. Identity failure hits the common methods in different ways. Multi-touch attribution turns actively misleading when the join is wrong, because it keeps assigning per-touch credit with total confidence. Marketing mix modelling is more sheltered, since it works on aggregates, though a corrupted identity layer still dirties the digital signals it ingests. Incrementality testing is the causal check that does not need to resolve the individual at all.

A stack running more than one of these is much harder to fool than one leaning on a single model.

Measurement inherits what happened at capture

The consequence of unvalidated capture appears at the join and measurement layer; the cause sits upstream, at capture. Skipping validation means every downstream model inherits the same false record. Provenance, consent, confidence scores, decay dates and suppression rules must be enforced before a record contributes to a measurement.

Data accuracy at capture and ongoing CRM maintenance give the join reliable inputs. Data orchestration can sequence the jobs but cannot validate them. Together these controls make the revenue figures used in return on ad spend (ROAS) more defensible.

For checks applied at capture, explore the LeadScale Engine. The same discipline remains necessary when records are matched or refreshed later.