Further Cookies and Tracking Disclosure

For Community and Agency Partners

01 Purpose

This document describes the cookies, browser storage, server records, telemetry, and related tracking technologies used by the Further chat (Virtual Sales Assistant, or VSA) and related tools when deployed on a community or agency partner's website. It is intended as a configuration and disclosure reference for partner technical, marketing, privacy, and legal teams.

What you need to know. Further's consent controls apply when Consent-Required Mode is turned on for a community (see Section 8 ). With the mode off, Further operates as described in this document without waiting for a consent signal. If the law that applies to your visitors requires their permission first, turn the mode on and connect your consent platform. Section 8, under "Before permission," describes what occurs before a choice is reported.

02 Our role

Further provides software-as-a-service tools, including chat, lead capture, telephone attribution, and static webforms, that communities deploy directly or through agencies. The legal role of each party depends on who determines the purposes and means of the processing and on the governing agreements.

1. The community or other website operator ordinarily determines why and how visitor data is processed and, depending on the applicable statute, acts as the business or controller.

2. An agency may act on the community's behalf as a service provider or processor, or may have another role, depending on its authority, contractual relationship, and use of the data.

3. Further ordinarily processes visitor data on behalf of the contracting partner and, where applicable, as a downstream service provider or processor under the governing agreements.

The party responsible under applicable law must provide required notices and obtain or honor any required consent or opt-out choice. Further provides the technical capabilities described in this document and supports the responsible parties in fulfilling those obligations.

Further does not use a shared-domain visitor cookie to recognize the same visitor across different partner sites. The persistent visitor identifier is stored in localStorage on the origin where the Further script runs and is scoped to that origin and community. Further no longer sets the visitor identifier, or another visitor-recognition cookie, on api.talkfurther.com. Partners that previously allowlisted that domain in their consent tooling should remove it. Further does not combine or aggregate visitor data across partners for Further's own purposes. Visit records are associated with the community where they occur, and analytics and reporting are scoped to the applicable partner organization. When Consent-Required Mode is enabled, Further applies each consent category separately, as described in Section 8.

03 Categories used in this document

This document classifies each item according to its purpose. These categories do not, by themselves, establish whether Further suppresses the item for a particular community, which depends on whether Consent-Required Mode is enabled. Section 8 explains when Further applies a CMP or Global Privacy Control signal and when processing begins without one. A partner's consent platform may use different category names, and the partner is responsible for mapping its categories and applicable legal requirements to Further's categories and consent interface.

1. Strictly Necessary: Processing reasonably necessary and proportionate to deliver or secure the chat, form, or other function the visitor requests. Some technical initialization occurs before the visitor interacts because the widget loads automatically. Whether prior consent is required depends on applicable law and the specific implementation.

2. Functional: Enhance the user experience or remember preferences. Not strictly required for the service to operate.

3. Performance & Analytics: Processing used to measure visits, recognition, engagement, page and form activity, attribution, performance, and errors. This category includes measurement derived from identifiers that may serve a separate Functional purpose.

4. Advertising & Targeting: Used for advertising, conversion attribution, or remarketing.

A category describes an item's purpose. References in this document to processing after a specified permission apply only where Consent-Required Mode is enabled for the community. A consent category may govern one stage of a data flow without governing every stage. Browser storage, transmission to Further, retention in Further's systems, and transmission to another recipient are described separately where they differ.

The control a visitor must be given depends on applicable law, on the data and purpose involved, and on who receives it. Some processing requires the visitor's prior consent, some requires only that the visitor be given a way to opt out, and some may proceed on notice alone subject to minimization and contract requirements. Partners must map their own deployment and visitor population to the rules that apply to them. Additional requirements apply to "sale" and "sharing" of personal information, processing of sensitive personal information, and recognition of Global Privacy Control (GPC) signals broadcast by the visitor's browser.

04 What Further uses, by category

4.1 Strictly Necessary

The items below support the current visit, delivery of the chat or form, or a submission the visitor initiates. Some initialize automatically when the widget loads, before the visitor interacts. Section 8 separately identifies the requests, records, identifiers, and technical data that arise before the visitor grants non-essential permission.

