GDPR, PECR and visitor tracking

What is the legal position on tracking what unique visitors do on your website without requiring them to log in?

The legal position can initially appear complex, because more than one regulatory framework may apply — in the UK, both the UK GDPR and the Privacy and Electronic Communications Regulations 2003 (PECR). The answer also depends on the specific technology used, the data collected, and how that data is subsequently processed.

Based on our work with legal advisers and our experience supporting clients, our view is that tracking identifiable or pseudonymous website visitors can be lawful, provided the relevant legal and regulatory requirements are met.

That formulation is precise. "Visitors opted in, therefore it is lawful" is not a position we adopt, and it is not one the published analysis cited in section 3 supports. Consent is one requirement among several, and it is the requirement most often implemented defectively.

In practical terms, an organisation tracking website visitors should:

1. Obtain valid consent before deploying non-essential tracking technologies. This includes relevant cookies, tracking pixels, scripts, tags and other technologies that store or access information on a visitor's device, unless a specific legal exemption applies.
2. Clearly explain the tracking activity. Provide clear and comprehensive information about what is being tracked, why, and how the resulting data is used — reflected in the organisation's cookie and privacy notices.
3. Give visitors meaningful control. Visitors should be able to accept or reject non-essential tracking, and withdrawing consent should be straightforward.
4. Prevent non-essential tracking from starting before valid consent is obtained. Relevant tracking scripts and technologies should not be activated until the visitor has provided the necessary consent.
5. Comply with data protection requirements where personal data is involved. If tracking data can be linked, directly or indirectly, to an identifiable individual, additional UK GDPR obligations may apply — transparency, lawful processing, data minimisation, retention, security and individual rights.

Failure to meet these requirements can create regulatory and legal risk, including potential non-compliance with PECR and, where personal data is involved, the UK GDPR.

A note on the Data (Use and Access) Act 2025. UK law has moved. The DUA Act introduced narrow exemptions to the PECR consent requirement — broadly, for cookies used solely for statistical purposes, for customising the appearance of a service, and for emergency geolocation. It would be convenient for us to argue that engagement analytics falls within the statistical exemption. We do not make that argument: SignalFlo's purpose is to identify named individuals so that a salesperson can follow up, which is not a "solely statistical" purpose. We treat the tracker as consent-requiring.

The framework set out above is not our own characterisation of it. Four international law firms have published analysis covering the technologies in question, and it may be consulted directly. It is cited here for the legal framework only — none of these firms has reviewed, advised on, or endorsed SignalFlo, and none of the material constitutes legal advice to the reader.

• Clifford Chance — Data (Use and Access) Act: cookies, trackers and security patches — covers cookies, tracking pixels, scripts and tags, and the new DUA Act exemptions. The clearest current statement that PECR consent is the default and exemptions are narrow.
• CMS — Data protection and cybersecurity laws in the United Kingdom — states directly that tracking pixels, link decoration, navigational tracking, web storage, fingerprinting techniques, and scripts and tags are regulated by PECR, read alongside the UK GDPR and the Data Protection Act 2018.
• Bird & Bird — Global Cookie Review — a formal, downloadable multi-jurisdiction report. Its UK section sets out the high consent threshold and the PECR / UK GDPR / DPA 2018 interaction.
• Linklaters — UK and EU: cookie rules to become the "law of everything"? — the most directly relevant to a product like this: it discusses the expanding scope of the cookie rules to "cookie-like" technologies such as tracking pixels and browser fingerprinting.

The short version of all four: these rules apply to far more than the word "cookie" suggests, and the direction of travel is wider, not narrower. That is precisely why we treat the tracker as consent-requiring rather than hunting for an exemption.

Our view is that privacy compliance should be designed into the tracking architecture from the outset, rather than bolted on once a customer's DPO asks a hard question.

We favour a conservative, privacy-first approach: giving visitors clear information and meaningful, granular control over the categories of tracking they accept. In our view this provides the strongest foundation for responsible visitor intelligence, while reducing regulatory risk and helping organisations stay aligned with evolving regulatory guidance.

In engineering terms that means three commitments, each of which is checkable in section 8 and section 9 rather than asserted here: collect the minimum that makes the product work, never collect a category of data we do not need simply because it is technically available, and fail closed when a visitor signals an objection.

This is the first thing to establish, because it reframes every question that follows.

Two consequences follow:

Asking for consent is the client's job; refusing to run without it is ours. The tracking script is deployed on the client's website, under their domain, alongside their consent management platform. They own the banner, the wording and the record of what each visitor agreed to — we cannot obtain consent on their behalf and do not claim to. What we can do, and do, is make the script inert until their platform tells it consent exists (section 8). The gate is enforced on both sides rather than trusted to one.

A visitor's rights are exercised against the controller. We assist the client in responding, as our DPA requires — see section 13.

Three categories, set out precisely.

