Data Privacy Statement for the FAIND Snippet

Last updated: 13 July 2026

This statement describes, at a technical level, exactly what the FAIND snippet — the one line of JavaScript a customer embeds on their own website — does and does not do with respect to a site visitor's personal data and terminal equipment. It is written so that a customer's data protection officer (DSB) or privacy team can classify the snippet in a consent management platform and document its lawful basis. It reflects the snippet as verified in the FAIND source code as of the audit date below; it is the updated English successor to an earlier German overview, and it supersedes any prior statement that described the snippet as using localStorage (see section 2). For processing that happens on FAIND's own marketing and application websites — as opposed to the snippet running on the customer's site — see Privacy Policy. For the data processing agreement, see Data Processing Agreement; for the technical integration guide, see Snippet Documentation and Implementation Guide.

1) Cookies — none

The FAIND snippet sets no cookies. It does not read, write, or delete any cookie on the visitor's browser. This has been confirmed in the source code.

• Install form: <script async src="https://app.getfaind.com/geo/snippet.js.php?d=DOMAIN_ID&t=TOKEN"></script>. The script file itself is served with Cache-Control: no-store. If the domain ID and token do not validate, the script logs a console.warn and performs no further action (no-op).
• Historical note: a stray PHPSESSID cookie that had leaked from a shared configuration path was removed on 2026-07-09. Since then the snippet delivery path sets no cookie of any kind.

2) On-device storage — none

The snippet writes nothing to, and reads nothing from, the visitor's device. Specifically it uses:

• No cookies (see section 1).
• No localStorage. Two functional keys previously existed. They were removed on 2026-07-10 and replaced by in-memory, per-page-load handling — nothing persists on the device between page loads.
• No sessionStorage, no IndexedDB.
• No device or browser fingerprinting of any kind.

Supersession: because localStorage was removed on 2026-07-10, any earlier FAIND overview stating that the snippet "uses localStorage" or relies on "functional local storage keys" is no longer accurate and is superseded by this statement. As of the current version, the snippet neither stores information in nor gains access to information already stored in the visitor's terminal equipment.

3) What the snippet reads from the page

To detect when the customer's own public page content changes — the purpose of the product — the snippet reads structural content from the page's main content region. It does not read any visitor-entered data.

• Main content only: it works from the page's main content, deliberately excluding cookie / consent / GDPR banner containers and non-content elements such as scripts, styles, navigation, footer, and ads.
• Page metadata: the page title and heading.
• Technical content fingerprint: from that cleaned content it derives change-detection signals only — a technical content fingerprint used solely to tell whether the page changed. These signals describe the page, not the visitor, and contain no personal data.
• What it never touches: it reads no form inputs and no input values. It never accesses data a visitor has typed.

The snippet is designed to keep the customer's Knowledge Graph current and to measure AI-driven visits in aggregate; it does not read or store any visitor-entered data.

4) Data transmitted to app.getfaind.com

All network calls go to app.getfaind.com only. Every call is asynchronous and non-blocking, with a short timeout; the page is never held up. Under a strict Content-Security-Policy the snippet fails closed and the rest of the page is unaffected. The following lists every category of data that is sent and its personal-data assessment.

• Page URL / path (query parameters stripped in the browser): Purpose: identify which of the customer's pages the signal is about. Personal-data assessment: arbitrary or PII-bearing query parameters are stripped client-side before sending, so they never leave the visitor's device (change effective 2026-07-12). Stored server-side: yes, at page level only (see section 5).
• Technical content signals: a technical content fingerprint used only to detect changes. Purpose: detect whether the customer's page content changed. Personal-data assessment: describes the page, not the visitor; no personal data. Stored server-side: yes, page-level change-detection signals.
• User-Agent: Purpose: classify the request as bot vs. human so AI-driven visits can be measured in aggregate. Personal-data assessment: a User-Agent string may constitute personal data; used only for bot/human classification. Stored server-side: no — the raw User-Agent is not retained; only the derived category is kept.
• IP address: Purpose: inherent to any HTTP request (as with any embedded image or script). Personal-data assessment: an IP address is personal data, but it is transient here. Stored server-side: no — the IP is not stored in the analytics for the snippet flow, and it is not used to build a visitor identifier.

The snippet measures AI-driven visits only in aggregate. No visitor identifier is transmitted, there is no cross-site tracking, and nothing is stored on the visitor's device.

5) Server-side storage

What FAIND stores from the snippet flow is page-level, not a visitor profile:

• Page change-detection signals: append-only records keyed to the customer's own content, used only to detect changes, with a short de-duplication window. No visitor data, no per-visit counter.
• Page content: the customer's own public page content, kept so the Knowledge Graph stays current; only the newest snapshots per page are retained. No end-visitor PII.
• Aggregated traffic counters: counts keyed by day, page/host, and source classification. There are no per-visitor rows, no raw IP, and no raw User-Agent.
• Not stored for the snippet flow: raw IP, raw User-Agent, any visitor identifier, any cookie, or any cross-site profile.

6) Consent classification (§25 TDDDG, GDPR)

This is the section a DSB uses to classify the snippet in a consent tool.

• §25 TDDDG is not triggered. §25 TDDDG (formerly §25 TTDSG) governs the storing of information in, or gaining of access to information already stored in, the visitor's terminal equipment. Because the snippet stores nothing on and reads nothing from the device (no cookies, no localStorage, no sessionStorage, no IndexedDB, no fingerprinting — see sections 1–2), §25 TDDDG does not apply.
• No consent-banner entry is required for the snippet. Since §25 TDDDG is not engaged, the snippet does not need its own entry in a cookie/consent banner. A transparency note in the site's privacy policy is sufficient.
• Lawful basis for the transient request metadata: processing of the technical request metadata (e.g. IP inherent to the request, User-Agent for bot/human classification) rests on Art. 6(1)(f) GDPR (legitimate interest in measuring AI visibility and keeping the AI-readable Knowledge Graph current) or, within the customer relationship, on the data processing agreement under Art. 28 GDPR.
• If your consent tool requires the snippet to be listed anyway: the recommended category label is "strictly necessary / technical", with consent not set as a precondition for loading it.

7) Retention and hosting location

• Hosting location: the snippet endpoints and the associated storage run on EU/German infrastructure — DigitalOcean, LLC (United States; EU hosting region Frankfurt / FRA1, Germany; further particulars on request) — fronted by Cloudflare, Inc. (United States; further particulars on request).
• Retention — key distinction. Nothing the snippet handles carries a visitor identifier, so none of it is personal visitor data; the retention below is therefore driven by usefulness, not by a personal-data time limit:
  • Page change-detection signals and Knowledge Graph artifacts: these are derived from the customer's own public pages and contain no visitor identifier, no raw IP, and no User-Agent. Only the newest snapshots per page are kept; the signals are retained for the duration of the subscription and are deleted or anonymized within 30 days after termination.
  • Aggregated traffic statistics: counts by page / host / source, with no visitor identifier, no raw IP, and no raw User-Agent. Because they carry no personal visitor data, they may be retained as long-term statistical records, including in anonymized / aggregated form.
  This is the operator's retention policy, not a contractual guarantee; a purge job is being implemented to enforce the personal-data limits described in Privacy Policy. Note that the snippet flow itself stores no server logs of visitor IP / User-Agent tied to a visitor and creates no FAIND own-site lead / journey data — those personal-data pockets, and their shorter limits (server logs 90 days; own-site lead / journey data deleted or anonymized after 24 months of inactivity), live on FAIND's own sites and are governed by Privacy Policy.

8) Data minimization

The snippet is built to minimize personal data by design:

• Query parameters stripped in the browser: arbitrary or PII-bearing query parameters are removed in the browser before any transmission, so they never leave the visitor's device (effective 2026-07-12).
• No form inputs and no input values are ever read.
• No visitor identifier is created or transmitted — no cookie, no local identifier, no fingerprint — so there is nothing to link one visit to another or across sites.
• User-Agent and IP are not stored in the snippet analytics; only the derived bot/human category and aggregated counters are kept.

For reference, the relevant change history is: cookies removed 2026-07-09; localStorage removed 2026-07-10; URL query parameters minimized 2026-07-12.

9) Roles and lawful basis

When the snippet runs on a customer's website, FAIND acts as the customer's processor for the page-level data it collects on the customer's behalf, under a data processing agreement (Art. 28 GDPR; see Data Processing Agreement). The customer remains the controller for the processing on its own site and is responsible for its own privacy-policy transparency note and for the lawfulness of the content served. Any limited processing that FAIND carries out in its own legitimate interest rests on Art. 6(1)(f) GDPR.

10) Contact for DSB questions

For data-protection questions about the snippet — including confirmation of the technical facts above for a consent-tool assessment — contact the provider:

leif ventures UG (haftungsbeschränkt)
Karl-Marx-Str. 250, 12057 Berlin, Germany
Commercial Register: HRB 170145 B, Local Court (Amtsgericht) Charlottenburg
Represented by: Leif Pritzel
Data Protection Officer: none appointed (not legally required); privacy contact: Leif Pritzel
Email: privacy@getfaind.com
Competent supervisory authority: Berliner Beauftragte für Datenschutz und Informationsfreiheit