1. Visit correlation identifier (visitUUID): Further creates a visit identifier when the loader initializes, before the visitor interacts with the chat. The client-side value is stored in sessionStorage on the origin where the Further script runs and lasts for the browser-tab session. It links requests and chat activity during that session to corresponding Visit, Visitor, and ChatUser records in Further's systems. The identifier does not directly contain a name, email address, or telephone number and is not used by itself to recognize the visitor on a later visit. It is treated as personal information while it can be linked to the visitor or associated records. Corresponding server records are retained as described in Section 7.

2. Chat-session state (eVsaSessionState:{communityId}): During the active chat, Further holds the visitor's answers in page memory and sends those answers, including care-related answers and contact information, to Further's servers as the visitor proceeds through the chat. Further stores the responses as chat answers and, after submission, on the Lead record; they are not stored on the Visit record. Where Functional processing is permitted, Further also writes the in-progress conversation, identifiers, and answers to localStorage to continue the experience. Without Functional permission, the browser-side answers remain only in page memory for the active interaction. Use during the current visit is Strictly Necessary; persistence or reuse across visits is Functional.

3. Lead identifier (leadID): When a visitor submits contact information and creates a lead, Further stores its database key for that lead. The key does not itself contain the visitor's name, email address, or telephone number, but it points to the lead record and is treated as a pseudonymous personal identifier. Use during the current visit to complete the visitor's requested interaction is Strictly Necessary. Reuse on a later visit to recognize or continue the existing lead is Functional. Where Consent-Required Mode is enabled, Further writes the key to localStorage only after Functional permission.

4. Form submission processing: Further processes the information needed to receive and act on a webform the visitor submits. This classification covers processing needed for the requested submission. It does not automatically include form-impression or engagement measurement, which is addressed under Performance & Analytics.

4.2 Functional

1. Returning-visitor recognition: Where permitted by the visitor's choice, Further uses the persistent visitor identifier, lead identifier, and chat-session state to recognize a returning visitor and continue that visitor's experience. Recognition may produce a shortened form, omit questions the visitor previously answered, prefill values, retain a preference to keep the chat closed, omit contact fields after a lead exists, and greet the visitor by name. It may also continue an existing lead across visits. It does not reopen the prior conversation. Measurement based on recognition is Performance & Analytics.

4.3 Performance & Analytics

These help the community and Further understand how the chat and related tools are used.

1. Visitor identifier (visitorUUID): The persistent client-side value is stored in localStorage on the origin where the Further script runs. It is not set as a cookie on api.talkfurther.com or another Further domain. Reusing the value to recognize a returning visitor serves a Functional purpose. New-versus-returning counts, engagement reporting, attribution, and other measurement derived from recognition are Performance & Analytics.

2. Visit record and browser information: Further creates a limited visit record when the loader initializes. After Performance & Analytics permission, the stored record may include the current page URL, referring page, full browser user-agent string, browser type and version, device type, screen dimensions, full IP address, campaign keyword, gclid and fbclid click identifiers, approximate IP-derived location, traffic-source information, and permitted host-page cookie values. Each chat step sends the full page URL to Further. Before Performance & Analytics permission, a click identifier appearing in that URL may be used temporarily in memory to select the chat flow but is not written to the Visit record. Further captures and stores gclid and fbclid with the visit record after Performance & Analytics permission. Viewport dimensions are transmitted but not stored. Screen dimensions are stored and are not used for device fingerprinting. Full IP address and referrer information may also be used for community-configured lead-suppression rules.

Because the current page URL is transmitted during initialization and retained with the visit record, partners should not place names, contact information, care needs, health information, or other sensitive values in page paths or query parameters on pages where the Further script loads.

1. Host-page cookie information: The Further client can read the complete document.cookie string accessible to JavaScript on the partner's page. When Consent-Required Mode is enabled, the cookie string is transmitted to Further only after Performance & Analytics permission. Further's server then filters it against a fixed allowlist before storing permitted values on the visit record. Further does not set the source cookies. An existing cookie can remain readable even if the partner later blocks the tool that originally created it. The partner must classify and control each source cookie according to its own purpose. The consent gate governing transmission to Further is Performance & Analytics, not the category assigned to the source cookie.

