Elido
15 хв читанняВідповідність

GDPR-сумісні скорочувачі посилань - на що звернути увагу у 2026 році

Практичний чекліст для маркетологів та відділів закупівель щодо оцінки скорочувачів посилань відповідно до GDPR: резидентність даних у ЄС, усічення IP, наявність DPA, розкриття субпроцесорів, право на видалення та приховані пастки популярних інструментів із США.

Sasha Ehrlich
Compliance · EU residency
Чекліст із десяти пунктів GDPR для скорочувачів посилань, зіставлений зі статтями GDPR: резидентність у ЄС (ст. 44), усічення IP (ст. 5), відсутність фінгерпринтингу (ст. 6), попередньо підписаний DPA (ст. 28), список субпроцесорів (ст. 28), право на видалення (ст. 17), SLA щодо повідомлення про злам (ст. 33), незалежна атестація (ст. 32), повідомлення про конфіденційність (ст. 13), аналітика без кукі (ст. 6)

Кожне перенаправлення через скорочувач посилань створює подію обробки даних. Подія кліку містить як мінімум IP-адресу, часову мітку та рядок user-agent. Згідно зі Статтею 4(1) GDPR, ця комбінація може становити персональні дані - Європейський суд підтвердив у справі Breyer (C-582/14, 2016), що динамічні IP-адреси є персональними даними, коли організація має реальні засоби ідентифікації особи, що стоїть за ними. Ваш скорочувач має такі засоби: він контролює журнал перенаправлень.

Цей допис є практичним чеклістом для оцінки того, чи є скорочувач посилань справді GDPR-сумісним. Я розберу, чого насправді вимагає регламент, де популярні постачальники не справляються, на що звернути увагу в сумісному інструменті та які компроміси це передбачає. Посилання в статті стосуються Регламенту (ЄС) 2016/679, GDPR зі змінами.

Що GDPR вимагає від скорочувача посилань#

Скорочувач посилань знаходиться в потоці даних між вашою кампанією та вашим клієнтом. Коли хтось натискає на коротке посилання, скорочувач бачить клік раніше, ніж цільова сторінка. Це робить скорочувач процесором даних згідно зі Статтею 4(8): він обробляє персональні дані від вашого імені. Ви є контролером; ви визначаєте мету та засоби відстеження. Скорочувач виконує операцію за вашими вказівками.

Потік даних при кліку на коротке посилання: рівень перенаправлення виконує геолокацію та перевірку ботів за повною IP-адресою, потім усікає її до /24 перед збереженням подій кліків у ЄС; ви залишаєтесь контролером, що обирає законну підставу.

Цей розподіл створює чотири конкретні зобов'язання, які повинен виконувати скорочувач:

1. Письмовий договір, що охоплює Статтю 28(3)

Стаття 28(3) перелічує вісім вимог, які повинен містити будь-який договір із процесором: обробка лише за задокументованими вказівками, конфіденційність, належна безпека, розкриття субпроцесорів, допомога з правами суб'єктів даних, допомога із зобов'язаннями щодо безпеки та DPIA, видалення або повернення даних після завершення та права на аудит. Скорочувач без Угоди про обробку даних (DPA), яка охоплює кожен із цих пунктів, не готовий до закупівель для розгортання в ЄС.

2. Законна підстава для шару відстеження кліків

Саме перенаправлення - прийняття кліку та спрямування його до місця призначення - можна вважати необхідним для надання послуги. Аналітичний шар, що знаходиться над цим перенаправленням - запис кліку для атрибуції, вимірювання кампанії, ретаргетингу - є окремою операцією обробки, яка потребує власної законної підстави згідно зі Статтею 6. Більшість B2B-команд обґрунтовують аналітику кампаній законним інтересом згідно зі Статтею 6(1)(f); якщо скорочувач впроваджує сторонні пікселі ретаргетингу під час перенаправлення, підстава змінюється на згоду згідно зі Статтею 6(1)(a), що означає, що вам потрібен механізм згоди до першого кліку.

3. Мінімізація даних

Стаття 5(1)(c) вимагає, щоб збір даних був «адекватним, відповідним і обмеженим тим, що необхідно». Для скорочувача цей принцип безпосередньо стосується схеми події кліку. Вам потрібні геодані на рівні країни, категорія пристрою, часова мітка та ідентифікатор кліку. Вам не потрібна повна IP-адреса після моменту перенаправлення. Вам майже напевно не потрібен повний рядок user-agent - розібраний кортеж device.type / device.os несе сигнал атрибуції, не будучи вектором для фінгерпринтингу.

