URL shortener and GDPR — what you need to know before adding a link to your newsletter
URL shorteners collect click data — and that is already a GDPR issue. We explain what the shortener sees, where this data ends up, and why server location matters when you operate in the EU.
One click on a shortened link is an average of four pieces of data recorded silently: IP address, browser, system, input source. Four. Now multiply that by 3000 newsletter recipients who click on the link to your offer on a Sunday morning. You suddenly have a database of several thousand records that you haven't even laid eyes on.
And this is exactly the moment when the link shortener and GDPR ceases to be a theoretical problem for lawyers, and begins to be yours.
Because an IP address in the EU is personal data. Not "almost", not "in some cases". Personal data. If you include a shortened link in a corporate campaign, as an administrator, you are responsible for what happens to the IP of the people who click on it.
What a shortener actually sees when someone clicks
The list is shorter than it seems, but dense enough:
- IP of the visitor (i.e., that specific person mentioned above),
- user agent, i.e., the browser and system,
- referer — from which page the entry came,
- approximate location, calculated from this IP.
That is enough to create nice click statistics. That is also enough to fall into obligations that most people do not think about when quickly pasting a link before sending.
Where does this data land (and why it's more important than the statistics themselves)
Here is the real catch. Many well-known URL shorteners are companies from outside Europe, most often American. You click "shorten", paste the link to your newsletter, and the data about who, when, and where they clicked flies across the ocean.
Two problems, one after another.
First: transferring data outside the EU requires a legal basis, and the very ground for this transfer can be shifting. The regulations have already changed several times, and there is no indication that this is the end.
Second: data falls under a different legal order. As a European administrator, you simply do not control it. Where the server is physically located ceases to be a boring detail from the documentation. It becomes a decision about whether you are GDPR compliant or not.
What actually reduces the risk
Three things. Without magic.
Server in the EU. Click data does not leave Europe, so the entire transatlantic transfer issue simply falls away. Less to translate, less to monitor.
Less data collected. The less the tool holds, the less you have to worry about. It is good when IP is hashed instead of being stored in plain text — then you see statistics, but you do not store a specific person's raw address. This is exactly the feature we built into cutty.dev, because without it, everything else is half-baked.
No cross-service tracking. A browser that does not fingerprint the visitor's profile and does not resell data further is one less problem on the list.
In practice, i.e., what to do on Monday morning
It is not about stopping shortening links. Do shorten them. It is only about choosing the tool consciously, rather than the first one that comes up in a search engine.
- Check where the server is located and who is running it in the first place.
- Check what it stores and for how long.
- If you collect visitor data, add a URL shortener to your privacy policy. Just one sentence. It really doesn't hurt.
That's all. This is not legal advice (I am not your lawyer), but it is the foundation upon which compliance is built much more easily than when data escapes across the ocean from the very first click.
And if you were to remember only one sentence from this: before you drop a link to your newsletter, check where your readers' IP will land. It is a question for five minutes from now that saves much more later stress.