a) CRM contact records, synchronised from the client's Salesforce or HubSpot: name, work email, job title, employer, account ownership.

b) Behavioural events: page URL and page title, document downloads, form submissions, webinar attendance, and activity already logged in the client's CRM (meetings, calls, emails). Each event carries a timestamp and an opaque visitor identifier.

c) Derived values computed from the above: an engagement score, a bucket label (for example Warm or Hot), an inferred persona type, and a week-on-week trend.

This is business-context data about people acting in a professional capacity — a fund selector at an asset management firm, reading a factsheet at work. It is not consumer data. We do not process special-category data as defined in Article 9, we do not process children's data, and we do not knowingly process anything about an individual's private life.

That framing does not exempt anything. Work email addresses and job titles are still personal data under the UK GDPR. It does bear materially on the balancing test in section 7.

Two separate legal questions are often conflated. They need separate answers.

The device access question is PECR, not GDPR. Placing or reading a cookie or similar identifier on a visitor's device is governed by PECR regulation 6 (in the EU, Article 5(3) ePrivacy). The lawful route there is consent, obtained by the client's own consent management platform. No GDPR lawful basis substitutes for it — a legitimate-interests argument does not authorise setting a non-essential cookie.

The subsequent processing question is UK GDPR. Once data has lawfully been collected, processing it is done under Article 6(1)(f), legitimate interests.

Legitimate interests assessment, in summary. *Purpose:* enabling a distribution team to see which of its existing professional relationships are actively engaged, so it prioritises correctly. *Necessity:* there is no less intrusive way to see engagement across both a website and a CRM; the alternative is guesswork or blanket outreach, which is worse for the individual. *Balance:* the data is business-context information about identified professionals in a B2B relationship; there is no consumer profiling, no advertising-network sharing, no data sale, no automated decision producing legal effects, and an objection is honoured. We consider the balance to favour the processing — but this is the client's assessment to adopt and record, as controller, and we provide this summary to support it.

The tracker ships consent-required, and enforces it itself. It is not strictly necessary, so it does not start on its own. Until the client's consent platform grants consent, the script writes no cookie, touches no storage, and sends no request. Requirement 4 in section 2 is not advice we pass on to clients — it is the default behaviour of the script.

The consent API. The client's consent management platform calls:

• window.SignalFlo.consent.grant() — when the visitor accepts the relevant category. Only at this point is the visitor identifier created.
• window.SignalFlo.consent.revoke() — when they withdraw. This is erasure, not just silence: the identifier cookie and the session keys are deleted from the device. A later re-grant therefore begins a new identifier rather than silently rejoining the visitor to their previous history.
• window.SignalFlo.consent.status() — returns the current state, so a preference centre can render it accurately.

The decision is remembered so a returning visitor is not asked again on every page.

What happens to activity before consent. A page view that occurs before the banner is answered is held in memory only, capped, and is discarded unless consent is then granted. Nothing is written to the device and nothing is transmitted in the meantime. If the visitor declines or simply leaves, it is gone.

An alternative configuration exists, and is the weaker of the two. A site whose consent platform already category-gates third-party tags — so the script is loaded only once the visitor has accepted — may set an attribute that treats loading as the signal. This is a legitimate configuration and is how most analytics tags operate. It is weaker because the guarantee then resides in the host page's tag configuration rather than in the script itself, where it can be inspected.

Do Not Track and Global Privacy Control outrank both modes. If a visitor's browser sends DNT or GPC, the script disables itself before doing anything at all, and a consent banner cannot switch it back on — calling grant() has no effect. A browser-level objection is not something a site banner should be able to click away.

That backstop is not consent, and we will not present it as such. An absent DNT or GPC signal tells you nothing about whether a visitor agreed to anything — most browsers send neither by default. It is a floor beneath the consent mechanism, not a substitute for it.

The tracking script is roughly 300 lines and is served unminified at /v1/signalflo.js. Everything in this section can be verified by reading it.

Stored on the device

Nothing in this table is created until consent is granted (section 8) — the row for the consent decision itself is the only thing written before that, and only in response to the visitor answering the banner.

Sent to us, per event: the opaque visitor id, the session id, the event type, the page URL, and the page title. Product events may add a fund identifier. That is the complete payload.

What we deliberately do not do. Every item below is an absence you can confirm in the script:

• No device or browser fingerprinting — no canvas, WebGL, screen, font, timezone or hardware probing of any kind.
• No cross-domain or cross-site tracking. The cookie is first-party and the beacon is sent with credentials omitted.
• No referrer capture.
• No form field contents. The script attaches no listener to any input, form or keystroke event.
• No mouse movement, scroll or click-heatmap capture, and no session replay. The script registers exactly two listeners, for browser history navigation and for tab visibility.
• No advertising or ad-network integration, no retargeting pixels, no data sharing with advertising platforms.
• We never sell personal data.

