Further — Cookies and Tracking Disclosure

For Community and Agency Partners

1. Purpose

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

2. Our role

Further provides software-as-a-service tools (chat, lead capture, phone attribution, static webforms) that partner communities embed on their websites. With respect to data collected about visitors to those websites:

• The partner community is the business (the data controller) under CCPA/CPRA and analogous state laws — they determine the purposes and means of processing.

• Further acts as a service provider — we process visitor data on the partner's behalf and under their instructions, pursuant to our service agreement.

• The partner is responsible for obtaining visitor consent on their site for any tracking categories that require it under applicable law.

• Further provides the technical capabilities described in this document and supports the partner in fulfilling their compliance obligations.

In certain configurations, Further may recognize the same visitor across different partner sites, for example, where a community operates a homepage that links visitors to its individual community websites. This cross-site recognition occurs because the visitor identifier is set on Further's shared service domain (api.talkfurther.com) and is used to recognize returning visitors, including where a visitor's first visit occurred on a different site. Further does not combine or aggregate visitor data across partners for Further's own purposes: visit records are tied to the specific community on which they occur, and analytics and reporting are always scoped to the individual partner's organization. This recognition depends on third-party cookies and therefore operates only in browsers that allow them (Safari and Firefox block third-party cookies by default; Chrome currently allows them by default). Further is rolling out a Consent-Required Mode on a staged basis. As the feature is made available to a partner's organization, it can be enabled by the partner through the Dashboard. When enabled, the mode disables visitor recognition for all visitors on that community, including recognition of returning visitors on the same site as well as cross-site recognition, until the visitor consents.

3. Categories used in this document

This document uses the four-category model that is the de facto industry standard for cookie and tracker classification — used by the major enterprise Consent Management Platforms (OneTrust, TrustArc, Cookiebot, Osano) and aligned with the IAB Tech Lab's Global Privacy Platform (GPP) signal taxonomy. The model is jurisdiction-neutral; the legal obligations attached to each category vary by state.

• Strictly Necessary — required for the service the visitor has explicitly requested. The chat or form will not function without these. Generally permitted without prior consent in all US jurisdictions.

• Functional — enhance the user experience or remember preferences. Not strictly required for the service to operate.

• Performance & Analytics — measure how visitors interact with the chat (page views, dwell time, returning-visitor recognition, error monitoring).

• Advertising & Targeting — used for advertising, conversion attribution, or remarketing.