4. Відповідність вимогам щодо міжнародної передачі даних

Якщо скорочувач зберігає або обробляє події кліків за межами ЄЕЗ, застосовуються Стаття 44 та Стаття 46. Передача даних до США вимагає або Стандартних договірних умов (SCC) разом із Оцінкою впливу передачі (TIA), або участі в Рамковій програмі захисту конфіденційності даних між ЄС та США, яка сама по собі є предметом триваючого судового розгляду. Скорочувач із хостингом у ЄС повністю уникає цієї проблеми.

Де популярні скорочувачі не справляються#

Bitly#

Основний рівень обробки даних Bitly знаходиться у Сполучених Штатах. Згідно з їхньою публічною документацією, міжнародна передача даних із ЄЕЗ спирається на Стандартні договірні умови. DPA доступний, але він не підписаний заздалегідь у стандартному контракті - корпоративні клієнти домовляються про нього окремо, що збільшує час на закупівлю. Резидентність даних лише в ЄС не є стандартною пропозицією; це питання для обговорення в межах індивідуального контракту.

Дві менш обговорювані проблеми: аналітична панель Bitly інтегрується зі сторонніми сервісами атрибуції, а деякі тарифні плани дозволяють впровадження пікселів ретаргетингу на рівні перенаправлення. Якщо пікселі ретаргетингу спрацьовують до того, як користувач надав згоду, це проблема відповідності Статті 6 для вас як контролера. Скорочувач є процесором, але контролер несе основну відповідальність за наявність правильної законної підстави.

Rebrandly#

Штаб-квартира Rebrandly знаходиться в Дубліні, що звучить привабливо для ЄС, але ключове питання полягає в тому, де обробляються дані, а не де зареєстрована компанія. Згідно з їхнім DPA (станом на травень 2026 року), передача даних із ЄЕЗ до США спирається на SCC. Обробка лише в ЄС доступна корпоративним клієнтам на індивідуальних умовах. Стандартний контракт не прив'язує дані до інфраструктури ЄС. Командам, яким потрібен юридично закріплений пункт про резидентність «з коробки», Rebrandly пропонує лише індивідуальні переговори.

Rebrandly також нативно підтримує сторонні пікселі ретаргетингу на більшості планів. Маркетингова цінність реальна; наслідок для відповідності полягає в тому, що будь-який піксель, що спрацьовує під час перенаправлення для суб'єктів із ЄС, потребує підстави у вигляді згоди, а не законного інтересу, оскільки поведінкове профілювання для реклами виходить за межі законного інтересу згідно з інтерпретаціями більшості наглядових органів.

TinyURL#

TinyURL пропонує зручний безкоштовний рівень і є широко використовуваним споживчим скорочувачем. Він не публікує список субпроцесорів. Стандартні умови не включають DPA, що відповідає Статті 28(3). Аналітичний шар є рудиментарним і розміщується в США. Для B2B або маркетингових команд з аудиторією в ЄС TinyURL не готовий до закупівель.

Загальна проблема скорочувачів із хостингом у США#

Багато постачальників, які працюють переважно для клієнтів із США, ставляться до відповідності GDPR як до формальності, а не як до архітектурного обмеження. Ознаки, на які варто звернути увагу: значок «GDPR compliant» на сторінці цін без посилання на DPA, список субпроцесорів, у якому не вказано регіони хостингу (лише назви хмарних гігантів без регіонів), процес видалення даних через службу підтримки, а не через задокументований API, та відсутність згадок про усічення IP або налаштування мінімізації даних за замовчуванням.

Заява про «відповідність GDPR» як маркетинговий хід нічого не варта без DPA, що відповідає Статті 28(3), актуального списку субпроцесорів із зазначенням регіонів та доказів того, що збір даних за замовчуванням передбачає мінімізацію, а не вимагає від вас окремого підключення цієї функції.

Чекліст для вибору GDPR-сумісного скорочувача#

Ось десять запитань, які варто поставити письмово перед підписанням контракту зі скорочувачем посилань, який оброблятиме дані про кліки суб'єктів із ЄС.

