Cookie and tracking notice

DRAFT — not legal advice — review by counsel required.

Who publishes this. This notice is for a Demander customer to publish on its website when it installs the Demander tracking snippet. The customer is the controller, and Demander is its processor (dpa.md). Replace the bracketed parts, and link this notice from your consent banner and privacy notice.

How the snippet behaves. Everything below describes packages/tracker:

lib/consent.ts: consent gating and the GPC/DNT signals;
lib/url.ts: click ids;
sdk.ts: storage keys;
services/tracking.ts: the server side.

---

Website analytics and company identification on [website]

We, [company], use Demander to understand which companies visit our website and which campaigns bring them. Here is what happens, depending on your choices.

What the snippet stores on your device

Demander uses no cookies. It may use your browser's local storage or session storage. The keys are:

Key	Storage	What	When
`dmdr_a`	localStorage	A random visitor id	Only after you accept analytics (or if this site runs in "off" mode, see below)
`dmdr_s`	sessionStorage or localStorage	A random id for this visit	sessionStorage before consent in "balanced" mode; persistent after analytics consent; not stored at all in "strict" mode before consent
`dmdr_l`	same as `dmdr_s`	The landing page's campaign parameters (UTM; ad click ids only with marketing consent)	With the visit id

What we record

Pages and events. The pages you view, with time, referrer and campaign (UTM) parameters.
Country, derived from your IP address.
A truncated, non-reversible fingerprint of your IP address. It is a hash with a secret salt that changes every day (ipHash). Your full IP address is not stored.
In strict mode before consent, the visit is counted with a daily-rotating key. The server computes it from the IP address, the browser's user agent and the site, with a secret salt. Nothing is stored on your device, and the key cannot link visits across days.
The company you are visiting from, where lawful (see below). The identification is company-level only: it never says which person visited.

Ad click ids in the landing URL:
Google: gclid, gbraid, wbraid, dclid;
Microsoft: msclkid;
Meta: fbclid;
TikTok: ttclid;
LinkedIn: li_fat_id;
Reddit: rdt_cid;
X: twclid;
Snap: sccid;
Pinterest: epik;
Yandex: yclid.

We use them to report conversions to the ad platform that brought you.

Linking your visits to you. If you identify yourself, for example by signing up or submitting a form, your visits are linked to that identity.
The e-mail address you type into a form on this site. This happens only if we enabled form capture; no other form field is ever read.

Global Privacy Control and Do Not Track

If your browser sends GPC (navigator.globalPrivacyControl) or Do Not Track, the snippet treats it as no marketing consent, whatever you clicked:

no click ids;
no linking of visits to you;
no form e-mail capture.

Your contact record is also never used to build lookalike audiences on ad platforms (Demander's seed rules exclude anyone who sent GPC on a linked visit).

Company identification

We identify the company behind a visit (not the person) from:

IP ranges learned in our own Demander workspace. These come from people at that company who identified themselves with a business e-mail. A range is trusted after two different contacts and deleted after 180 days without new evidence. Only the prefix (/24 or /48) is kept.
The public registry record of the IP range (RDAP), queried through rdap.org and the regional internet registries.
Reverse DNS.
[If enabled:] IPinfo / Dealfront, which receive the IP address to return the company.

This runs only when [we have completed a legitimate-interest assessment for it / you gave marketing consent], and never when your browser sends GPC.

This site runs Demander in [strict / balanced / off] mode:

Mode	Before you choose	After analytics consent
strict (default)	Nothing stored on your device; the server counts the visit with a daily-rotating key	Persistent random id (`dmdr_a`)
balanced	A per-visit id in sessionStorage	Persistent random id
off	Persistent random id immediately. Only use this where consent is collected by another tool before the snippet loads, or is not required.	—

Marketing consent (click ids, linking visits to you, form e-mails) is separate from analytics consent, and GPC/DNT always override it.

Recipients, retention and your rights

Who receives the data. Demander ([legal entity], EU hosting) processes it for us. Ad platforms receive conversion events only with your marketing consent.
How long we keep it. Visit data is kept for [retention you set] and deleted with our Demander workspace. Learned IP ranges are deleted after 180 days without new evidence.
Your choices. You can withdraw consent at any time in [consent settings link].
Contact. For access, deletion or objection, contact [company privacy contact]. Our full privacy notice: [link].

---

Notes for the customer and for counsel

ePrivacy Art. 5(3). Local and session storage count as "storing information on terminal equipment". In balanced mode, storing the per-visit id before consent must be justified as strictly necessary, or treated as needing consent. Strict mode avoids storage before consent.
The cookieless daily key. It processes the IP address and user agent without storage access: GDPR applies (legitimate interest), not ePrivacy storage consent. Some authorities view fingerprint-like techniques as covered by Art. 5(3) anyway. [Counsel: confirm per market.]
Google Consent Mode. The snippet does not set Google's gtag consent signals. If the site also runs Google tags, configure Consent Mode in the site's consent tool. Conversions that Demander uploads to Google carry click ids only when the visitor gave marketing consent.

Cookie and tracking notice (for customers' websites)