Sift Docs
Privacy

GDPR and consent

Why Sift does not need a cookie banner, and where that argument has limits.

This page explains the technical design. It is not legal advice. Your jurisdiction, your national implementation of the ePrivacy rules, and your own risk tolerance decide what you need.

The short version

Consent banners exist mainly to authorize storing information on a device — cookies, localStorage, and similar. Sift stores nothing on the device.

  • No cookies are set.
  • No localStorage value is written. One is read, and only if you write it yourself to opt out.
  • No device fingerprint is created or persisted.
  • No IP address is stored.

Without device storage or a persistent identifier, the usual consent trigger is not present.

The technical basis

The visitor identifier is:

SHA-256( siteId + IP + user agent + daily salt )

The salt is random, generated server-side, and different for every day. The same person visiting on two days produces two unrelated numbers. There is no way to join them.

That is the difference between "pseudonymous identifier" and "anonymous aggregate". Sift keeps the aggregate and throws away the inputs.

See IP handling for the mechanics.

What a DPO will ask

Is the IP address processed? Yes, in memory, for the duration of one request. It is not written to storage or logs. Processing a value transiently is not the same as storing it.

Is the user agent processed? Yes, in memory, and reduced to browser, OS, and device before storage.

Is the data personal? Sift's position is that stored records are not personal data, because no record can be linked back to a person. A regulator may disagree about the transient IP processing; that is a legal question, not a technical one.

Is there a legitimate interest? Most operators run analytics under legitimate interest rather than consent. Document the purpose: measuring aggregate traffic to improve a website.

What about third-country transfers? Traffic is processed at Cloudflare's edge and stored in your database region. Check your Cloudflare and database provider terms.

Where the argument gets weaker

  • If you add your own identifiers to URLs — ?user_id=, ?email= — those end up in UTM parameters and referrers. Do not do that.
  • If you proxy the script and rewrite paths in a way that encodes a user, that path is stored.
  • If your national law requires consent for any analytics regardless of storage, this design does not exempt you.
  • If you combine Sift data with another system that can re-identify people, the combined dataset is a different question.

Practical checklist

  1. Install the script without cookies or custom identifiers.
  2. Do not put personal data in URLs.
  3. Document the purpose and the legal basis in your privacy policy.
  4. Name Sift, Cloudflare, and your database host as processors if your policy lists them.
  5. Keep your own records of the decision.

What Sift does not claim

Sift does not claim to be "GDPR certified", and this page is not a legal opinion. It describes a design that removes the usual consent trigger. Whether that is enough for you is a question for your counsel.

On this page