2. Chat-session and website telemetry: This processing includes page-view activity, form-impression and form-interaction activity, new-versus-returning counts, dwell time, engagement measurement, and RUM performance marks. When Consent-Required Mode is enabled, RUM performance marks are held in the browser and sent only after Performance & Analytics permission. Separately, on each page load the loader sends a track-website request whether or not permission has been given. Its application record contains the community, page path, product flags, and detected CMP status. The application record contains no Further-assigned visitor identifier, IP address, or cookies, although ordinary network requests expose request information to Further's infrastructure. The form-impression browser key is visit_interaction_{visitUuid}_{formUuid} and is stored in sessionStorage for the browser-tab session. It is used only for measurement, and the form works without it.

3. Sentry error monitoring: When Consent-Required Mode is enabled, browser-side Sentry does not load until the visitor grants Performance & Analytics permission. No Sentry telemetry leaves the browser before that permission. After permission, a production error may send the stack trace, browser context, page URL, IP address, community information, and internal identifiers such as the visit, visitor, and lead identifiers. No chat conversation content is sent through this integration.

4. Operational loader logging: Separate from Sentry, the Further loader can call Further's own logging endpoint before the visitor grants permission. A loader log or error can include the page URL, browser user agent, navigator vendor, message, and stack trace. When Consent-Required Mode is enabled and Performance & Analytics permission is withheld, the loader removes the page URL, user agent, and navigator vendor, so an entry carries only the entry name, message, and stack trace. Errors raised before the consent controls initialize, such as a failure to retrieve the chat configuration, include the page URL, user agent, and navigator vendor.

5. Telephone-number reservation and call attribution: Where the community enables telephone tracking, Further substitutes a tracking number for the community's number and temporarily reserves that number to the visitor. The reservation is released approximately five minutes after the visitor leaves the site. No persistent client-side phone-attribution identifier is stored. Reserving and releasing the number to make the requested calling function available is Strictly Necessary. Matching a resulting call to the originating visit for source and performance reporting is Performance & Analytics. Sending a call outcome to an advertising platform as a conversion is Advertising & Targeting.

4.4 Advertising & Targeting

1. Partner-configured analytics and advertising integrations: Where the partner configures Google Analytics 4, Google Tag Manager, Meta Pixel, Google Ads, or a similar integration, Further may send events and related information to the partner's configured account. Depending on the integration and settings, that information may include Further's visit and visitor identifiers, page URL, chat events and selections, including a selected care type, and, if the partner turns on that option, hashed name, email address, or telephone number. Google Ads conversion uploads use the most recent gclid captured within the prior 90 days or, only where no click identifier is available, hashed email address and telephone number. Further does not send fbclid to Meta.

Hashing contact information does not make it anonymous where the recipient can match the hashed value to an account or other information.

When Consent-Required Mode is enabled, Further sends configured GA4, GTM, and Meta events after Advertising & Targeting permission. Google Ads conversion uploads are not sent after the visitor declines Advertising & Targeting. Until a choice is recorded, a configured Google Ads upload can proceed. The partner controls the receiving account, audiences, retention, advertising features, and downstream uses.

These transfers may constitute targeted advertising, sale or sharing of personal information, or processing of sensitive personal information or consumer health data, depending on the data, configuration, recipient, jurisdiction, and use. Consent does not make a transfer permissible where the recipient's terms prohibit the information or use. Partners must not configure Further to send information that the recipient prohibits and must configure their notices, consent controls, opt-out mechanisms, receiving accounts, and downstream uses accordingly.

If the partner has not configured one of these integrations through Further, the Further widget does not make the corresponding dispatch. A partner may separately operate its own analytics or advertising tags on the same page. Those independent tags are outside the scope of this document.