Десять запитань чекліста для скорочувачів, зіставлених зі статтями GDPR: резидентність - ст. 44, DPA - ст. 28(3), усічення IP - ст. 5(1)(c), видалення - ст. 17, SLA при зломі - ст. 33 та інші.

1. Де обробляються дані, і чи є це договірним зобов'язанням?#

Запитайте про регіон хмарного провайдера - не просто назву компанії. «AWS» - це не відповідь; названий регіон ЄС, як-от «AWS eu-central-1», - так. Що ще важливіше, запитайте, чи є цей регіон обов'язковим пунктом у стандартному контракті, чи це лише операційна практика, яка може змінитися без вашої згоди. Згідно зі Статтею 44, передача даних за межі ЄЕЗ потребує законної підстави; ви хочете, щоб зобов'язання щодо резидентності було в контракті, щоб вам не доводилося повторно проводити аналіз кожного разу, коли постачальник оновлює свою інфраструктуру.

2. Чи підписаний DPA заздалегідь, і чи повністю він охоплює Статтю 28(3)?#

DPA, який надається попередньо підписаним у стандартному контракті, свідчить про те, що постачальник розглядає відповідність GDPR як базу, а не предмет торгів. Прочитайте DPA на відповідність восьми підпунктам Статті 28(3). Кожен має бути врахований. Зверніть особливу увагу на пункт (d) - залучення субпроцесорів - та пункт (h) - права на аудит. Загальні фрази на кшталт «ми використовуємо стандартні галузеві практики безпеки» замість конкретних зобов'язань - це тривожний сигнал.

3. Скільки субпроцесорів, і чи вказані вони разом із регіонами?#

Кожен субпроцесор - це додаткова ланка в ланцюжку передачі. Короткий список із вказаними регіонами (провайдер обчислень у ЄС у регіоні ЄС, email-провайдер у US East тощо) можна перевірити за один раз. Довгий список із неясними назвами постачальників - це тягар для обслуговування та ризик для резидентності даних. Згідно зі Статтею 28(2), кожен субпроцесор повинен прийняти ті самі зобов'язання щодо захисту даних, що й процесор. Запитайте, який термін повідомлення про нових субпроцесорів і чи маєте ви право заперечувати проти їх залучення.

4. Чи усікає або хешує скорочувач IP-адреси перед їх зберіганням?#

Зберігання повної IP-адреси рідко є необхідним для випадків використання аналітики, які підтримує скорочувач. Геолокацію на рівні країни та виявлення ботів можна виконати під час перенаправлення за повною IP-адресою, після чого зберегти результат; саму IP-адресу можна видалити або усікти. Згідно зі Статтею 5(1)(c), зберігання більшої кількості даних, ніж вимагає мета, є порушенням принципу мінімізації даних. Запитайте, чи є усічення або хешування IP налаштуванням за замовчуванням, чи вам потрібно активувати його самостійно. Мінімізація за замовчуванням - це правильна архітектура; мінімізація за запитом перекладає ризики відповідності на вас.

5. Чи впроваджує перенаправлення сторонні скрипти або пікселі?#

Деякі скорочувачі пропонують впровадження пікселів ретаргетингу як функцію: коли відвідувач натискає на ваше коротке посилання, скорочувач завантажує Meta Pixel, Google Tag або подібний сторонній скрипт до або під час перенаправлення. Для суб'єктів із ЄС завантаження стороннього скрипта поведінкового відстеження без попередньої згоди є порушенням Статті 6 та, залежно від того, чи встановлюються кукі, Директиви про конфіденційність та електронні засоби зв'язку (ePrivacy Directive). Якщо ваш скорочувач пропонує впровадження пікселів, ця функція повинна бути вимкнена або залежати від згоди для трафіку з ЄС. Якщо постачальник не може підтвердити, що сторонні скрипти не завантажуються за замовчуванням, перевірте це самі за допомогою вкладки Network.

6. Чи є кінцева точка API для запитів на право на видалення даних?#

Стаття 17 надає суб'єктам даних право на видалення їхніх персональних даних «без невиправданої затримки» за наявності певних підстав. Коли ви отримуєте запит на видалення, що стосується даних про кліки, які зберігає ваш скорочувач, вам потрібен механізм для виконання цієї дії. Кінцева точка API, яка приймає ідентифікатор суб'єкта та видаляє пов'язані події кліків, є правильним рішенням. Видалення через запит у службу підтримки не вважається виконаним «без невиправданої затримки» згідно з інтерпретаціями більшості наглядових органів і не є масштабованою моделлю при значному обсязі кліків.