In jurisdictions with enhanced consumer privacy protections — including (without limitation) California, Colorado, Connecticut, Virginia, and the growing list of US states with comprehensive privacy statutes, as well as Canadian frameworks (PIPEDA federally and Quebec's Law 25) where partners deploy to Canadian visitors — Performance & Analytics and Advertising & Targeting items typically require an affirmative visitor choice (opt-in or opt-out, depending on the jurisdiction and the activity) before they may fire. 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.

4. What Further uses, by category

4.1 Strictly Necessary

The following are required for the chat and form tools to function for a visitor who has chosen to use them. They are not set unless the visitor engages with the chat (or until they are needed for the requested service).

• Visit correlation identifier — a session-scoped UUID used to associate the visitor's chat actions with the corresponding backend records during a visit. In the current implementation this identifier is created when the loader script initializes (i.e., before the visitor has interacted with the chat); pending product changes will defer creation until first interaction, at which point it will be strictly necessary in all jurisdictions.

• Chat session state — stores the in-progress conversation, the answers the visitor has provided, and the chat user identifier. Active session state (used to continue a conversation across page reloads during the same visit) is strictly necessary to deliver the chat service the visitor has requested. Where the same storage is also used to recognize the visitor on a future visit, that return-visit component is treated as Functional rather than Strictly Necessary and is subject to the consent posture for the Functional category in the applicable jurisdiction.

• Lead identifier (post lead creation) — persists the identifier of a lead the visitor has explicitly created so the conversation can be continued on return visits.

• Form submission processing — the data needed to receive and process a webform the visitor submits.

4.2 Functional

• Phone-call attribution identifier — when phone-number tracking is enabled by the community, links an inbound call placed to the tracking number that Further displays in place of the community's own number back to the originating visit, so the community can attribute lead sources.

4.3 Performance & Analytics

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

• Visitor identifier (visitor-uid / cached UUID) — distinguishes new visitors from returning visitors. Set as a cookie on api.talkfurther.com and cached in browser storage on the partner site. Used for cross-visit recognition within the same partner site.

• Visit record — created when the Further loader script initializes on a page. Includes: browser type and version, screen and viewport size, referring page, current page URL, IP address, and approximate IP-derived location (see § 6).

• Forwarded host-page cookies — the Further loader reads the cookies available to it on the host page (not limited to a fixed list; while these are most often analytics and attribution cookies such as Google Analytics or VWO, any cookie readable on the page may be read and forwarded) and stores their values alongside the visit record. We do not set these cookies — they originate from the host page and its tag manager. Each forwarded cookie should be categorized according to its own source: if the partner's CMP blocks a source cookie before consent, Further will not receive it; if consent is given, the value is forwarded alongside the visit record and the data flow should be treated according to that cookie's original category.

• Chat-session telemetry — page-view beacons (floating chat only), form-impression beacons, returning-lead recognition, and dwell-time / engagement measurement.

• Operational error monitoring (Sentry) — when the widget encounters an error in production, error context (stack trace, browser context, and internal reference identifiers such as the visit and visitor UUIDs, the lead identifier, and the community name) is sent to Sentry to help us diagnose issues. The Sentry integration is configured to scrub personal information, and no conversation content is sent.

4.4 Advertising & Targeting

These are set only when the community has configured them via Further's analytics configuration.

• Google Analytics 4 / Google Tag Manager events — when the community has configured a GA4 measurement ID or a GTM container in Further, our widget dispatches events into the community's GA4 / GTM. This may cause Google to set its standard cookies (_ga, _gid, _gat, and similar) on the partner site, per Google's normal behavior. The data flow and Google's retention/use of these cookies are governed by Google's privacy terms and the community's GA4 / GTM configuration. If the community has enabled Google Ads, Google Signals, or remarketing features, this dispatch may constitute a "sale" or "share" of personal information under CCPA/CPRA; in that case the community should gate the events behind Advertising & Targeting consent and ensure its "Do Not Sell or Share My Personal Information" link honors the visitor's choice.

If the community has not configured a Google Analytics or GTM integration, no Advertising & Targeting items are set by the Further widget.

Quick reference: what to configure in your CMP

The table below summarizes the cookies, browser-storage keys, and host-page cookies relevant to a partner's CMP configuration. For each item it gives the storage mechanism and lifetime, when in the visitor's session it fires, and what the partner should configure in their CMP. Items marked "under review" are subject to engineering remediation; partners deploying in opt-in jurisdictions should treat those items as the strictest applicable category until remediation is complete.

Scope notes for partners. This document and the table above describe US and Canadian visitor-privacy considerations. Partners whose webforms collect health-adjacent information (care needs, mobility, cognitive status) should treat that data as potentially "sensitive personal information" under CCPA and several other state laws; sensitive PI has separate consent and use-restriction requirements that the partner must address in their own privacy notice. Further's tools are not intended for visitors under 13; partners must ensure no minor data is submitted.

5. Third-party vendors

Vendors with whom data may be processed in connection with the Further service:

Additional vendors may be engaged for specific communities under separate written agreement. Communities can request a vendor list specific to their deployment.

6. 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 intended to fall outside the "precise geolocation" thresholds defined by US state privacy laws — including approximately 1,850 feet / 1,000 meters under California's CPRA, and approximately 1,750 feet under the Colorado, Connecticut, Virginia, Maryland, and Oregon statutes. Stored fields are: city, postal code, country code, country name, and approximate latitude/longitude coordinates.

7. Data retention

Data subject deletion or anonymization requests are handled through the process in § 9.

8. Working with a Consent Management Platform (CMP)

When consent-required mode is enabled for a community, the Further loader script limits collection to what's necessary to show the chat until the visitor signals consent - typically through the partner's Consent Management Platform (CMP). The visitor can open, ask, and answer, submit forms, and schedule tours, while non-essential tracking is held back until consent is granted. If consent is later withdrawn, Further anonymizes the tracking data collected while consent was active and clears the cross-visit identifiers from the browser. With the mode off (the default), nothing changes and the loader performs all of the § 4 operations on load as before.

In this v1, consent is treated as a single on/off signal - granted or withheld as a whole, rather than per category. A CMP can report the visitor's choice per category (functional / analytics / advertising), and Further records it that way for the audit trail and for future per-category enforcement, but today any withheld category withholds consent entirely.

The mode is reported to Further at runtime through a small JavaScript API, so consent changes are honored within the session rather than only on subsequent page loads. The steps below describe how a partner configures their CMP to use it.

What partners using a CMP should do today

For visitors who require pre-consent suppression of non-Strictly-Necessary categories (typically in enhanced-protection states such as California, Colorado, Connecticut, and Virginia, or where a Global Privacy Control signal is present):

1. Enable the mode. To enable Consent-Required Mode for your community, go to Dashboard → Web Assistant → Visitor Consent and toggle it on. The mode is off by default, so partners are unaffected until they opt in. If you don't see the option, it may not be enabled for your organization yet — contact support to turn it on (see Section 11).

2. Report consent changes from your CMP's "consent updated" handler by calling setConsent (snippet below).

3. No need to wait for the widget. setConsent may be called before Further finishes initializing — the call is buffered and applied once it's ready. CMPs that re-fire setConsent on every page load are fine; repeated identical calls are idempotent (no duplicate audit rows, no churn).

4. GPC is honored automatically. If the browser sends Global Privacy Control (navigator.globalPrivacyControl === true), the gate is forced closed and setConsent cannot override it. No CMP action needed.

5. The choice persists. Further stores the latest choice in localStorage, scoped per community (further_consent:<communityId>), for 12 months. A returning visitor keeps their choice without the CMP re-asserting it.

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

// visitor rejects — any category false closes the gate
window.FurtherSiteManager.setConsent({ functional: true, analytics: false, advertising: false });

v1 semantics (binary): any category explicitly false → withheld; all provided categories truthy → granted. The per-category shape is honored for storage today and lets us enforce per-category later without breaking your integration.

Default state with the mode on: withheld until setConsent grants (or a persisted prior grant is found). Mode off: always granted (unchanged behavior).

For visitors who do not consent to all categories used by the widget, the Further tools will remain loaded and interactable, but only strictly necessary functionality will be served for that visitor's session — that is, the chat loads and stays usable and the visitor can still submit their contact details, while non-essential functionality is withheld.

Consent scoping across related sites. A visitor's consent choice is bound to the domain on which it is given. Consent collected on one domain (for example, a partner's homepage) does not carry over to a community site on a different domain, which must collect its own consent. Further's browser storage is scoped per community, so a homepage and a community that share one domain maintain separate Further storage but share the same domain-level consent state. Partners that rely on homepage-to-community visit attribution should configure consent, including the Consent Required mode once it is available to their organization, consistently across the homepage and the community sites it links to; if tracking is suppressed on either property, the cross-site attribution chain breaks.