Scope notes for partners: This document addresses U.S. and Canadian visitor-privacy considerations. Partners whose forms or chat flows collect information about care needs, mobility, cognitive status, health conditions, or similar matters should assess whether the information is sensitive personal information, consumer health data, or both. Those answers are sent to Further and stored as chat answers and, after submission, on the Lead record in every consent state. They may also remain in the visitor's browser when Functional processing is allowed. If the partner enables analytics or advertising integrations, chat selections, including care type, may also be transmitted to the partner's configured Google or Meta account. Partners should minimize the questions asked and should not configure Further to send care-related answers or contact information to an analytics or advertising provider unless the partner has confirmed that the transfer and intended downstream use are necessary, lawful, covered by the partner's notice and any required consent or authorization, and permitted by the recipient's terms. Further's tools are not designed for children or minors. Applicable age thresholds and required controls vary by jurisdiction and may restrict targeted advertising or sale or sharing of a minor's personal information. Partners must assess the requirements applicable to their audience and configure their deployment accordingly.

Quick reference for partner configuration

The table below summarizes the browser storage, server records, request information, telemetry, and partner-configured integrations relevant to a partner's consent and disclosure configuration.

How to read the consent column: The consent descriptions assume that Consent-Required Mode is enabled for the community.

05 Browser-facing and tracking services

The following services may receive or process information in the visitor-facing or tracking path. This table is not Further's complete subprocessor list. The consent conditions in the table apply where Consent-Required Mode is enabled.

Further also uses infrastructure providers, partner-directed webhooks sent through Svix, CRM integrations, Zapier, customer data feeds, offline conversion services, AI lead-summary providers, and other subprocessors according to the partner's deployment. Partner-directed webhooks, CRM connectors, Zapier, customer feeds, and AI-summary flows deliver lead information, including contact information and chat answers, when a lead is created, as the partner directs. Browser-derived information, including IP address, cookie values, approximate location, referrer, and URL parameters, is included only if Further previously collected it following Performance & Analytics permission. Recipient-side retention is governed by the receiving system. Partners must review each configured integration and its field mapping. Partners with implementation or diligence questions may contact Further Support. Further's current subprocessor list is available at trust.talkfurther.com.

06 Approximate geolocation

The Further backend derives approximate geolocation from the visitor's IP address using MaxMind's GeoLite2-City database. The database is queried locally on Further's servers; no visitor data is transmitted to MaxMind.

The data stored is approximate (typical accuracy: 50-100 km in the United States) and is derived at city or region level. Further does not collect GPS or device-reported location through this feature and does not intend this data to constitute precise geolocation as defined under applicable law, although accuracy is not guaranteed for any individual record. Further stores approximate location when the Visit record is created with Performance & Analytics permission or back-fills it after that permission is granted. Stored fields are city, postal code, country code, country name, and approximate latitude and longitude. Further may use the stored information for distance calculations, dashboard location and maps, location-based flow routing, AI lead context, CRM fields, exports, and customer feeds. Withdrawal is described in Section 8.

07 Data retention

Loader error logs and other Further operational logs are retained according to Further's operational log retention schedule. Sentry data is retained for 90 days at the organization level for both browser-side and server-side monitoring. Consent-audit records are retained with the related Visitor record so that Further can show the choices it received. Further retains CRM request payloads for 30 days. Recipient-side copies follow the receiving system's retention.

Data-subject requests are handled through the process in Section 9.

08 Working with a Consent Management Platform (CMP)

How Consent-Required Mode works

When Consent-Required Mode is enabled and no stored choice applies, the Further script initializes in a restricted state. The chat remains available. The script makes the requests and creates the records described under "Before permission" below. Other processing is enabled according to the visitor's reported choices, with each category applied separately.

When Consent-Required Mode is disabled, Further begins the processing described in this document when the applicable event occurs. Further does not use the partner's CMP signal or a Global Privacy Control signal to suppress that processing.

Withdrawal

Functional withdrawal: When Functional permission changes from granted to withheld, Further removes the persistent visitor identifier and the lead identifier from localStorage and resets the saved chat state for the community currently being viewed. Values in sessionStorage and in memory can remain until the current browser session ends. Records already held on Further's servers are retained as described in Section 7.

Performance & Analytics withdrawal: When Performance & Analytics permission changes from granted to withheld, Further updates its records as follows.

1. Removed: the stored IP address; approximate location (coordinates, postal code, city, country code, and country name); forwarded cookie values and cookie URL parameters; and the caller number on the link between a call and the visit.

2. Kept: the records of the visit, the visitor, the chat, any lead, and visit duration; page URL; referrer; user agent; device information; traffic source; screen dimensions; call identifiers; the caller's number in Further's own call log; the stored map image derived from the approximate location; and the cached session distance.

