Audit Website Intent Coverage Before Blaming Low Account Activity

To audit website intent coverage, trace an approved visit from its host and page through collection, received activity, identity resolution, and the account view your team actually uses. Record the evidence at each step. A loaded tag does not prove that an event arrived, and a received event does not prove that a company was identified.

Low account activity can reflect several different conditions: limited traffic, deliberate collection exclusions, an implementation problem, unresolved identity, or a downstream filter. Diagnose those separately before changing targeting or concluding that accounts have lost interest.

The workflow below is a proposed audit method, not a report of tests performed on your website. It gives marketing operations, web owners, and sales operations a shared way to document what they intend to capture and what they can actually verify.

What should a website intent coverage audit establish?

A useful audit answers a narrow question: does the approved collection path work for the website surfaces that should contribute to the outbound account view? It does not establish whether every visitor can be identified or whether an identified company wants to buy.

Start with an evidence ladder. Each layer requires its own observation; passing an earlier layer cannot substitute for checking a later one.

1. Inventory hosts, subdomains, and page types

Build the inventory before opening a tag debugger. Otherwise, the audit tends to cover familiar pages and miss separate publishing systems. Ask the web owner for production hosts, campaign landing-page hosts, documentation surfaces, and any application areas included in the approved measurement plan.

For each entry, record the host, page template or route family, publishing system, technical owner, intended event source, and whether collection is approved. Identify excluded environments and pages explicitly. An excluded surface is different from an intended surface with a broken implementation.

Organize checks around deployment boundaries. A shared template may provide evidence for multiple pages, but a separately managed subdomain needs its own review. Include important paths with different navigation behavior, redirects, or consent presentation. Do not infer shared deployment from similar branding.

Keep expected coverage separate from commercial priority. Pricing pages may matter more to an outbound workflow, while other pages help explain a visit. Neither category justifies collecting activity outside your approved scope. The audit owner should be able to explain both why a surface is included and who authorized that choice.

2. Verify the published collection path

Inspect the production configuration that serves the page, not only a draft container or unpublished CMS setting. Record which system sends the activity and which destination workspace should receive it. Where ownership crosses teams, assign one person to confirm the handoff instead of accepting separate assurances that each side is configured.

Unify's website tag documentation describes installation in the page head or body, automatic page-visit collection, and initializing the client once. It also documents Content Security Policy requirements. Use that guidance to review the actual implementation; the presence of copied script text alone is insufficient evidence.

Record the deployed version or change reference where available. Check that the intended configuration is active on the host being tested. If the site uses a tag manager, distinguish its preview state from the published container. If the implementation uses application code, identify the release carrying that code.

Review consent and collection controls with the responsible owner. Test only approved conditions using authorized accounts and devices. If collection is intentionally withheld under a particular state, record that as expected behavior. Do not disable consent controls or protective settings simply to obtain a more reassuring activity count.

3. Run a permitted visit and preserve its context

Create a blank test record before navigating. Capture the page or route, host, test time and timezone, browser context, consent state, collection source, destination, and expected event. Avoid putting unnecessary personal information into the audit log.

Observe the browser and destination as separate steps. At the browser layer, record whether the expected collection component loaded and whether a relevant request was attempted. Preserve failures or blocking information that the implementation owner can investigate. A successful request is a transport observation, not proof of a usable account signal.

At the destination, look for the corresponding event using the narrowest practical combination of time, source, and page. Compare the observed properties with the intended event. If the destination cannot expose a suitable event record, mark this layer unverified and ask the owner what evidence is available.

Repeat the same planned check for each distinct implementation boundary. Do not count repeated visits to one familiar page as evidence that unrelated hosts work. Separate initial page loads from navigation paths your implementation is expected to measure. Record which paths remain untested so the final result has a clear scope.

4. Inspect received activity in Unify

Unify's website visitors documentation places incoming events under Settings → Web & product data. The Events tab supports source, domain, and event-type filters; the Settings tab shows connected sources and their last received event. Use those records to verify receipt after allowing for processing.

For the Intent Client, documented tracking rules include allowed domains and ignored URLs; an allowed domain also covers its subdomains. Check both rules against the inventory. The same documentation warns that sending identical activity through multiple sources can create duplicates.

