Visitor Identification Data Model: The CRM Fields That Prevent Bad Routing

A visitor identification data model should make weak signals safer to use, not make them sound stronger than they are. Keep a small CRM schema that records the signal source, evidence level, matched account or known-contact context, page or offer context, fit and suppression status, privacy-review label, owner, allowed next action, and stop rule. Drop raw page trails, oversized vendor exports, person-level labels, and permanent intent scores unless a documented source and review owner support that use.

Use this as a schema template before visitor-identification data enters HubSpot, Salesforce, Slack alerts, or sales tasks. The goal is not to collect every available field. The goal is to preserve enough evidence that RevOps can route or suppress a signal without implying a named buyer visited when the data only supports account-level review.

The CRM field schema

Start with three groups: fields to keep by default, fields to keep only when a workflow truly needs them, and fields to keep out of CRM unless a review owner approves them.

Field	Suggested type	Keep when	Owner	Allowed use	Stop rule
visitor_signal_source	Picklist	Every visitor-identification workflow. Values might include vendor, first-party form, known-contact activity, manual account research, or reviewed import.	RevOps or CRM admin.	Explain where the signal came from before routing or alerting.	Stop if users cannot tell vendor inference from explicit form evidence.
evidence_level	Picklist	Every workflow. Use labels such as account-level match, known contact, explicit form submission, anonymous page activity, or manual review.	RevOps plus privacy reviewer.	Prevent account evidence from becoming person-level outreach.	Stop if the label says “identified person” without source proof.
matched_account_or_domain	Text or account lookup	The workflow performs account review, suppression, or routing.	CRM owner.	Connect the signal to account research or existing ownership.	Stop if consumer ISP, school, agency, employee, or ambiguous domains are treated as target accounts.
known_contact_evidence	Picklist or text	A form submission, login, CRM record, or first-party event connects the signal to a known record.	CRM owner.	Separate known-contact activity from anonymous account signals.	Stop if the field is filled from anonymous visitor identification alone.
page_or_offer_group	Picklist	Routing depends on broad page intent, asset, campaign, or form type.	Web or marketing ops.	Route by reviewed page group without storing every raw URL forever.	Stop if low-intent, support, careers, login, or internal pages enter sales routing by default.
data_layer_context_key	Text or picklist	A tag or workflow passes structured page/event context.	Tag owner.	Document which data-layer value fed the downstream field.	Stop if the data layer carries unnecessary personal, sensitive, or unreviewed fields.
fit_status	Picklist	Sales action depends on ICP fit.	RevOps or sales ops.	Suppress bad fit and route good fit to review.	Stop if fit is missing but automation still creates a task.
suppression_reason	Picklist	Always, even if the value is none.	Sales ops.	Exclude employees, customers, partners, competitors, open opportunities, test traffic, and weak matches before alerts.	Stop if suppression happens after a rep notification.
privacy_review_label	Picklist	The workflow touches tracking, CRM writes, exports, regional choices, or outreach.	Privacy/legal owner.	Show whether the workflow is approved, needs review, or must stay internal.	Stop if the field is blank and sales will see the signal.
allowed_next_action	Picklist	Every workflow that can trigger owner assignment, tasks, alerts, or nurture.	Sales ops plus RevOps.	Keep actions proportional: review, suppress, nurture, owner check, create task, or hold.	Stop if weak evidence maps directly to direct outreach.
workflow_owner	User/team lookup	Every operational field set.	Operations lead.	Name who changes the model and answers audit questions.	Stop if no owner can explain why a field exists.
stop_rule	Text	Every field set that can influence sales.	RevOps or privacy reviewer.	Tell users exactly when not to route, alert, export, or contact.	Stop if sales copy can hide the uncertainty.
last_reviewed_at	Date	Periodic review or policy-sensitive fields.	Field owner.	Trigger field cleanup, retention review, and source verification.	Stop if fields are never reviewed after launch.

This schema works because it keeps source, evidence, action, and ownership separate. HubSpot property documentation supports the idea that CRM properties can store structured operational values. Salesforce field documentation supports field-type and custom-field planning. Those docs do not prove visitor identity, so the field names must preserve uncertainty instead of hiding it.

Optional fields to add only when they change a decision

Add optional fields only when someone can name the workflow that reads them.

Optional field	Add when it changes	Safer default
account_match_confidence_label	A vendor or internal process provides a documented confidence tier and the workflow treats weak matches differently.	Use low, medium, high, or review-needed labels, not an invented precision score.
intent_page_group	Page grouping changes account review priority.	Store a reviewed group such as pricing, demo, product, integration, lead magnet, or education instead of every page URL.
recent_activity_window	Timing matters for routing.	Store a coarse window such as last 7 days or campaign period; avoid raw histories unless needed for QA.
existing_owner_result	Assignment depends on lead, contact, account, opportunity, customer-success, or territory ownership.	Prefer existing owner review before round-robin.
review_notes	A human review is required before action.	Use short operational notes, not speculative statements about buyer intent.
alert_payload_label	Slack, email, or task alerts use the field set.	Store the exact evidence label and safe next action that the alert will show.

The Google Tag Manager data layer can pass structured event and page context to tags. Use that for context labels, not as proof that an account is a buyer. Slack incoming webhooks can deliver internal messages, but the webhook is only plumbing; the CRM schema still needs evidence and stop rules before an alert is safe.

Fields to keep out of CRM by default

Some data is tempting because vendors can export it, but it usually creates more risk than routing value.