Складність полягає в тому, що події кліків часто зберігаються в аналітичних базах даних, призначених лише для додавання (аналітичних базах даних (BigQuery, Snowflake)). Постачальник, який зберігає дані таким чином, повинен довести, що видалення є реальним - операція DELETE для відповідного розділу, а не просто зміна статусу запису. Запитайте про SLA постачальника щодо Статті 17 та технічний механізм, що за цим стоїть.

7. Який SLA щодо повідомлення про злам даних?#

Стаття 33 вимагає від контролера повідомити свій наглядовий орган про порушення захисту персональних даних «без невиправданої затримки та, за можливості, не пізніше ніж через 72 години після того, як йому стало про це відомо». Щоб вкластися в ці терміни, ваш процесор повинен повідомити вас значно швидше - галузевою нормою є 24 години з моменту виявлення до повідомлення контролера. Ваш DPA повинен містити цей SLA. Фраза «ми повідомимо вас негайно» не є конкретним показником.

8. Чи використовує скорочувач за замовчуванням аналітику без кукі та від першої особи?#

Багато скорочувачів будують власні аналітичні панелі на основі сторонніх інструментів продуктової аналітики (Mixpanel, Amplitude, Segment), які мають хостинг у США та можуть встановлювати постійні ідентифікатори в кукі або локальному сховищі. Для власної продуктової аналітики скорочувача (відстеження вашого використання сервісу) це окреме питання. Але ключовим для відстеження кліків є те, чи встановлює потік перенаправлення будь-які кукі або постійні ідентифікатори в браузері відвідувача без його згоди.

Подія кліку без кукі - така, що визначає країну, пристрій та реферер із заголовків запиту без встановлення будь-якого стану на стороні клієнта - не потребує механізму згоди для аналітики від першої особи згідно з рекомендаціями більшості наглядових органів, за умови, що дані обробляються на підставі законного інтересу, а повідомлення про конфіденційність є доступним. Перенаправлення, яке встановлює постійний ідентифікатор або завантажує сторонній тег, потребує вікна згоди. З'ясуйте, який метод використовує ваш скорочувач.

9. Чи є повідомлення про прозорість, доступне для отримувачів посилань?#

Стаття 13 вимагає, щоб особи, чиї дані збираються, були проінформовані про обробку в момент збору, якщо не застосовуються винятки. Для відстеження кліків за коротким посиланням практичне питання звучить так: як людина, яка натискає на посилання, дізнається, що її клік відстежується, і де вона може про це прочитати?

Більшість розгортань скорочувачів вирішують це через повідомлення про конфіденційність контролера на цільовій сторінці або в банері кукі на вихідній сторінці кампанії. Скорочувачу як процесору не потрібно показувати власне повідомлення тому, хто клікає - але вам як контролеру потрібне повідомлення про конфіденційність, яке охоплює ланцюжок обробки відстеження посилань. Якщо політика конфіденційності скорочувача є єдиним документом, що описує обробку, і вона написана з позиції постачальника, а не контролера, у вас є прогалина.

10. Чи можете ви завантажити та видалити власні дані без звернення до підтримки?#

Це практична перевірка того, чи справді постачальник реалізує права суб'єктів даних, про підтримку яких він заявляє. Ви повинні мати можливість: експортувати всі події кліків для робочого простору в портативному форматі, видаляти окремі посилання та пов'язану з ними історію кліків, а також закрити обліковий запис із задокументованим видаленням усіх персональних даних. Якщо будь-яка з цих дій вимагає запиту до служби підтримки замість використання самостійного API або панелі керування, запитайте про SLA та закріпіть його в контракті.

Пов'язані компроміси#

GDPR-сумісна архітектура передбачає реальні компроміси, і бути чесним щодо них корисніше, ніж вдавати, що обмеження відповідності нічого не коштують.

Менш детальна аналітика. Скорочувач, який усікає IP-адреси до /24 і відкидає повний рядок user-agent, надає вам дані про країну, сімейство пристроїв та ОС, але не про місто, не індивідуальний фінгерпринт браузера і не ідентифікацію користувача між сесіями, яку дозволили б дані повної роздільної здатності. Для більшості випадків атрибуції кампаній такого рівня деталізації достатньо. Для ретаргетингу на індивідуальному рівні потрібен інший підхід - зазвичай серверне пересилання конверсій за ідентифікатором від першої особи, яким користувач уже поділився (email, ID у системі), що не вимагає від скорочувача відстеження особи на рівні перенаправлення.

