Implementation and QA: visitor identification guides
Install, test, filter, and debug visitor identification so the data is usable before sales sees it.
I need the tracking and data model to work cleanly.
To install visitor identification on Webflow, paste the vendor script into Site settings > Custom code (Head code), which applies site-wide once published; custom code needs a paid Site plan or a Core, Growth, Agency or Freelancer Workspace, because the free Starter plan cannot save custom code. On a HubSpot CMS site, paste it into Settings > Content > Pages > Site header HTML for the domain, which every plan can use. Both installs need the same QA pass afterward: confirm the script fires once, respects consent, and reaches the vendor dashboard before any signal reaches sales.
Reviewed September 25, 202611 min read
To install visitor identification with Google Tag Manager, add the vendor tag as a controlled GTM tag, limit its trigger to the pages that should collect visitor signals, check consent settings with your privacy owner, use Preview/Tag Assistant before publishing, and confirm the tag fires once without duplicating existing analytics or CRM events. GTM deploys and manages tags; it does not identify companies or people by itself.
Reviewed September 25, 202613 min read
Switching visitor-identification vendors safely means exporting and archiving historical matched-account data before cancellation, mapping old vendor fields to new vendor fields in the CRM instead of assuming they mean the same thing, running both tags in parallel for a QA window before cutting over, and only then removing the old script and pausing the old CRM workflow. Skipping the parallel-run step is the most common cause of a silent data gap between vendors.
Reviewed September 16, 20268 min read
A 5-minute weekly visitor-identification QA routine checks four things: is the script still firing on a known page, has the daily match volume moved outside its normal range, has a new noisy domain shown up that needs an exclusion rule, and does one downstream alert still read as a reviewed account signal instead of a name-and-outreach command. This is not the deep post-launch QA test or the full match-quality audit; it is a five-minute health check meant to catch a broken tag or a quiet vendor outage before a week of bad data reaches sales.
Reviewed September 16, 20267 min read
Client-side visitor identification is usually fastest when you need a browser tag to collect page activity and hand it to a vendor or analytics destination. Server-side visitor identification is better when your team needs a controlled collection layer, cleaner event governance, or first-party server events before sending data onward. Most B2B teams should choose a hybrid: browser-side tags for page/session context, server-side collection only for events the team can validate, and CRM/form records for known-contact evidence.
Reviewed September 14, 20269 min read
A website visitor identification implementation checklist should start with scope, evidence boundaries, and routing rules before any alert goes live. Confirm the tag or tracking code fires once on the right pages, decide what account or contact evidence each source can support, create CRM fields for source/fit/owner/stop rules, route only reviewed signals, write internal alerts that name assumptions, and QA the workflow after launch.
Reviewed September 2, 202612 min read
To exclude employees from visitor identification, write suppression rules before signals reach sales: filter or label internal/test traffic, suppress existing customers from prospect alerts, downgrade partners, vendors, competitors, and bad-fit accounts, and require a named evidence field for every exception. Use Google Tag Manager trigger scope, Google Analytics internal-traffic filters, CRM properties or lists, workflow conditions, and conservative alert wording as separate controls; do not treat any one tool as proof of identity or compliance.
Reviewed September 2, 202615 min read
To QA a visitor-identification pixel after launch, run a production test session on scoped pages, confirm the tag fires once, verify trigger and consent behavior against the implementation plan, look for the visit in analytics or the vendor interface, confirm any CRM/workflow handoff is labeled as a reviewed account signal, and check that internal alerts state what is known, inferred, and not safe for outreach. A passing test proves the tag and downstream workflow are usable; it does not prove every anonymous visitor is a named buyer.
Reviewed September 2, 202614 min read