If your website visitor identification match rate looks worse on some sessions than others, remote work is probably why. A visitor on a home internet connection resolves to a residential ISP, not an employer, so most identification tools never get a company to match against at all. That's not a bad match or a false positive. It's a session that never had a chance of resolving in the first place, and if you don't account for it, it quietly drags down every match-rate number your team reports.

This is different from the VPN and corporate-SASE problem we've written about before, where traffic gets mis-attributed to the wrong company because thousands of employees share one exit IP. Remote work on a home connection doesn't mis-attribute anything. It just returns nothing, and a silent miss is a different problem to solve than a wrong match.

Why remote sessions are structurally different from office sessions

Most website visitor identification starts with the visiting IP address and works outward from there. On a corporate network, that IP address is registered to a business, so a reverse-IP lookup returns a real company name. On a home network, the same IP address is registered to Comcast, Spectrum, AT&T, or another residential ISP. There's no business entity for the IP to resolve to, so the account-level lookup returns nothing before person-level identification even has a chance to run.

Company-level identification against a residential IP fails at the infrastructure layer, not the vendor layer. No amount of tuning fixes a lookup that has no business record to find. That's the honest baseline every RevOps and demand-gen leader should start from before they start troubleshooting their vendor.

Person-level identification isn't blocked by the same wall. It doesn't depend on the IP resolving to a company at all. Knock2 matches visitors, including ones on residential connections, against an identity graph built from a consent-based publisher network, so a name, email, and title can surface even when the account-level lookup comes back empty. That's the mechanism worth understanding before you assume a remote session is unrecoverable: the two identification layers fail independently, and losing one doesn't have to mean losing both.

A miss isn't a false positive, and it shouldn't be diagnosed like one

Teams that read our piece on catching false positives in visitor ID data sometimes bring the same checklist to a remote-work gap, and it doesn't apply. A false positive is a wrong answer: the tool confidently names a company or person that isn't actually who visited. A residential-IP miss is no answer at all: an empty account field, an empty contact field, a session that simply doesn't appear in your identified-visitor report.

That distinction matters operationally. False positives get fixed by tightening confidence thresholds and filtering rules. Residential-IP misses don't respond to threshold tuning, because there was never a low-confidence match to filter, just no match. Treating a structural miss like a confidence problem wastes a debugging cycle chasing a fix that can't exist at the account-ID layer.

How to tell how much of your gap is actually this

Before you build a recovery plan, size the problem. A few checks, in order of effort:

• Segment your unmatched sessions by connection type. Most identification platforms (Knock2 included) expose ISP or network-type data on unmatched sessions. Pull a week of unresolved sessions and check how many resolve to known residential and mobile carriers versus business ISPs. That ratio is your real WFH-blind-spot size, not a guess.
• Compare match rate by time of day and day of week. If your account-level match rate dips on Mondays and Fridays, or evenings, relative to Tuesday-through-Thursday office hours, that pattern tracks with hybrid work schedules more reliably than almost any other signal.
• Cross-reference against your CRM's known remote employees. If you sell into companies with fully distributed teams (dev tools, remote-first SaaS, agencies), pull a sample of contacts you know work from home and see how their sessions resolve. It's a small sample, but it's a real one.

Most teams find the residential-IP share of their unmatched traffic sits meaningfully higher than they assumed, especially in industries like software, professional services, and agencies where remote and hybrid work are the default rather than the exception.

The recovery playbook: what actually gets a name back

None of these techniques are magic, and none of them will resolve 100% of residential traffic. What they do is recover a meaningful share of sessions that a pure reverse-IP lookup would otherwise write off entirely.

• Declared-identity capture and cross-reference. If the same visitor has ever filled out a form, opened a marketing email, or logged into a gated resource from any network, that declared identity can be matched against a later anonymous session through your own first-party data, not just the ISP lookup. This is the single highest-leverage fix and the one most teams underuse.
• Waterfall enrichment. Running a residential-IP session through a secondary identification pass, rather than accepting the first lookup's null result, is exactly the approach we lay out in our waterfall enrichment guide. It's built for precisely this kind of layered failure.
• Intent-data overlay. When a session can't resolve to a person, account-level intent signals (repeat visits from the same general geography, content topic patterns, correlated account engagement elsewhere in your stack) can still tell you a target account is active, even without a name attached to this specific visit.
• Consent-based identity graph matching. This is the mechanism that gives person-level identification a path around the residential-ISP wall in the first place, matching the visitor against a broader identity graph rather than relying on IP-to-business resolution alone.

What to do with the sessions that still won't resolve

Some share of remote-work traffic won't resolve no matter what you run against it, and the honest move is to plan for that rather than chase a 100% number that doesn't exist. Two practical adjustments:

First, stop reporting a single blended match rate to leadership without a segment breakdown. A blended number that mixes office and residential traffic will always look worse than either segment alone, and it invites the wrong conversation about vendor performance. Report office-network and residential-network match rates separately, the way you'd already segment mobile from desktop.

Second, build a fallback play for genuinely unresolved sessions instead of ignoring them. Account-level intent signals, retargeting based on page and content engagement, and nurture sequences triggered by aggregate behavioral patterns can all still move a session toward pipeline even without a name. The goal isn't to fake identification. It's to make sure an unresolved visitor isn't a dead end just because this particular session didn't produce a contact record. Our piece on proving ROI on website visitor identification covers how to frame this kind of blended-value reporting for stakeholders who only see the raw match-rate number.

Knock2 identifies 93%* of accounts and 62%* of individual visitors, name, email, and title, on US traffic, measured against engaged sessions. Those numbers already account for structural gaps like residential-IP traffic. If your current tool's advertised accuracy doesn't hold up once you segment out remote-heavy traffic, that's a fair question to bring to your next vendor conversation.

*Identification rates measured against engaged sessions (any visit lasting 10 seconds or longer, or including 2 or more pageviews). Results may vary by traffic profile, geography, and industry.

FAQ: Website visitor identification and remote workers

Why doesn't my visitor ID tool identify traffic from home offices?

Because company-level identification typically starts with a reverse-IP lookup, and a home internet connection resolves to a residential ISP rather than a business. There's no company record for the lookup to find, so the session returns unmatched before person-level identification can run.

Is a residential-IP miss the same as a false positive?

No. A false positive is a wrong match: the tool names a company or person that isn't who actually visited. A residential-IP miss is an empty result. They have different causes and need different fixes.

Can person-level identification work even when company-level identification fails?

Yes, because it doesn't depend on the IP resolving to a business. Person-level matching against a consent-based identity graph can surface a name, email, and title on a residential-IP session even when the account-level lookup comes back empty.

How much of my traffic is affected by this?

It varies by industry and how remote or hybrid your buyer base is. Segment your unmatched sessions by ISP/network type and compare match rate by day of week to get a real number instead of a guess.

What's the single best fix for this blind spot?

Declared-identity cross-reference, matching a later anonymous session against an identity the same visitor has already given you through a form fill, email click, or gated-content login, recovers more remote-work sessions than any other single technique, because it doesn't depend on IP resolution at all.

Want to see how much of your own traffic is falling into this gap? Book a Knock2 demo and we'll walk through your segmented match rate, office versus remote, before you commit to anything.