Менший набір функцій. Деякі з найпотужніших функцій скорочувачів - впровадження пікселів ретаргетингу, міждоменне відстеження, глибока інтеграція зі сторонніми рекламними платформами - побудовані на методах збору даних, які важко узгодити з мінімізацією. GDPR-сумісний скорочувач зазвичай має «чистіше» перенаправлення, яке робить менше на цьому рівні та передає більше на рівень подій конверсії, де контролер має прямі відносини з користувачем і може обґрунтувати відстеження згодою.

Витрати на закупівлю. Вибір скорочувача з хостингом у ЄС та попередньо підписаним DPA скорочує цикл закупівель порівняно з постачальником із США, який потребує індивідуального контракту для резидентності в ЄС. Це не скасовує цикл повністю. Вам все одно потрібно перевірити DPA, список субпроцесорів, SLA щодо видалення даних та підтвердити, що налаштування усічення IP та кукі за замовчуванням відповідають вашому повідомленню про конфіденційність. Розраховуйте на 2–4 години роботи із закупівлі для GDPR-сумісного скорочувача порівняно з 2–8 тижнями для постачальника із США, де резидентність у ЄС потребує індивідуальних переговорів.

Порівняння скорочувача з хостингом у ЄС (резидентність у контракті, попередньо підписаний DPA, не потрібна підстава для передачі даних, близько 2-4 годин) та розміщеного в США (індивідуальні умови для ЄС, SCC плюс TIA, близько 2-8 тижнів).

Як Elido підходить до цього#

Ось як виглядає стандартне розгортання Elido стосовно цього чекліста.

Резидентність даних. Elido за замовчуванням обробляє події кліків на інфраструктурі ЄС у регіоні ЄС. Резидентність є обов'язковим пунктом у стандартному контракті з клієнтом, а не операційною практикою. Клієнти плану Business+ можуть закріпити дані за іншими регіонами; за замовчуванням дані не передаються за межі ЄЕЗ.

Усічення IP. Події кліків, що зберігаються у нашому аналітичному сховищі, містять мережевий префікс /24 (IPv4) або /48 (IPv6), а не повну IP-адресу. Геолокація та виявлення ботів працюють із повною IP-адресою під час перенаправлення, після чого повна IP-адреса видаляється перед збереженням події. Це налаштування за замовчуванням; вам не потрібно його конфігурувати.

Сторонні пікселі під час перенаправлення. Рівень перенаправлення не завантажує жодних сторонніх скриптів. Серверне пересилання конверсій - надсилання даних атрибуції до Meta CAPI, GA4 або подібних систем - є опціональною функцією, що налаштовується окремо і використовує дані подій від першої особи, які ви надсилаєте через POST до API Elido, а не піксель, впроваджений під час перенаправлення. Це архітектурно різні речі: одне спрацьовує без відома відвідувача з перенаправлення, інше - це виклик server-to-server на основі даних, якими відвідувач уже поділився з вами.

DPA. DPA Elido попередньо підписаний у стандартному контракті з клієнтом. Він охоплює всі вісім підпунктів Статті 28(3). Субпроцесори перелічені на сторінці довіри із зазначенням регіонів. Сторінка legal/privacy описує ланцюжок обробки, видимий для отримувачів посилань.

Право на видалення. Запити на видалення згідно зі Статтею 17 передаються до сховища подій кліків наше аналітичне сховище протягом 24 годин. Видалення відбувається на рівні розділів бази даних, а не просто як зміна статусу запису.

Аналітика без кукі. Рівень перенаправлення не встановлює кукі. Події кліків фіксуються лише на стороні сервера. Аналітична панель, яку Elido використовує внутрішньо, працює через Plausible у режимі без кукі для продуктової телеметрії; це окремо від запису подій кліків для ваших кампаній.

Чого Elido поки що не має: SOC 2 Type II (у процесі, заплановано на другу половину 2026 року), шаблону DPIA для самостійного заповнення клієнтами та повністю автоматизованого API для запитів на доступ до даних у менш поширених сценаріях права на доступ. Детальніше про поточні атестації дивіться на сторінці довіри.

