The direct answer, and why it splits in two
Most guides answer this question as if there is one rule called "click tracking consent." There is not. There are two separate legal triggers that click tracking can hit independently, and a lot of confusion comes from treating them as one thing. The first is the ePrivacy Directive's rule on storing or accessing information on a device, commonly shortened to the cookie law, which applies the moment something gets written to or read from the visitor's browser, a cookie, local storage, anything similar. The second is GDPR's rule on processing personal data, which applies the moment information that can identify a person, directly or indirectly, gets collected and stored anywhere, cookie or not. A click tracking setup can trip either one on its own, both together, or neither.
Why an IP address complicates the answer
An IP address counts as personal data under EU law even when no name, email, or account is attached to it. It's capable of identifying a person indirectly, a position the Court of Justice of the European Union confirmed in the Breyer ruling. That means a server-side click log that sets zero cookies, uses no fingerprinting, and just records a UTM parameter, a referrer, a timestamp, and the visitor's full IP address, can still be processing personal data under GDPR. Whether the ePrivacy cookie rule also applies is a separate question. Collapse this to "no cookies means no consent needed" and you've skipped half the analysis: the cookie question and the personal data question get answered by different tests, and a setup can pass one and fail the other.
What each mechanism actually triggers
| Click tracking mechanism | Triggers ePrivacy (storage or access) | Involves personal data under GDPR |
|---|---|---|
| Server log with UTM parameter and referrer only, no IP stored | No | Generally no, if nothing else identifies the visitor |
| Server log storing the visitor's raw IP address | No, storage is on the server, not the device | Yes, an IP address is personal data under EU law |
| Server log storing a hashed or truncated IP | No | Often reduced risk, but hashing alone does not guarantee anonymization if it can be reversed |
| First-touch or last-touch cookie set on the click | Yes, a cookie is written to the device | Often yes, since the cookie usually links back to identifiable behavior |
| Third-party ad network pixel firing on the click | Yes | Yes |
| Device fingerprinting in place of a cookie | Yes, most regulators treat fingerprinting as covered by the same storage or access rule | Usually yes |
GDPR click tracking, in practice
When people search for gdpr click tracking or ask whether click tracking is gdpr compliant, they are usually really asking two things at once: is a cookie involved, and is the data being collected personal data. Consent is one lawful basis GDPR offers for processing personal data, but it is not the only one. Legitimate interest can apply to some analytics processing under narrower conditions, and a small number of data protection authorities, France's CNIL is the clearest documented example, publish specific criteria under which certain audience measurement tools can operate without consent, provided the data stays first party, IPs are truncated or otherwise reduced, cross-site tracking does not happen, and visitors get an easy opt-out. Meeting an exemption like that is a narrow, technical exercise, not a default state, and whether a given setup qualifies is a question for someone who can review the actual configuration, not a general guide.
Tracking consent rules for cookie-based click attribution
Once a cookie enters the picture, the analysis gets simpler in one respect: the ePrivacy storage rule applies regardless of whether the resulting data would separately count as personal, so the consent question stops being conditional. This is the situation most link-in-bio and campaign tracking tools sit in, because first-party tracking that ties a click to a later conversion generally needs to persist something across a visit, and a cookie is the most common way to do that. Raydar's own click tracking, for example, uses first-touch and last-touch cookies specifically so that a later sale or signup can be traced back to the post or campaign that produced the original click, which makes that feature exactly the kind of tracking a consent mechanism is built to cover, the same as any analytics or attribution cookie. A click ID passed as a URL parameter, by contrast, is closer to the UTM case: it identifies a specific click event, not a person, until something on the receiving end stores it against other identifying data.
Where visitor identification changes the picture
Some tools go further than click attribution and try to identify who the visitor is, not just which campaign sent them. That is a materially different question from click tracking consent, and it deserves its own scrutiny rather than being folded into a general cookie policy. IP hashing is one method used to do this without storing a raw address, and it reduces certain risks without eliminating the underlying personal data question, since a hash of an IP is still derived from personal data and can, depending on the salt and the lookup table available, be reversible. Anyone deciding how their tracking stack works should treat "we hash it" as a mitigation to describe accurately, not a compliance answer on its own.
How consent banners and click tracking tools actually connect
A consent management platform, the tool behind most cookie banners, does not usually block tracking scripts by itself. It records a choice, then either withholds a signal that other scripts are waiting for or, on better implementations, actively stops those scripts from loading until the visitor has answered. A lot of sites get exactly this piece wrong. The banner records consent choices correctly, but the actual tracking, click pixels, ad tags, analytics snippets, keeps firing on page load regardless of what the visitor answered. The banner looks compliant. The tracking behaves as if no banner existed. This tends to happen when a consent banner gets bolted onto a build late, rather than each tracking tool being wired to actually read the consent state before it fires anything. Whether your click tracking respects a decline, not just whether a banner appears, is what separates real consent infrastructure from consent theater.
What a click ID changes about this
A click ID, the identifier some ad platforms and link tools append to a URL to tie a click back to a specific ad or campaign entry, sits in a slightly different spot than a plain UTM parameter. On its own, a click ID in a URL is still just a string of characters, no different in kind from a UTM tag, so the ePrivacy storage question does not apply to the parameter itself. What determines the consent question is what happens after the link is followed: whether the receiving page reads that identifier and pairs it with a cookie, a stored session, or a server-side profile that lets a specific person be tracked across visits. A campaign that only ever reads the click ID once, logs an aggregate count, and discards the rest is in a very different position from one that stores it against a growing visitor profile. The parameter format tells you nothing about which of those two things is actually happening on the backend, so the URL structure alone tells you nothing reliable about compliance.
Server-side tracking does not automatically solve this
A trend in the last few years has been moving tracking from the browser to the server, partly to work around browser cookie blocking, partly marketed as a privacy improvement. Server-side tracking removes the ePrivacy storage question when it genuinely avoids writing anything to the visitor's device, which is a real technical difference. It does not remove the GDPR personal data question, and in some setups it makes that question harder to audit, because the data collection is no longer visible in browser developer tools the way a client-side script is. Moving a tracking pipeline server-side changes which rule applies and how visible the collection is to the visitor. It does not, by itself, change whether personal data is being processed, and "server-side" is not a synonym for "compliant," whatever the tracking vendor's sales page implies.
What to actually do with this
Map your own setup against the table above before assuming an answer either way. Check whether anything writes to the visitor's device, that answers the ePrivacy question. Check what you retain server-side and whether it includes an IP address, a device identifier, or anything else that could point back to a person, that answers the GDPR question. Then get someone qualified to confirm the specific mechanism and jurisdiction. The honest answer here is conditional by design, not because the law is vague, but because click tracking covers technical setups that just get treated differently. And that's frustrating if you wanted a single yes or no, but it's the accurate one. This is not legal advice, and it is not a substitute for a lawyer reviewing your actual stack.