Do not store by default	Why	Safer alternative
Raw URL-by-URL visit history	It can be noisy, stale, sensitive, and hard to explain later.	Store a reviewed page or offer group plus the source system.
Full query strings or referrers	They may include unnecessary or sensitive context.	Store campaign or source labels after review.
Person-level identity labels from anonymous account data	They overstate what account-level visitor identification can prove.	Use evidence_level and known_contact_evidence separately.
Vendor match-rate or accuracy claims	They become unsupported metrics unless current source documentation and your own test support them.	Store a dated confidence label or manual-review result.
Permanent “hot lead” or “buying intent” scores	They hide uncertainty and age badly.	Store the evidence fields that caused the review action.
Unowned free-text notes	They can become undocumented policy or outreach guidance.	Use controlled fields plus a named workflow_owner.
Export/screenshot paths	Copies outlive the system of record.	Keep exports in a controlled review packet with a deletion or archive owner.

Use the existing data-minimization guide when the main problem is reducing retention, exports, or broad collection. Use this page when the main task is deciding the CRM schema before routing starts.

How to model evidence without overstating identity

The most important field is evidence_level. It should be boring and explicit:

Evidence label	What it can support	What it cannot support by itself
anonymous_page_activity	Aggregate analysis, content performance, or tag QA.	Account routing, named-person outreach, or sales-ready claims.
account_level_match	Internal account review, suppression checks, owner lookup, or account research.	A claim that a specific person visited.
known_contact_activity	Owner review when a known CRM record has a documented first-party event.	Outreach that ignores consent, preference, or relationship context.
explicit_form_submission	Asset fulfillment and normal form or Web-to-Lead routing.	Merging unrelated anonymous account activity into the form evidence.
manual_review_approved	The next action named by the reviewer.	Expanding the use beyond that approval without another review.

This separation keeps HubSpot workflows, Salesforce assignment rules, and Slack alerts from acting on a stronger story than the source supports. A workflow can still be useful; it just has to say what it knows.

Worked example: one pricing-page account signal

Assume a visitor-identification vendor reports that ExampleCo visited a pricing page. No person filled out a form. The CRM already has an ExampleCo account with an owner, and the vendor page is being used only as category evidence, not as proof of match quality.

A safe CRM record might look like this:

Field	Value
visitor_signal_source	visitor-identification vendor
evidence_level	account-level match
matched_account_or_domain	exampleco.com or ExampleCo account lookup
known_contact_evidence	none
page_or_offer_group	pricing
fit_status	review-needed
suppression_reason	none found yet
privacy_review_label	internal-review-only
allowed_next_action	account-owner review
workflow_owner	RevOps
stop_rule	do not claim a named person visited; do not create outreach until owner review confirms the next action
last_reviewed_at	2026-09-02

That record can help the account owner review context. It should not create a message saying, “Someone from ExampleCo is ready to buy,” and it should not create a new lead if there is already an owner or open opportunity that should handle the signal.

Build the model in this order

1. Define the allowed action first: suppress, review, nurture, assign owner, create task, alert, or hold.
2. Add only the fields needed to explain that action later.
3. Choose CRM field types that keep choices consistent: picklists for source and evidence, dates for review cadence, lookups for owners or accounts, and short text only when a controlled list would lose necessary context.
4. Decide which fields are short-lived review fields and which belong in permanent account or contact records.
5. Test the schema with one explicit form submission, one known-contact activity, one account-level visitor match, one employee or customer visit, and one weak or ambiguous match.
6. Review the alert or task copy before launch. It should state source, evidence level, owner, safe next action, and stop rule.

If a field does not change one of those decisions, do not add it yet.

Claim ledger

Claim used in this guide	Source checked	What the source supports	What this guide does not claim
CRM properties and fields can store structured operational values.	HubSpot properties docs and Salesforce field docs, checked 2026-09-02.	Field/property planning for CRM data.	CRM fields prove visitor identity or deserve permanence by default.
Data-layer context can pass structured page or event information to tags.	Google Tag Manager data-layer docs, checked 2026-09-02.	Website context handoff to tags.	The data layer proves consent, account fit, or sales readiness.
Incoming webhooks can deliver internal Slack messages.	Slack incoming-webhooks docs, checked 2026-09-02.	Alert payload delivery as internal messaging plumbing.	A visitor-identification vendor has a specific Slack integration or the alert is safe for outreach.
Data minimisation, accuracy, storage limitation, security, accountability, and lawful processing require review.	ICO and EDPB guidance, checked 2026-09-02.	Privacy-review principles and escalation topics.	Legal advice, a lawful basis, or a universal retention period.
Visitor-identification vendor pages can be used as cautious category examples.	Leadinfo and Snitcher pages, checked 2026-09-02.	The category exists and is marketed around visitor/account identification.	Match rates, pricing, integration depth, compliance outcomes, or person-level certainty.

FAQ

What fields should be in a visitor identification data model?

Start with signal source, evidence level, matched account or known-contact context, page or offer group, fit status, suppression reason, privacy-review label, allowed next action, owner, stop rule, and review date. Add optional fields only when a workflow reads them.

Should visitor identification create contact fields or account fields?

Account-level signals usually belong on an account, review queue, or task context, not as proof on a named contact. Contact fields are safer when there is explicit form submission, known-contact activity, or another first-party source that supports the contact-level label.

How is this different from data minimization?

Data minimization asks how to collect and retain less. This data model asks which fields are useful enough to exist in CRM at all. The two work together: use the model to name the necessary fields, then use minimization rules to limit scope, access, exports, and review cadence.

Can I store a visitor intent score?

Only if the score is documented, reviewed, and tied to a safe next action. A score with no source label or expiration can make weak evidence look certain. Prefer storing the evidence fields and a manual-review result.

What should a Slack alert include from this model?

Include the signal source, evidence level, matched account or known-contact context, page group, owner, allowed next action, and stop rule. Do not include wording that implies a named person visited unless the CRM evidence supports that exact claim.