How to Resolve Multiple Signals From the Same Person or Company
One person can visit, reply, and submit a form; several people at one company can do the same. More events do not automatically mean more leads or stronger intent. This framework preserves raw evidence, resolves identity carefully, and groups related events into actionable signal episodes.
DEFINITION
What is this about?
Resolve multiple B2B signals by preserving every raw event, deduplicating technical repeats, linking people and companies with explicit confidence, and grouping events that concern the same decision into a dated signal episode. Within that episode, identify corroboration, new information, contradiction, and stop conditions. Choose the strongest supported next action; do not add event counts into a probability or create duplicate leads.
KEY TAKEAWAYS
- Raw events, identities, decision episodes, leads, and accounts are different objects.
- Deduplication removes technical repetition; it must not erase legitimate separate actions.
- Several weak events do not automatically become one strong intent conclusion.
- Contradictory signals remain visible and can override a convenient narrative.
- One company can have several concurrent decision episodes with different people, applications, and states.
Who this framework is for
This framework is for teams reconciling email-link visits, direct replies, forms, repeat activity, referrals, and company-level events across an outreach program. It is especially useful where narrow account lists make accidental double counting materially distort pipeline reporting.
Contents
1 Model events, entities, and episodes separately 2 Resolve identity without forcing certainty 3 Apply the SellersGPT THREAD Resolution Framework 4 Derive one current action from many events 5 Preserve provenance, corrections, and expiry 6 Illustrative example 7 Common mistakes 8 What this does not mean 9 Common questions 10 Sources and methodology
1. Model events, entities, and episodes separately
An event is a recorded occurrence: page request, email reply, form submission, unsubscribe, bounce, or manual verification. A person and company are entities to which evidence may be linked. A decision episode is a bounded set of events concerning one problem, application, purchase situation, and time window. A lead is an operational state created under a defined policy. Do not collapse these objects. One event can link to multiple possible people. One person can have two unrelated decision episodes. Ten events can update one lead. One company can contain an active replacement project and an unrelated distributor inquiry at the same time. Google Analytics treats events as measured interactions and allows event parameters to describe them. Google Analytics - Events That measurement model is useful for raw capture, but a website event does not itself define a sales episode or commercial state. HTTP also establishes request semantics, not business identity or intent. IETF - RFC 9110, HTTP Semantics A repeat request may be a new visit, refresh, retry, scanner, or forward. Resolve it using evidence, not count alone.
2. Resolve identity without forcing certainty
Link evidence in layers: Link Stronger evidence State Event to technical session Stable session or server correlation fields Known / Inferred / Unknown / Conflicted Event to campaign context Unique token and delivery record Known / Inferred / Unknown / Conflicted Event to person Authenticated context, person-confirmed identity, verified mailbox, or reliable unique linkage Verified / Supported / Claimed / Unknown / Conflicted Person to company Current first-party profile, company domain plus corroboration, or authorized record Verified / Supported / Unknown / Conflicted Event to decision episode Same application, request, actors, and credible time relationship Known / Inferred / Unknown / Conflicted An email domain is not always a legal entity. A corporate network can represent many people. A unique link may be forwarded. A role mailbox may have several operators. Preserve the weakest unresolved link. Use deterministic match evidence before fuzzy similarity. When two records share a name but have different companies, do not merge them. When two forms share a company but describe different applications, do not force them into one episode.
3. Apply the SellersGPT THREAD Resolution Framework
The THREAD Resolution Framework is an original SellersGPT editorial tool.
• T - Timestamp and raw trace: retain occurrence time, received time, source ID, and processing time.
• H - Human and traffic integrity: separate person action from scanner, bot, delivery, and administrative events.
• R - Resolve entity links: attach explicit confidence and preserve competing identities.
• E - Episode scope: define account/site, application, purchase situation, and time boundary.
• A - Assess relationship among events: duplicate, corroborating, additive, contradictory, independent, or stop.
• D - Derive the current action: update research, lead, qualification, owner, suppression, or stop state under a versioned rule. The event relationship is more useful than an additive score: Relationship Meaning Treatment Duplicate Same underlying occurrence recorded more than once Preserve raw records; count once operationally Corroborating Independent event supports the same fact Raise evidence confidence for that fact only Additive Event supplies a new relevant fact Update the episode record Contradictory Credible event conflicts with a current conclusion Mark conflict; resolve before high-impact action Independent Different problem, application, or decision Create or update a separate episode Stop Event creates suppression, disqualification, or termination Apply scope-specific stop before prioritization Three page visits are not necessarily corroboration because they may share one scanner cause. A reply that explicitly names the application can independently support the episode link. A form that provides a different company can create a conflict rather than another “intent point.”
4. Derive one current action from many events
Process in order: 1 Apply stop, existing-customer, suppression, and invalid-event rules. 2 Deduplicate events that represent the same underlying action. 3 Resolve identity and episode scope. 4 Select the strongest explicit request or obligation. 5 Run the current fit and qualification gates. 6 Assign one owner per next action and preserve separate specialist tasks. 7 Set a review or expiry date. If the same person visits and then replies, the reply can clarify the visit. It does not mean two leads exist. If two people at one company submit different forms about the same project, link both people to the episode and maintain their separate roles and requests. Do not let volume override quality. A company with twelve anonymous visits and no verified identity can remain an account-research signal. A company with one verified form asking for a dated quote may deserve immediate action. Priority depends on evidence and obligation, not raw count.
5. Preserve provenance, corrections, and expiry
The W3C PROV overview describes provenance as information about entities, activities, and people involved in producing data or things. W3C - PROV Overview Pipeline records benefit from the same discipline: keep the source, transformation, actor or rule, and revision trail. NIST's log-management guidance covers the need to establish processes for generating, transmitting, storing, analyzing, and disposing of log data. NIST SP 800-92 - Guide to Computer Security Log Management A GTM event ledger is not a security log, but the bounded practices of timestamp integrity, access control, review, and retention are relevant. NIST's Information Quality Standards emphasize utility, objectivity, and integrity for information it disseminates. NIST - Information Quality Standards SellersGPT does not claim those standards govern private CRM data; it applies the general editorial discipline of documenting sources, limitations, and corrections. Derived states should be revisable. Raw events should be protected against casual alteration. A merge needs reversible links, not destructive deletion. Expire behavioral inferences sooner than verified company facts, and refresh identity, role, employment, and project timing according to their volatility.
6. Illustrative example
Illustrative example. The company, people, events, and calculations below are fictional. They are not a SellersGPT customer result or forecast. Fictional Arcway Pumps records nine events for Beacon Foods: Raw events Resolution Episode treatment Three requests within 8 seconds from a security network One scanner cluster Exclude from human activity One campaign-link visit after 6 hours Supported human event linked to Dana's campaign context Create lead under active rule Dana replies “Maintenance needs the washdown curve” Explicit request and application Add to replacement episode Dana submits the form twice within 40 seconds One submission plus technical duplicate Count one request Lee submits a distributor form Different relationship and purpose Separate channel episode Dana unsubscribes Person stop Suppress Dana; keep account episodes There are nine raw events. Three scanner requests represent one automated cluster, and two form submissions represent one user action. Operationally distinct occurrences are therefore: scanner cluster, human visit, reply, form action, distributor form, and unsubscribe, or six occurrences. Only four are human commercial actions: visit, reply, Dana's form, and Lee's form. Dana's visit, reply, and form concern one replacement episode and update one lead. Lee's form creates a separate channel episode. Dana's unsubscribe stops contact with Dana but does not erase the past evidence or automatically suppress Lee. The company now has two episodes, not six leads and not one blended “very high intent” score.
7. Common mistakes
Adding every event into an intent score Event counts mix scanners, retries, weak behavior, explicit requests, and stop events. Resolve the class and fact supported. Merging at company level only One company can have unrelated sites, applications, projects, and buying groups. Deduplicating by time alone Two people can act seconds apart; one automation can act days apart. Use cause and evidence. Overwriting the “wrong” record A corrected interpretation does not make the original event disappear. Preserve history and the reason for revision. Ignoring negative and stop events Conflict and suppression are part of the episode, not inconvenient exceptions. Treating shared domain as one identity Role mailboxes, subsidiaries, consultants, and parent-child companies require explicit resolution.
8. What this does not mean
• It does not require all events to be merged into an account score.
• It does not claim that more independent signals equal purchase probability.
• It does not erase person-level suppression when an account remains active.
• It does not authorize sharing one stakeholder's confidential message with another.
• It does not replace identity, ICP, qualification, or data-retention policy.
9. Common questions
How long should an episode window be? There is no universal duration. Use the product, buying cycle, application, and explicit timing evidence. Keep the chosen rule versioned and allow a person to reopen or distinguish a project. Should multiple people at one company become one lead? Only if the operating model defines a lead at company or episode level. Preserve every person's role, evidence, treatment, and owner even when they share an episode. Does an explicit form override an earlier anonymous visit? It can clarify the episode and provide stronger identity and request evidence. It does not prove the anonymous visit came from the same person unless the link is supported. What happens when two records conflict? Mark the relevant field Conflicted, retain both sources and dates, limit high-impact action, and route a resolution task. Do not choose the more favorable record automatically.
10. Sources and methodology
Sources 1 W3C - PROV Overview. Used for provenance concepts involving entities, activities, agents, and derivation. Accessed August 25, 2026. 2 NIST SP 800-92 - Guide to Computer Security Log Management. Used as bounded guidance for trace, timestamp, access, review, and retention disciplines. Accessed August 25, 2026. 3 NIST - Information Quality Standards. Used for the general information-quality concepts of utility, objectivity, integrity, and correction, not as a private CRM mandate. Accessed August 25, 2026. 4 Google Analytics - Events. Used for first-party web-event measurement concepts. Accessed August 25, 2026. 5 IETF - RFC 9110, HTTP Semantics. Used to bound what a web request establishes before commercial interpretation. Accessed August 25, 2026. SellersGPT analysis and framework The THREAD Resolution Framework, relationship classes, operational derivation order, and example are original SellersGPT editorial tools. They are not W3C, NIST, Google, or IETF standards and do not estimate intent or purchase probability. Update policy Review this framework when event schemas, identity resolution, lead definitions, retention policies, or episode rules change. Re-test deduplication against known scanner, retry, forward, and repeated-form patterns.
Sources and Methodology
- support.google.com: How to Resolve Multiple Signals From the Same Person or Company
- rfc-editor.org: How to Resolve Multiple Signals From the Same Person or Company
- w3.org: How to Resolve Multiple Signals From the Same Person or Company
- csrc.nist.gov: How to Resolve Multiple Signals From the Same Person or Company
- nist.gov: How to Resolve Multiple Signals From the Same Person or Company
Methodology
This article separates cited official or first-party facts from SellersGPT calculations, examples, frameworks, and recommendations. Source links and scope are retained from the publication pack.
Limitations
This material supports planning and decision-making. It is not legal, financial, regulatory, or performance advice, and it does not guarantee leads, meetings, customers, revenue, or return on investment.