3. Deleted only if the visitor became a lead: recorded link clicks and page open and close events.

These changes apply when a previously granted permission is withdrawn through the partner's consent platform.

Information already shared

Withdrawal applies to information in Further's systems and the visitor's browser. Information already sent to a partner-configured integration or another recipient is governed by that recipient. Where a withdrawal or deletion must also be applied in those systems, the partner should address those copies directly.

Category-enforcement status

A partner's CMP reports Functional, Performance & Analytics, and Advertising & Targeting separately. Where Consent-Required Mode is enabled, Further applies each category independently. Withholding one category does not withhold another. Further records the reported choices by category for the consent audit trail.

How partners configure the mode

The visitor's choice is reported to Further at runtime through Further's consent interface, allowing a change to be applied during the session rather than only on a later page load.

1. Enable the mode. To enable Consent-Required Mode for a community, go to Dashboard, Settings, Web Assistant, Visitor Consent and turn the mode on. The mode is off by default, so Further's product behavior does not change until it is enabled. If the option is unavailable, contact Further Support. If applicable law or the partner's policy requires pre-consent suppression and Consent-Required Mode is not available and enabled, do not install the Further script on that community's pages, or keep it blocked through the partner's consent platform, until the mode is available and enabled.

2. Keep the script unblocked. Once the mode is enabled, the script must be present on the page to receive the CMP signal and detect Global Privacy Control. Do not assign the Further script to a gated category in the partner's consent platform, because a blocked script cannot receive or apply the visitor's choice.

3. Connect the CMP. Further currently provides direct bridges for CookieYes, Cookiebot, OneTrust, Complianz, Osano, TrustArc, Quantcast Choice, Termly, Iubenda, Usercentrics, WebToffee, and CookieFirst. The Quantcast bridge listens through the IAB TCF v2.2 API but applies a choice only when the platform is Quantcast Choice; Further does not provide a generic bridge for other TCF platforms. A bridged CMP supplies values for all three Further categories. Partners must configure all three categories in their CMP and test the result. Unless Further confirms a direct bridge for the partner's platform, the implementation must call setConsent. Enabling Consent-Required Mode without a working signal leaves Functional, Performance & Analytics, and Advertising & Targeting withheld for every visitor, including visitors who accept. The chat remains available, and the processing described under "Before permission" below continues.

4. Report changes. setConsent may be called before Further finishes initializing. Further retains the most recent call received before initialization and applies that call when initialization completes. If more than one call is made before initialization, only the last call is applied. Repeating the same choice does not create a duplicate consent-audit record.

5. Apply GPC. When Consent-Required Mode is enabled, a Global Privacy Control signal present when the script initializes sets Functional, Performance & Analytics, and Advertising & Targeting to withheld and cannot be overridden through setConsent. Further reads the signal during initialization. When Consent-Required Mode is disabled, GPC does not affect Further's processing.

6. Store the choice. Further stores the visitor's latest reported choice in localStorage on the origin where the script runs, using the key further_consent:<communityId>, for 365 days from the most recent report. The key is scoped to the community. A different domain or subdomain cannot access the stored choice.

// visitor accepts 
 window.FurtherSiteManager.setConsent({   
   functional: true, analytics: true, advertising: true 
 });

// visitor declines everything: report all three categories as false
 window.FurtherSiteManager.setConsent({
   functional: false, analytics: false, advertising: false 
 });

How to report each category

For a direct setConsent call, a category is granted only when the implementation reports the literal Boolean value true. A false, omitted, undefined, or non-Boolean value leaves that category withheld. Report all three categories on every call and do not pass strings such as "true" or "false" in place of Boolean values. A call with an empty object grants no category, and passing null or a value that is not an object throws a TypeError. setConsent returns no value.

Before a choice is reported

With Consent-Required Mode on and no applicable stored choice or reported signal, Functional, Performance & Analytics, and Advertising & Targeting remain withheld, except that a configured Google Ads upload follows the rule described in Section 4.4. For a direct setConsent call, only a literal Boolean true grants the reported category. With the mode off, Further permits all categories.

What remains available

