Website storage, analytics and consent

Storage used for support#

The installed widget uses localStorage for its opaque visitor identifier and sessionStorage for tab/conversation continuity on the website origin. It runs an installation check when loading. Public support requests can include the current path and query.

Browser continuity belongs to the website origin where the widget runs. Another domain, device or private session is not automatically the same visitor, and clearing local storage changes the local identifiers without deleting retained server content. A customer question can include personal details even when the stored identifier itself is opaque. Review the page paths and configured context too: query parameters can contain information your site should not unnecessarily send. Use stable public routes and avoid putting account secrets into URLs. Explain the support service separately from your site's optional advertising or measurement tools so visitors can understand what each interaction does.

Optional analytics on reesponder.com#

Optional marketing measurement uses Google Analytics, Microsoft Clarity and the site tracker after permitted analytics choice. Advertising storage and personalisation signals stay denied in this configuration. This setup is specific to Reesponder's marketing website.

When testing the Reesponder marketing site, optional collection should not start merely because the page rendered or the two-second desktop prompt appeared. The preference decision gates the configured measurement integrations. A visitor who rejects optional analytics can continue browsing and use essential site functions. The fact that the banner contains a compliance label is not a technical measurement test: inspect the actual consent state and outgoing requests. Likewise, this marketing-site implementation does not establish the consent rules for a customer's separate website. Your own trackers, plugins and consent manager need a review based on what they actually load and collect.

The visitor's choice is remembered#

The current marketing preference record is version 3 and valid for up to 180 days. Accept all, Reject optional and Preferences are the initial controls; Cookie preferences in the footer reopens them.

The saved marketing choice lasts for a bounded period and is checked before optional tools start on the next page. Test direct entry to a subpage as well as a link from the homepage: someone may first arrive through search on a guide or product page. A valid choice on the same marketing origin should remain effective across those routes. If a browser blocks the preference storage, collection should remain off rather than treating the failure as permission. To revisit the decision, use Cookie preferences in the footer. Closing an interface or scrolling the page is not the same as choosing optional analytics.

What the marketing integration limits#

Before enabling replay, inspect forms, embedded support, authenticated-looking content and any element marked sensitive. A mask should already be in place when collection starts, not added after a private value was captured. Marketing event labels should describe a permitted interaction such as navigation or a category selection rather than copy whatever the visitor typed. URL sanitisation also needs verification: query parameters and fragments can carry tokens or personal values even on an ordinary landing page. Keeping only the origin and path reduces that exposure for this integration. It does not automatically sanitise unrelated scripts installed elsewhere on the website.

Withdrawal and existing records#

Run withdrawal as a separate test from initial rejection. Allow optional analytics through Preferences, verify the allowed state, then withdraw it and inspect subsequent requests and known first-party storage. Navigate again to ensure the saved withdrawal persists. Records previously sent to the external services are not removed by a local switch. If a person asks about those records, identify the relevant processing service and request route instead of promising the preference screen erased history. Clearing widget storage is similarly a continuity reset, not a service-wide deletion request. Different purposes and record locations need different controls, even when they share the same browser.

Keep your own website configuration separate#

The official widget does not install Reesponder's marketing analytics or cookie interface onto your business website. Inventory your own scripts, plugins, embeds and consent controls. Note which code loads immediately, which waits for a saved choice and which may be injected by a CMS or tag manager later. If your integration has a deliberate support-loading policy, test that policy on direct entry and after navigation. A consent interface from one site cannot control a script independently published by another hostname or a different application.

Assign ownership for each integration rather than assuming one banner manages everything. A theme developer may publish support, a marketing administrator may manage tags and a third-party plugin may load its own resources. Use the browser's actual requests and storage to check the resulting behaviour. Document the purposes and data that your implementation actually uses through the appropriate business review. This guide explains current technical controls, not a certification or a substitute for reviewing your own processing arrangements. For a Reesponder-specific data question, use the Privacy Policy and processing agreement alongside your implementation details.

Reproduce a masking issue with synthetic content#

Create a test page state with an obvious fake value, such as a non-sensitive sample email, in the same element type as the reported issue. Test a normal form input, an editable control, embedded support and any sensitive-marked content relevant to the page. The mask needs to be present before replay starts. Record the chosen analytics state and the time of the synthetic interaction so it can be located without recording an actual customer account or private conversation as evidence.

Inspect both the initial page and content introduced later by your interface. A component can replace a protected element or render a value in a different place, so the test should follow the same sequence that exposed the report. Verify that event labels use permitted interaction names rather than copying editable text. Check a URL with a deliberately synthetic query or fragment to establish that this marketing integration sends origin/path instead of those values. Review unrelated measurement scripts separately. A successful masking check reduces a particular exposure; it does not prove that every service on the page receives only anonymous information.

Test expiry, storage failure and later changes#

A saved choice can be absent because the browser is new, storage is blocked or a previous record is expired or incompatible. Use separate test states to identify the reason instead of treating every visible prompt as failure to remember the visitor. On the same marketing origin, a valid compatible choice should carry into a direct subpage visit. On another origin or device, it is a separate browser state. Keep that distinction clear when comparing reports from a homepage visit and a guide opened in a private window.

For a failure report, record the origin, browser mode, chosen preference and whether the browser accepted the saved record. Optional collection should remain off when a valid allowed choice cannot be established. After a preference change, navigate and refresh to confirm that the new decision governs startup. Later withdrawal also needs a check of subsequent requests and controllable first-party storage, rather than only disappearance of the dialog. Do not manually alter production preference records to simulate permission for another user. Use controlled profiles and synthetic activity, then return to the intended choice through the supported interface.

Test all four consent states#

A useful test sequence has four profiles or clearly separated states: fresh browser with no choice, rejected optional analytics, accepted analytics and withdrawn analytics. In each, load a direct marketing subpage, navigate to another page, and inspect whether the expected optional requests occur. Use synthetic interaction data and avoid entering real customer records into a replay test. On your own website, perform a separate sequence for your consent manager and support-loading policy, because Reesponder's marketing configuration is not injected by the widget. Record which scripts are optional, which functionality is required and who maintains each configuration.

Verify the outcome and keep safe evidence#

Keep consent verification grounded in observable behaviour. Record the chosen state, page origin, test time and tool requests before and after navigation or withdrawal. Check direct visits, refreshes and expired saved preferences rather than evaluating only the banner's appearance. For a masking issue, provide a synthetic reproduction and the affected element type without sending real private content. The published Privacy Policy describes Reesponder's own processing; a customer's website disclosures also need to describe its own data choices. Treat support transcripts, optional marketing measurements and external business records as separate categories when investigating a personal-data question.