What's planned

Native CMP integration is in active product development at Further. Planned capabilities include:

• Detection and recognition of TCF v2.2, OneTrust, Cookiebot, and other CMP consent signals on page load

• Selective enablement of categories within a single page load — so features from Performance & Analytics can remain available to a visitor even when Advertising & Targeting consent has not been granted. Currently, a visitor should consent to all categories for us to enable Performance & Analytics features.

Partners with specific implementation requirements (specific CMP integrators) or timelines should contact us — see § 11.

9. Visitor data requests

Visitors whose data has been collected through a Further-enabled community website have the rights afforded by applicable US and, where relevant, Canadian privacy laws, including:

• 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)

• The right to request deletion of personal information (CCPA/CPRA and analogous state laws); Further will work with the partner to fulfill deletion requests, and depending on the system involved, fulfillment may currently require manual operations by Further or vendor support rather than self-service deletion

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

• 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)

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

Because Further is a service provider and the community is the business, visitor requests should ordinarily be received and verified by the community. The community can then forward the verified request to Further for fulfillment. To submit a request to Further on behalf of an identified visitor, please contact us at the privacy address in § 11 with:

• The community / property the visitor interacted with

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

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

Standard fulfillment turnaround: within the timeframe required by the applicable law (typically 45 days under most US state laws, extendable once by an additional 45 days where permitted), measured from a complete, verified request. 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.

11. Contact