A device graph is a probabilistic or deterministic mapping that links a single individual across the multiple devices, browsers, and sessions they use, allowing an anonymous web visit on one device to be resolved to a known profile based on activity observed on another device. In B2B identity stacks the device graph is the connective tissue that powers contact-level deanonymization.
TL;DR
A device graph links devices to people. Deterministic graphs use confirmed identifiers (an email open, a logged-in session, a CRM-known visitor) to anchor a profile, then probabilistic links extend coverage to other devices the same person uses. B2B identity stacks use the graph to resolve anonymous website visitors to named individuals (contact-level deanonymization). Match rate depends on graph coverage in the visitor's geography and on the recency of confirmed activity.
---How a device graph is built
A deterministic device graph is built from confirmed identity events. A user opens an email tracked by a pixel, which ties the device to a known email address. A user logs into a web application that shares identity with the graph provider. A user fills a form that confirms the identity. Each confirmed event anchors that device to that person.
A probabilistic device graph extends the deterministic core. If two devices share a household IP for months, the graph infers a likely individual link. If a device fingerprint pattern matches across browsers, the graph infers a likely same-person link. Probabilistic extension expands coverage but introduces false-positive risk, which is why the highest-quality identity providers anchor every probabilistic edge in at least one deterministic confirmation.
What a device graph enables in B2B
The primary B2B use case is contact-level deanonymization. When an anonymous visitor lands on a B2B website, the device graph looks up the visiting device, finds a confirmed identity anchor, and returns the named individual. The vendor then knows that "Jane Doe (VP RevOps at Acme Corp)" visited, not just "someone from a Comcast residential IP".
The secondary use case is cross-device journey reconstruction. A buyer researches on their laptop at work, switches to mobile during a commute, and lands on the vendor's pricing page from a personal device that evening. Without a device graph the three sessions look like three different visitors. With a device graph the three sessions resolve to one person, and the journey can be reconstructed for attribution and personalization.
Skip the manual work
Abmatic AI runs targets, sequences, ads, meetings, and attribution autonomously. One platform replaces 9 tools.
See the demo →Examples of device graphs in B2B production
A B2B SaaS vendor uses a deterministic-anchored device graph (via a third-party identity provider that the contact-level deanonymization layer plugs into) to resolve 30 to 50% of US business-hour traffic to a named individual. The match rate is highest for repeat visitors with prior email engagement and lowest for first-time visitors arriving from organic search.
A mid-market platform vendor uses the device graph for both anonymous resolution and cross-device journey reconstruction. The platform's pricing-page conversion attribution credits the full set of sessions across devices for the same person, not just the device of the converting session. The reporting layer rolls up to account-level pipeline contribution.
An enterprise vendor uses the device graph to disambiguate buying-committee members in real time. Three different devices from three different IPs visit the same vendor's product pages on the same day. The device graph resolves them to three named individuals at the same target account, and the platform recognizes a buying-committee forming and routes Slack alerts to the AE.
---How Abmatic AI handles this
Abmatic AI is the most comprehensive AI-native revenue platform on the market. The shared identity graph that powers contact-level deanonymization (RB2B / Vector / Warmly equivalent, native capability) is built on top of a device-graph layer integrated with leading identity providers. Anonymous visits get resolved to named individuals where graph coverage permits.
Once resolved, every downstream module uses the identity. Web personalization (Mutiny / Intellimize-class) swaps copy by persona. Agentic Chat (Qualified / Drift-class) opens with role-aware questions. Agentic Outbound (Unify / 11x / AiSDR-class) enrolls the matched contact in a sequence. Account-list-driven LinkedIn Ads, Meta Ads, and Google DSP target the resolved account. Agentic Workflows fire if-X-then-Y rules off of identity-driven signals. AI SDR meeting routing (Chili Piper-class) sends qualified inbound to the right AE.
The shared signal layer pairs first-party intent and third-party intent with the resolved identity. The shared identity graph also includes account-level deanonymization (6sense / Demandbase equivalent), so both layers operate on the same data. The platform covers 15+ native modules, runs on bi-directional Salesforce and HubSpot integrations, and is priced starting at $36,000 per year. Time-to-value is days.
---FAQ
Is a device graph the same as a cookie graph?
Related but not identical. A cookie graph links browser cookies; a device graph links devices, which can include multiple cookies per device and signals that survive cookie clearing. Device graphs are more durable than cookie graphs in modern privacy conditions.
How accurate is a device graph?
Deterministic links are essentially 100% accurate. Probabilistic links carry false-positive risk; the highest-quality graphs report match-confidence scores and let downstream applications choose a threshold. For B2B contact-level deanonymization the conventional threshold trades modest coverage loss for high precision.
Does third-party cookie deprecation kill device graphs?
No, but it changes their composition. Graphs that depended heavily on third-party cookies have lost some coverage and have shifted toward email-pixel anchors, logged-in-session anchors, and first-party device fingerprints. The capability remains but the data sources have rotated.
How is a device graph different from a CRM contact record?
A CRM record stores known contacts the vendor has touched. A device graph resolves anonymous activity to identities, including identities that may never have entered the vendor's CRM before. The two layers feed each other: the graph identifies new prospects, and the CRM stores the relationship over time.
Curious how device-graph-powered contact-level deanonymization fits in one platform? Book an Abmatic AI demo.
