Legitimate-interest assessment template

If you rely on legitimate interest (GDPR Art. 6(1)(f)) to measure visits before consent, after a refusal, or outside the consent regions, record your assessment. This template follows the three usual tests: purpose, necessity and balancing. What Pipetrace does is prefilled from the software; the parts in brackets are yours to complete. You are the controller, so the assessment and the decision are yours.

This assessment is about the legal basis for the processing. Rules on storing or reading information on a visitor's device (in the EU, national laws implementing the ePrivacy Directive) are a separate question: where such a rule requires consent, legitimate interest does not replace it. The EDPB (Guidelines 2/2023) considers that a script which makes the browser send information can fall under these rules even when nothing is stored; check this for tier 1 as well as tier 2. The jurisdiction guidance summarises the situation by country.

About this assessment

Controller[Your organisation's name and contact details]
Website[Your site's domain]
Pipetrace settings
  • Consent mode: [Consent required everywhere, or in consent regions]
  • Before consent: [Off, Anonymous counts or Anonymous sessions]
  • Retention: [1 to 25 months]
Assessed by[Name, role and date]
Next review[A date, and whenever you change these settings]

Part A: Anonymous counts (tier 1)

Complete this part if you count visits before consent or after a refusal. It also applies if you use "Consent required in consent regions", whatever your pre-consent setting: a visitor outside the consent regions who refuses is still counted at tier 1.

1. Purpose

Prefilled: counting page views and visits, with their pages, sources, campaigns, countries and device types, so that traffic figures include visitors who have not chosen yet or who refused analytics cookies. Without it, reports show only the visitors who accepted, and campaign and content decisions rest on a fraction of the traffic.

[Why complete counts matter to you, and what you decide with them]

2. Necessity

Prefilled: what Pipetrace keeps for each page view, custom event or goal:

  • The event type: page view, custom event or goal
  • Event data with at most three keys: page_instance_id, a random ID for the page load, shared by the events sent from that page and used to replace this page view if the visitor accepts on the same page; contract_version, the tracker's event format version; and, for custom events and goals only, name, the event's name. Never properties, values or revenue
  • A random ID for the event, used to drop duplicate deliveries
  • The time the server received it, truncated to the minute
  • The page path; a fragment that could carry a token is removed
  • The page URL with only the UTM campaign parameters kept
  • The referring site's origin (not the full address), and its source and medium
  • UTM campaign tags
  • The country, looked up from the request
  • Device type and browser family, from the user agent
  • The primary language (for example “pt”), from the Accept-Language header
  • Whether the page view started a visit: a full page load with no referrer or from another site, not a reload or back/forward navigation

At tiers 1 and 2, the tracker stores nothing in the visitor's browser. It reads one thing, and only before switching to tier 3: an opt-out saved in localStorage (_pt_consent) by the older optOut() call. If it finds one and the visitor has not accepted, it stays at tier 1. There is no visitor or session ID. The IP address is used to look up the country and, briefly, to protect the service from abuse. Pipetrace does not store it: no event or other database record contains it, and the Pipetrace API leaves it out of its request logs for the tracking endpoints, the policy lookup and the tracker script.

[Could you reach the purpose with less data? Fields or reports you could do without]

3. Balancing

Prefilled safeguards:

  • Pipetrace does not combine these records into a visitor profile: there is no visitor or session identifier.
  • Nothing recorded at tier 1 or tier 2 is linked to a tier 3 visitor. When a visitor accepts on the same page, that page's tier 1 or tier 2 page view is deleted and replaced by its tier 3 page view. Nothing is copied from it; for a tier 2 page view, the server only checks whether its session has other page views, to decide whether the tier 3 page view continues a visit.
  • Global Privacy Control stops all collection: nothing is stored from a request that carries it.
  • Do Not Track keeps the visitor at tier 1 at most, even after the visitor accepts.
  • Data is deleted after your retention period (1 to 25 months).
  • Pipetrace processes the data on your behalf, as your processor.
  • Settings → Privacy generates a privacy notice for your settings that explains what is collected and how visitors can object.

[Would your visitors reasonably expect this? Your audience, whether it includes children or vulnerable people, whether your site's topic is sensitive (for example health), and how visitors can object to you]

Visitors who click Reject are still recorded at your pre-consent tier (and, with "Consent required in consent regions", at tier 1 outside the consent regions even with Off). The EDPB's consent guidelines (05/2020) caution against switching to another legal basis after a refusal, so address refusals on their own.

[Visitors who clicked Reject: why counting them is justified, or the setting you choose instead]

Part B: Anonymous sessions (tier 2)

Complete Part A first. Tier 2 adds sessions, so this part covers only what it adds.

1. Purpose

Prefilled: grouping page views into visits, to measure visits, entry and exit pages, journeys and funnels before consent and after a refusal.

[Why you need visits and journeys, not only counts]

2. Necessity

Prefilled: tier 2 adds these fields to Part A's:

  • A daily visitor code: “a2_” and the first 30 hex characters of an HMAC-SHA256 of the IP address and user agent, keyed with the site's secret key for that UTC day
  • A random session ID, not derived from the visitor
  • The page's number within the session, and the session's first page
  • Whether this is the daily code's first session that UTC day

The visitor code is pseudonymous within a UTC day. It is derived on the server, never stored in the browser, and changes at midnight UTC. The time is kept exactly instead of to the minute, so pages can be put in order. A session ends after 30 minutes without a page view, custom event or goal. The IP address is used to look up the country, to compute the daily visitor code and, briefly, to protect the service from abuse. Pipetrace does not store it (the visitor code is a keyed hash of it): no event or other database record contains it, and the Pipetrace API leaves it out of its request logs for the tracking endpoints, the policy lookup and the tracker script.

[Why counts alone are not enough for this purpose]

3. Balancing

Prefilled safeguards:

  • The day's secret key is kept until 01:00 UTC the next day and then deleted by a cleanup that runs every 15 minutes; the day's codes cannot be recomputed from the live database after that. Operator-held database backups follow their own retention.
  • Each site has its own keys, so codes cannot be matched across sites.
  • Tier 2 stays apart from consented analytics as Part A describes, and records no time on page, scrolling, performance, errors or forms.

Known limits of tier 2:

  • People who share an IP address and an identical user agent (the same browser, version and operating system, for example in one office) count as one visitor. So does everyone with the same user agent behind a proxy that does not pass on the visitor's IP address.
  • A visitor whose IP address changes (a mobile network switch, IPv6 privacy addresses, iCloud Private Relay or a VPN) becomes a new visitor with a new session.
  • A session that crosses midnight UTC counts as two visits, and the same person on two days counts as two visitors.
  • No time on page, scrolling, bounce, performance, errors or forms.

The position on tier 2 differs by the country where you are established: see the jurisdiction guidance. In some countries national guidance supports it, in some the authority assesses it case by case, and in others no national guidance supports it and you accept the risk.

[Your conclusion on expectations and impact for tier 2]

Part C: Consented analytics (tier 3, the same data consented visitors get) outside the consent regions

Complete this part only if you use "Consent required in consent regions". Visitors outside the consent regions then get tier 3, the same data consented visitors get, without being asked. If you are established in one of the places where Pipetrace requires consent everywhere, Pipetrace applies "Consent required everywhere" instead, and this part does not apply.

1. Purpose

[Why you measure these visitors in full before they choose]

2. Necessity

Prefilled. Tier 3 stores a random visitor ID in the first-party cookie _pt_vid, which expires 730 days (about 2 years) after it was last set (the tracker sets it again on every tier 3 page load), and in localStorage and IndexedDB, which have no expiry; it keeps a per-tab session ID in sessionStorage.

Tier 3 keeps a visitor profile that links the visitor's visits and journeys across days. It records the full page address and title, the referring page, campaign tags (UTM), country, device type, browser, operating system, connection type, time zone, language and screen details, time on page, scrolling, clicks on outbound links and downloads, rage clicks (repeated) and dead clicks (unresponsive), performance, errors, form starts and submissions (never what is typed), and the names and details of custom events and goals, and the amount, currency and order ID of revenue events the website sends. If you call identify, it also records the user identifier and details (traits) you supply, and links the visitor's visits to them.

The IP address is used to look up the country, to compute the same-day recovery hash with that day's secret key and, briefly, to protect the service from abuse. Pipetrace does not store it (the recovery hash is a keyed hash of it): no event or other database record contains it, and the Pipetrace API leaves it out of its request logs for the tracking endpoints, the policy lookup and the tracker script.

The data collection reference lists every field.

[Which of these you need, and whether counts or sessions would do]

[Whether you call identify for these visitors, and if so which user ID and traits you send]

3. Balancing

Prefilled safeguards:

  • A refusal is honoured on the page where it is made: the tracker stops using cookies and identifiers, and their page views are stored as tier 1 only. Pipetrace does not remember the visitor's choice. Your consent tool must store it and load the script with data-consent="denied" on every later page; otherwise, in regional mode, a visitor outside the consent regions who refused gets tier 3 again on the next page, and so does a visitor on a legacy site.
  • A safeguard you must implement: [How your consent tool stores a refusal and loads the script with data-consent="denied" on every later page]
  • Global Privacy Control stops all collection: nothing is stored from a request that carries it.
  • Do Not Track keeps the visitor at tier 1 at most, even after the visitor accepts.
  • A visitor whose country is unknown is treated as being in a consent region.
  • Data is deleted after your retention period (1 to 25 months).

Whether the GDPR, or another law, applies to these visitors depends on where you are established and whom your site targets. Pipetrace does not decide which law applies: you decide this with your adviser. Where the law that applies requires consent for cookies or browser storage, legitimate interest does not replace it.

[The laws that apply to these visitors, and your conclusion]

Outcome

  • [Proceed as assessed]
  • [Proceed with these changes (list them)]
  • [Do not proceed: the settings you will change instead]

If you do not proceed, note how your settings interact. Off before consent with "Consent required everywhere" records nothing before the visitor accepts or after a refusal. With "Consent required in consent regions", a refusal outside the consent regions is still stored as tier 1, whatever the pre-consent setting.

Keep this assessment with your records of processing, review it when you change these settings, and make sure your privacy notice explains the right to object.