Чекліст міграції при переході з не-ЄС скорочувача#

Якщо ви зараз використовуєте скорочувач із хостингом у США і хочете перейти на європейський, ось стислий операційний чекліст.

Перед підписанням нового контракту:

  1. Прочитайте DPA нового постачальника на відповідність Статті 28(3). Переконайтеся, що всі вісім пунктів чітко прописані.
  2. Перевірте список субпроцесорів. Переконайтеся, що вказано регіони хостингу, а не лише назви хмарних провайдерів.
  3. Підтвердьте налаштування усічення IP за замовчуванням. Запитайте письмове підтвердження, якщо цього немає в документації продукту.
  4. Підтвердьте SLA щодо Статті 17 та технічний механізм його виконання.
  5. Перевірте, чи спрацьовують пікселі ретаргетингу під час перенаправлення. Якщо так, переконайтеся, що їх можна повністю вимкнути або поставити в залежність від згоди.

Під час міграції:

  1. Експортуйте існуючі короткі посилання у форматі CSV. Переконайтеся, що нова платформа зберігає ваші кастомні слаги (slugs), перш ніж змінювати DNS.
  2. Створіть усі посилання на новій платформі з тим самим кастомним доменом і слагами перед перенаправленням CNAME.
  3. Зачекайте 24–48 годин на оновлення DNS після зміни CNAME. Протягом цього вікна обидві платформи надаватимуть валідні відповіді, якщо слаги збігаються.
  4. Не переносьте історичні дані про кліки зі старої платформи - відповідальність за старі події кліків залишається на попередньому процесорі, доки ви не скористаєтеся правом на видалення.

Після міграції:

  1. Надішліть запит на видалення всіх персональних даних, пов'язаних із вашим робочим простором, старому постачальнику. Підтвердьте отримання запиту та терміни видалення.
  2. Оновіть ваше повідомлення про конфіденційність, вказавши нового процесора, його субпроцесорів та нову резидентність даних.
  3. Перегляньте банери кукі або механізми згоди, які стосувалися функцій відстеження старого скорочувача. Скоригуйте їх обсяг, якщо збір даних на новій платформі за замовчуванням є вужчим.

Посібник із міграції з Bitly детальніше описує технічні механізми імпорту посилань та передачі DNS.

Що перевірити, перш ніж вірити заявам про відповідність GDPR#

Будь-який скорочувач може написати «GDPR compliant» на сторінці цін. Ця заява не регулюється і сама по собі не має юридичної сили. Артефакти, які справді мають вагу, це:

  • DPA, що відповідає Статті 28(3) підпункт за підпунктом.
  • Список субпроцесорів із зазначенням постачальників, регіонів та категорій даних, що передаються.
  • Повідомлення про конфіденційність, доступне для отримувачів посилань, яке описує ланцюжок обробки - це відповідає вимогам Статті 13.
  • Задокументовані правила обробки IP, які підтверджують усічення або хешування перед збереженням.
  • SLA щодо видалення даних згідно зі Статтею 17 із зазначеним технічним механізмом.
  • Незалежна атестація (ISO 27001 - це мінімум; SOC 2 Type II додає впевненості для закупівель у США та на міжнародному рівні).

Якщо постачальник не може надати все це письмово протягом одного робочого дня, заява про «відповідність GDPR» - це лише маркетинговий текст, а не задокументована позиція щодо відповідності.


Для детального юридичного аналізу статей, на яких базується цей чекліст, у базовому матеріалі про GDPR для скорочувачів детально розглядаються Статті 3, 6, 28, 30, 32 та 35 із цитуванням наглядових органів. Документи для закупівель: політика конфіденційності Elido, умови надання послуг та ціни - DPA включено до стандартного контракту на кожному платному рівні.

Схоже у блозі#

Спробуйте Elido

Вставте URL - отримайте коротке посилання

Без реєстрації. Посилання живе 30 днів. Зареєструйтесь, щоб зберегти назавжди.

Безкоштовно, без реєстрації · 2 на день

Спробуйте Elido

URL-скорочувач із хостингом у ЄС: власні домени, глибока аналітика, відкритий API. Безкоштовний тариф - без кредитної картки.

Теги
gdpr url shortener
gdpr friendly url shortener
url shortener data residency
link tracking gdpr
eu url shortener
dpa url shortener
gdpr checklist

Читати далі