If a visitor withholds one or more categories, the chat remains available. Further applies each of the visitor's choices separately. The visitor can continue to chat and submit contact information.

Before permission

With Consent-Required Mode on and no non-essential permission, the Further script makes the requests needed to display and operate the chat. Every web request necessarily carries the visitor's IP address and browser user agent. On each page load, the script retrieves the chat configuration and sends the page URL. It also creates Visit and Visitor records under one-time identifiers, without the gated browser details and without linking the visitor to an earlier visit. When the chat opens, the script creates a ChatUser record linked to that visit and retrieves the first question. As the visitor answers, the answers and contact information are sent to Further so the chat can respond and the visitor's request can be completed. A submitted lead is delivered to the partner-directed integrations described in Section 5. Loader diagnostic entries are handled as described in Section 4.3. The loader also sends the track-website request described in Section 4.3. A configured Google Ads upload follows the rule described in Section 4.4. Where enabled, reCAPTCHA loads when a form renders and the YouTube player loads when a video gallery renders, as described in Section 5. Sentry is not started, and RUM performance marks are held in the browser, until Performance & Analytics permission. The resulting records are retained as described in Section 7.

Consent across sites and communities

Further stores each community's consent choice under a community-specific key on the origin where the script runs. Different domains and subdomains cannot access one another's stored choice. Communities on the same origin still use separate Further keys. Partners relying on homepage-to-community attribution should configure each relevant origin and community consistently. Suppression on either side can interrupt the attribution chain.

Partners with implementation requirements or deployment-specific questions should contact Further Support using the contact information at the top of this document.

09 Visitor data requests

Visitors whose data has been collected through a Further-enabled community website may have rights under the privacy law applicable to them. Depending on the jurisdiction, those rights may include:

1. The right to know what personal information has been collected (CCPA, and analogous laws in the growing list of US states with comprehensive privacy statutes; access rights also exist under Canadian PIPEDA and Quebec Law 25)

2. The right to request deletion of personal information (CCPA/CPRA and analogous state laws); Further will work with the partner to fulfill deletion requests

3. The right to correct inaccurate personal information (CPRA and most newer state laws)

4. The right to opt out of "sale" or "sharing" of personal information, and of targeted advertising (CCPA/CPRA; analogous rights under most newer state laws)

5. The right to data portability (CPRA, CPA, VCDPA, CTDPA, and others)

For processing controlled by a community or other website operator, visitor requests should ordinarily be received and verified by that entity or its designated agency. The verified request may then be forwarded to Further for fulfillment.

To submit a request to Further on behalf of an identified visitor, please contact us at the privacy address in Section 11 with:

1. The community / property the visitor interacted with

2. Identifiable information about the visitor (visit date, lead identifier if known, email or phone if provided)

3. The type of request (access, deletion, correction, opt-out, portability)

Standard fulfillment turnaround: Further will work with the partner to complete its part of a verified request promptly so that the community can meet its deadline under applicable law. The community remains responsible for the deadline under applicable law, which is measured from the community's receipt of the request rather than from the date verification is completed. Further will work with the partner to meet shorter turnarounds where the partner has committed to them.

10 Changes to this document

This document is reviewed and updated as the Further product evolves and as the applicable legal landscape changes. The "Last reviewed" date at the top reflects the most recent review. Material changes are logged below.

11-02-2026 (changes from the version effective 06-12-2026)

1. Updated the visitor identifier description to confirm that the persistent visitor identifier is stored on the partner's origin.

2. Distinguished in-session operation, returning-visitor recognition, and measurement by purpose.

3. Updated the description of pre-permission initialization, visit-record fields, host-page cookie handling, loader logging, and Sentry.

4. Updated telephone-number release timing and classified number reservation, attribution, and advertising conversion uploads separately.

5. Expanded the disclosure of browser-facing services and partner-configured analytics and advertising recipients.

6. Updated the description of consent withdrawal.

7. Updated Consent-Required Mode to apply each consent category separately, and updated GPC handling, consent storage, the supported CMP list, and direct setConsent instructions.

8. Updated the description of approximate geolocation.

9. Updated retention information.

10. Updated how Further supports partners with visitor data requests.

11 Contact