Apollo's own website visitor identification tells you which company showed up on your site. It does not tell you which person did. If you're already running outbound through Apollo sequences and want to trigger them off real, person-level visitor identification instead of Apollo's IP-to-company guesswork, you need a dedicated identification layer feeding Apollo, not Apollo's own contact-matching step. Here's exactly how that workflow works, why the distinction changes your reply rates, and how to build it without adding a second tool your reps have to check.

What Apollo's Native Visitor ID Actually Identifies

Apollo's website visitor tracking works by matching your traffic's IP addresses against its own database of 230M+ contacts and 30M+ companies. Read Apollo's own documentation closely and the two-step process becomes clear: first, a "Play" captures the account by resolving the visiting IP to a company. Second, a separate Play "finds the right contacts" at that company from Apollo's database.

That second step is not identification. It's a best-guess contact suggestion pulled from Apollo's own B2B database, based on who's likely to be relevant at the company that showed up, not the actual individual who was on your pricing page at 2:14 PM. If your VP of Sales visits your site and Apollo suggests your VP of Sales as a contact to sequence, that's a coincidence of good account mapping, not confirmation of who visited.

This matters because it changes what you can honestly say in outreach. "I noticed [Company] checking out our pricing page" is defensible with company-level matching alone. "I noticed you checking out our pricing page" is not, unless you've actually identified that specific person.

Why Person-Level Identification Changes What You Can Automate

Person-level identification means the platform actually resolves a visitor to a name, verified email, and title, not a plausible contact at the matched company. Knock2 matches visitors against an identity graph built from a consent-based publisher network, and publishes two identification rates measured against engaged sessions (any visit of 10+ seconds or 2+ pageviews, per Google Analytics' definition):

• 93%* account/company-level identification
• 62%* person-level identification (name, email, title), US traffic only

*Identification rates measured against engaged sessions. Results may vary by traffic profile, geography, and industry.

The practical difference: when a visit resolves at the person level, you can trigger an Apollo sequence addressed to the actual individual, referencing the actual page they viewed, without Apollo's contact-suggestion layer guessing on your behalf. When a visit only resolves at the company level, you still have a real, actionable signal, but it belongs in a different motion (Slack alert to the account owner, not an automated 1:1 sequence written as if you know who read the page).

How to Build the Identification-to-Apollo Workflow

The workflow itself is short. A standing automation, what Knock2 calls a Play, sits between identification and Apollo, using a native Apollo action (see the full list on our native integrations page) rather than a manual CSV export:

1. Identify. A visitor lands on your site and gets matched against the identity graph in real time.
2. Filter. The Play checks match confidence, page intent, and whether the contact or account already has an open deal, so you don't sequence someone your AE is already emailing.
3. Enrich. Missing fields (title, verified email) get filled before the record moves anywhere, ideally by checking more than one source; see our waterfall enrichment breakdown if a single provider is leaving gaps.
4. Route. Qualifying contacts get added directly to an Apollo sequence; everyone else gets a Slack alert, a CRM record, or nothing, depending on the tier below.

The Play is built once, reviewed, then armed. Nothing fires into a live sequence until a human has seen the rule and turned it on, which matters more than it sounds like it should, because the failure mode of visitor-triggered outbound is almost always volume, not accuracy: teams that skip the filter step drown their sequences in company-level-only matches and torch their reply rates within a month.

What Confidence Tier Should Trigger What Action

Not every identified visitor belongs in a sequence. Treat match confidence and page intent as a gate, not a formality:

• 🔴 Very High - person-level match, verified email, engaged session on a high-intent page (pricing, demo, product) - Auto-enroll in an Apollo sequence immediately, personalized with the page they viewed
• 🟠 High - person-level match, unverified title, single engaged session - Auto-enroll in a lighter-touch sequence variant, hold the personalization claims to what you actually know
• 🟡 Medium - company-level match only, but on a high-intent page - Route to Slack for the account owner, do not auto-sequence a specific name you don't have
• 🟢 Low-Medium - company-level match on general content pages - Add to a CRM nurture list, revisit if the account returns to a higher-intent page
• ⚪ Low - below the engaged-session threshold - No action; a single-page bounce isn't a signal worth spending sequence capacity on

That 🟡 tier is where most Apollo-native setups quietly go wrong. Because Apollo's contact-suggestion step returns a plausible name at the company level, it's tempting to treat it as good enough to auto-enroll. It isn't. A wrong-guess contact sequence is worse than a Slack alert asking a human to confirm the right person, because the wrong-guess version burns a real prospect's inbox and your sender reputation on a message addressed to someone who was never on your site.

What This Looks Like Once It's Running

Once the Play is live, the reps' experience doesn't change much, which is the point. A qualifying visitor shows up in Apollo already enrolled in the right sequence, with the visited page and identification confidence attached as context, the same way a rep would expect a warm inbound lead to arrive. The identification and filtering logic runs upstream, invisible unless something needs a human decision, in which case it lands in Slack instead of silently misfiring into a sequence.

This isn't a replacement for Apollo. Apollo remains the sequencing and engagement engine; nothing here changes how sequences, steps, or reply detection work inside it. What changes is what triggers the sequence and who it's personalized to; instead of Apollo's own IP-to-company-to-guessed-contact chain, the trigger is a real identification event with a confidence tier attached, and the routing logic decides whether that event deserves a sequence, a Slack ping, or nothing at all. The same pattern works if your reps route into CRM records instead of a sequencer; see how the same identify-filter-route logic looks when the destination is HubSpot pipeline instead of an Apollo sequence.

The filtering discipline matters more than the tool you route into. Teams running warm outbound built on intent signals already know that volume without a confidence gate is what kills reply rates, whether the trigger is a website visit, an intent spike, or an Apollo-native contact guess.

Frequently Asked Questions

Doesn't Apollo already do website visitor identification?

Apollo has a native feature that resolves visiting IP addresses to companies, then suggests likely contacts from its own database. That's company-level identification plus a contact guess, not a confirmed match to the specific person who visited. If your outreach claims to know who visited, and not just which company, you need a person-level identification source feeding into Apollo, not Apollo's own contact-suggestion step alone.

What's the real difference between company-level and person-level identification for outbound?

Company-level identification tells you an account showed interest; it's enough to route a Slack alert or add an account to a target list. Person-level identification tells you which individual to sequence and what to reference in that sequence honestly. Treating a company-level match as if it were person-level is how "personalized" outbound ends up addressed to the wrong person.

How does a visitor actually get enrolled into an Apollo sequence automatically?

A standing automation identifies the visitor, checks match confidence and existing deal status, enriches any missing fields, then adds qualifying contacts directly into the target Apollo sequence. The rule is built and reviewed before it's turned on, so nothing enrolls automatically until a human has approved the filter logic.

What should I filter out before a visitor ever reaches a sequence?

At minimum: match confidence tier, whether the contact or account already has an open opportunity (don't sequence someone your AE is mid-conversation with), and a minimum engagement threshold so single-page bounces don't consume sequence capacity. Skipping these filters is the most common reason visitor-triggered outbound programs burn out their reply rates within weeks.

Does this work if most of my traffic only resolves at the company level?

Yes, but it changes the play, not the value. Company-level-only matches should route to Slack alerts and CRM account records, not automated 1:1 sequences written as if you know the individual. The difference between person-level and company-level identification determines which motion a given visit belongs in.

Ready to see which of your Apollo-bound contacts are company-level guesses and which are confirmed matches? Book a demo and we'll show you the identification layer running against your own traffic.