Retain an event reference or permitted screenshot when possible, together with the audit observation. Avoid replacing evidence with a note that says only “working.” A useful entry identifies exactly what arrived and which planned check it supports.

When records appear duplicated, compare their sources and implementation paths before changing interpretation rules. When records appear absent, verify that the view itself is not hiding them. Preserve the difference between “no event found in this view” and “the destination received no event.” The first is an observation; the second needs broader evidence.

5. Separate identification from account-view visibility

Unify documents company identification through Reveal separately from identifying a known person using an identify event. Keep those outcomes separate in the audit. Company-level activity must not be presented as evidence that a named employee visited.

For matching mechanics, use the separate guide to how website visitor identification works. This coverage audit should stop short of provider match-rate comparisons. One permitted test visit cannot establish the identification performance of your entire traffic mix.

If an event exists but no company association is visible, record the identity step as unresolved. Do not invent an account association to complete the test. If an association exists, inspect the specific account record and the activity visible there before moving downstream.

Next, open the view the intended user relies on. Check its date range, ownership restrictions, account selection, and activity conditions. A correct underlying record can remain outside a narrowly configured audience. That may be intended behavior rather than an integration failure.

If the workflow continues into the CRM, verify the relevant record and destination field or activity object. The architecture belongs in the guide to connecting website intent data to your CRM; this audit establishes whether the agreed path can be observed on the surfaces tested.

Route the finding to the owner who can resolve it

Use the earliest unverified handoff to choose the next investigation. Avoid asking sales to change messaging when collection remains unverified, or asking engineering to repair an audience exclusion that the revenue team deliberately configured.

Close the audit with evidence, exceptions, and retests

For each inventory entry, record one of four proposed outcomes: verified within scope, intentionally excluded, failed at a named layer, or still unverified. Attach the observation, accountable owner, and next action. These are audit labels your team can adopt, not built-in Unify statuses.

Require a retest after a fix using the original approved conditions. Record the changed configuration and the new observation together. Retain unresolved items rather than converting them to a pass because other pages work.

A completion statement should say which hosts and paths were checked, under which conditions, and which layers were verified. It should not say that all visitors are identifiable or that low activity means weak demand. Reopen affected checks when collection ownership, consent behavior, website hosting, or destination workflows change.

If Unify is part of your stack, start with one approved surface and follow it through Web & product data to the intended account view. Expand only after the team agrees on the evidence required at each handoff.

Glossary

• Coverage: the approved website surfaces and conditions included in collection checks.
• Received event: an activity record visible at the destination, distinct from a browser request.
• Identity resolution: associating activity with a company or a known person using available information.
• Downstream view: the account list, audience, CRM record, or workflow where activity must become usable.
• Intentionally excluded: outside the approved collection or operational scope, rather than technically broken.

Frequently asked questions

Does a firing website tag prove that account identification works?

No. It establishes only an observation about the collection layer. Verify the received event, the company association, and the intended account view separately. An event can arrive without enough information to identify a company, and an identified company can remain outside a filtered audience.

Should every subdomain be included in the audit?

Inventory every relevant production subdomain, then distinguish approved collection surfaces from intentional exclusions. Test each separate implementation boundary. Shared branding or a common parent domain does not establish that a separate publishing system has the intended collection path deployed.

How should consent-related gaps be recorded?

Record the observed consent state and the behavior required by your approved implementation. If collection should be withheld, that is an expected exclusion for that condition. Investigate a mismatch with the responsible owner instead of bypassing the control to make activity appear.

Can low account activity prove that buyers are less interested?

No. First establish collection coverage, received activity, identity handling, and downstream visibility. Even after those checks, website activity is only one observation about account behavior. It does not establish budget, purchase timing, or the intentions of a specific employee.

What should trigger another coverage audit?

Retest affected surfaces after changes to hosting, templates, tag deployment, consent behavior, event sources, or destination workflows. Also investigate unexplained discontinuities in activity. Keep the previous scope and evidence available so the team can compare like-for-like conditions instead of relying on memory.