Before installing a heatmap, decide what it is allowed to see

A heatmap can show where people click and how far they scroll. A session recording can reconstruct a visitor's path through a page. Those tools may reveal a broken button or a confusing form, but installing one without boundaries can also collect more website behavior than the business intended.

Do not begin with the tracking code. Begin with one decision, the pages needed to support it, and the information the tool is not allowed to receive. Then test the accepted, rejected, and withdrawn-consent paths before treating the installation as complete.

Use the low-traffic website-fix guide when the question is how much confidence to place in sparse behavior data. Use this checklist when deciding whether and how a heatmap or session-recording tool should observe the site at all.

Define the observation job

Write one sentence that connects the tool to a decision:

We will observe [specific pages and interactions] for [time window] to decide whether [named change] should be tested, repaired, or left alone.

“Understand visitors” is too broad. “Determine whether mobile visitors can find and use the appointment button on the service page” is testable. It also gives you a reason to exclude checkout, account, support, and internal pages that do not answer the question.

Record the following before evaluating vendors:

Heatmaps and recordings are not interchangeable. An aggregate click map may answer whether people use a navigation item without exposing an individual journey. A recording may be useful for reproducing a broken multi-step flow, but it creates more detailed evidence and needs a narrower purpose, page scope, and access list.

Build a page-risk map before installation

Inventory page templates, not just a few visible URLs. A form or account component can appear across many generated routes.

These are planning categories, not legal classifications. A public page can still expose personal information through query strings, embedded widgets, error messages, form validation, or personalized content. Inspect the actual rendered page in each relevant state.

Review at least these surfaces:

• Text, number, email, search, and free-response inputs
• Dropdown selections, calendars, uploads, and chat transcripts
• Confirmation pages and validation errors
• Account names, order numbers, appointment details, and support references
• Page titles, URL paths, query parameters, and fragments
• Images, videos, canvases, iframes, and embedded third-party tools
• Data attributes and CSS-generated content
• Mobile layouts and single-page application route changes

Do not assume a vendor's default masking covers every one of those surfaces. Microsoft says Clarity masks input boxes and dropdowns in all masking modes, but also documents site-wide modes, element overrides, and content that needs separate attention. It states that masking changes affect new recordings and cannot be applied retroactively. Current Contentsquare documentation for its Hotjar platform similarly says suppression happens before a session is sent and cannot be applied to already transmitted sessions. That makes a pre-install page map materially different from cleaning up later.

Decide what the consent states should do

Consent requirements vary by jurisdiction, purpose, technology, and configuration. This checklist does not determine your legal basis. Document the markets you serve, obtain qualified advice where needed, and configure the tool to match the policy you actually adopted.

Do not reduce the question to “Are cookies present?” Microsoft currently documents that when Clarity's analytics_storage state is denied, its tag can still load and collect cookieless data with some features limited. Google likewise documents basic and advanced consent-mode behavior and requires default states to be set and then updated from the user's choice. A no-cookie test is useful, but it is not a complete no-data test.

Build the expected behavior before testing:

The UK Information Commissioner's Office currently says non-exempt storage and access technologies require prior consent, that silence does not qualify as consent, and that withdrawal should be as easy as giving consent. Its guidance also says a new technology or purpose may require fresh consent. Those rules are specific to the covered UK framework, but the operational lesson travels well: the banner copy, saved preference, tag timing, and network behavior must agree.

Test the data boundary, not just the dashboard

Use a non-production environment if it faithfully represents the production templates and consent system. If a controlled production test is necessary, use clearly marked test records and remove them where the product allows.

Run a small matrix across relevant devices and states:

1. Clear the site's cookies and local storage.
2. Open developer tools before loading the page.
3. Visit one included public page without making a consent choice.
4. Inspect scripts, network requests, cookies, local storage, and the tool's reported consent state.
5. Reject analytics and repeat the page path.
6. Accept analytics and repeat the same path.
7. Withdraw the choice and verify the immediate and next-page behavior.
8. Submit validation errors and a marked test record through every included form type.
9. Visit every excluded template and confirm that no prohibited capture appears.
10. Review the resulting heatmap or recording as the lowest-permission viewer, not only as an administrator.

For each case, save the time, time zone, browser, device class, path, consent action, expected behavior, observed requests, storage keys, recording or heatmap result, masking result, and pass or fail decision.

Calculate completion without mistaking it for compliance:

Test completion = completed required cases / required cases

Pass coverage = passed required cases / required cases

Suppose a business defines 18 required cases across pages, devices, and consent states. It completes 17 and passes 15. Test completion is 17 divided by 18, or about 94.4%. Pass coverage is 15 divided by 18, or about 83.3%.

Neither percentage authorizes launch. One failed excluded-page test can outweigh fifteen ordinary passes. Use the ratios to expose unfinished work, then apply a hard rule: every high-risk exclusion, suppression, rejection, and withdrawal case must pass before broad collection begins.

Set retention and access before data arrives

Vendor retention is not one universal number. Microsoft currently lists 30 days for Clarity playback data, while other Clarity data types and saved subsets can follow different periods. Other products may vary by data type, plan, configuration, or deletion action. Record the current terms you examined, the business's shorter internal need if applicable, and who is responsible for deletion or review.

Use a named access register:

Least privilege matters because a correctly masked recording can still expose business processes, customer journeys, private page structure, or support context. Decide whether contractors may view recordings, whether links may be shared, whether downloads are permitted, and how access is removed when work ends. Include the tool in the marketing handoff pack and the software exit packet.

Launch as a bounded pilot

Start with the fewest pages and shortest useful collection window. Record the tag version, consent configuration, masking selectors, included and excluded paths, access list, retention assumption, start time, and automatic review date.

Choose one of four decisions:

At the review date, connect each finding to evidence and a proposed change. A heatmap hotspot does not prove why someone clicked. A replay shows what the interface displayed and how one browser interacted with it, not what the visitor thought. Treat observations as hypotheses, then use the website-fix decision board to decide what deserves repair or a controlled test.

Keep an uninstall packet

Before launch, document how to stop collection. Include the code location, tag-manager container and trigger, consent integration, vendor project owner, connected advertising or analytics products, access-removal steps, deletion controls, export limits, retention behavior, and a verification test for pages where the tag should be gone.

After removal, repeat the rejected-consent and excluded-page network checks. Deleting a dashboard project is not proof that a tag stopped running, and removing a tag is not proof that previously collected data was deleted.

A useful heatmap setup is not the one that records the most sessions. It is the one that answers a defined question while proving what it observes, what it excludes, how consent changes its behavior, who can see the results, and when collection ends. If your team needs help governing measurement tools across its website and reporting stack, review Ocean Media's strategy and reporting service.