Anonymous traffic can be matched to an organisation by reverse-IP lookup — the feature that lets a client see that someone at a given firm has been reading a fund page.

The visitor's IP address is never stored. It is used transiently, in memory, for rate limiting and for a single reverse-IP lookup, and is then discarded. There is no IP address column in our events tables or our session tables — this is an architectural property, not a retention policy that could quietly change.

The result is company-level only. What we retain is a company domain and company name. Reverse-IP lookup resolves a network, not a person: it can tell a client that *someone at Example Asset Management* viewed a page, and it cannot tell them who. An anonymous visitor becomes a named individual only through the identification described in section 11, never through IP.

This deserves its own section rather than a footnote, because it is the part a data protection officer will most want to see disclosed.

When a known contact identifies themselves — by submitting a form, or by arriving through a tracked link in an email — SignalFlo links that browser's opaque identifier to their CRM contact record. Activity previously recorded against that browser is then attributed to them retroactively, including page views from before they identified themselves.

This is defensible on the legitimate-interests analysis in section 7, and is standard behaviour across B2B marketing-automation platforms. It is disclosed here because disclosure is a condition of that defence.

Three limits are enforced in the software:

• A contact must already exist in the client's CRM. Identification never creates a new person; an unrecognised identifier is rejected.
• Suppression is respected at the point of linking. A contact flagged as tracking-suppressed cannot be linked, and the attempt is refused.
• Suppression is retroactive. Suppressing a contact detaches their identifier and returns their prior activity to the anonymous pool.

Clients should ensure their own privacy notice reflects this behaviour, since they are the controller and it is their visitors.

Article 22 does not bite here, and it is worth explaining why rather than simply asserting it.

Article 22 applies to decisions based solely on automated processing that produce legal effects concerning an individual, or similarly significantly affect them. A SignalFlo score determines which professional contact a salesperson calls first. It does not decide whether someone is offered a product, granted credit, priced differently, hired, or refused a service. Being contacted earlier or later by a fund's distribution team is not a legal or similarly significant effect on the individual.

Two commitments make that credible rather than convenient:

• A human always decides the outreach. The score ranks a list; it does not send anything or refuse anything by itself.
• The methodology is published. The scoring model is points, time-decay, and configured multipliers — deterministic and inspectable, not an opaque model. A client can show any contact exactly which events produced their score.

Article 22 not applying does not remove the Article 21 right to object. It applies to this processing and we honour it — see section 13.

Rights under the UK GDPR — access, rectification, erasure, restriction, portability, and objection — are exercised against the client as controller. As processor we assist, as our DPA requires.

The mechanisms currently available are as follows.

• Objection / opt-out (Art. 21) is implemented as a per-contact tracking suppression flag. It stops future tracking and retroactively detaches past identification, returning that activity to the anonymous pool. It is currently actioned by us on request from the client rather than through a self-service button in the client's admin console. Building that control into the UI is on our roadmap.
• Access, erasure, rectification and portability for an individual contact are handled by us on request from the client, within the DPA's timeframes. We do not yet offer a self-service per-contact export or erasure tool.
• Whole-tenant deletion on termination is supported.

Where self-service rights tooling is a procurement requirement, its availability should be confirmed with us before contract rather than assumed.

Primary hosting is in the EU/EEA. The database is hosted in Ireland (Supabase, eu-west-1) and the application in Frankfurt (Render, eu-central-1).

Some processing necessarily involves transfers outside the UK/EEA. The ones that apply to SignalFlo data:

A current sub-processor register, with the region and transfer safeguard for each, is available on request and forms a schedule to the DPA. Notification of new sub-processors is handled under the DPA's change process.

The retention position is as follows, stated as currently enforced rather than as intended.

• Behavioural events are retained for the life of the client's subscription. There is currently no fixed retention period and no automated deletion of historical events. Introducing a configurable retention window is on our roadmap; until it ships, we will not claim a retention period we do not enforce.
• Score snapshots are pruned on a rolling basis, keeping the current score and a trend history.
• Audit logs are retained for regulatory record-keeping.
• On termination, all client data is deleted from production systems, with backups ageing out on their own cycle.
• Individual erasure requests are actioned as described in section 13.

Where a defined retention period for behavioural events is required for a data protection impact assessment, it is agreed contractually.

Questions about this page, requests for the DPA, the sub-processor register, or assistance with a data subject request:

Eddric Ltd · info@eddric.ai · 167-169 Great Portland Street, 5th Floor, London W1W 5PF, United Kingdom

If you are an individual whose data is processed through a client's SignalFlo deployment, that client is your controller and is the right first point of contact. You may also complain to the UK Information Commissioner's Office at ico.org.uk.

This page is not legal advice. It sets out our position and our engineering commitments so that you can evaluate them. It is not a substitute for your own assessment, and the firms cited in section 3 have not advised on or endorsed this product.