Експорт даних коротких посилань: чотири речі, які можна забрати з собою

Сервіс скорочення посилань зберігає чотири види даних, і лише один переноситься без втрат, коли ви йдете. Таблиця посилань - слаги, цільові URL, теги та домени, на яких вони розміщені - це саме те, для чого кожен серйозний постачальник дозволяє експортувати дані коротких посилань, зазвичай у форматі CSV або через API, бо схема проста, а кожній платформі потрібен базовий імпортер, щоб залучати нових клієнтів. Агреговані лічильники кліків також зазвичай доступні, хоча деталізація відрізняється. Необроблені події кліків - запис по одному рядку на клік із міткою часу, реферером, пристроєм та IP - є винятком: більшість постачальників ніколи їх не відкривають, бо поверхня експорту ніколи не будувалася для вивантаження повної історії. Метадані облікового запису - теги, домени, користувачі - перебувають посередині, їх можна експортувати частинами, а не одним чистим вивантаженням.

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

Що насправді зберігає платформа коротких посилань

Кожен сервіс скорочення побудований навколо тих самих чотирьох класів даних. Розуміння того, який клас - який, ще до того, як вам знадобиться експорт, визначає, чи займе міграція або аудит один день, чи цілий квартал.

• Таблиця посилань: слаг, цільовий URL, дата створення, теги, папка та власний домен, до якого прив'язане посилання.
• Агреговані лічильники кліків: загальна кількість за весь час для кожного посилання, іноді щоденна розбивка, подекуди - розподіл за країною чи реферером.
• Необроблені події кліків: один рядок на клік, що містить мітку часу, IP, user agent і реферер, з якого відбувся перехід.
• Метадані облікового запису: налаштування робочого простору, записи власних доменів, список учасників команди, API-ключі, таксономія тегів.

Ці чотири класи відкриті не однаковою мірою, і саме розрив між ними - головна тема цієї статті.

Чому таблиця посилань переноситься, а історія кліків - зазвичай ні

Таблиця посилань переносима, бо її схема навмисно проста. Слаг, цільова адреса, жменька необов'язкових полів - кожен постачальник підтримує імпорт із CSV, щоб залучати нових клієнтів, а це означає, що в кожного постачальника є й певна форма експорту в CSV, хоча б для того, щоб маркетингова сторінка конкурента могла обіцяти "перехід за один день". Гід із поширених збоїв при міграції з Bitly розглядає, що насправді ламається під час перенесення цієї таблиці - регістр слага, кінцеві слеші, колізії шляхів у диплінках. Ця стаття - про інший момент: рутинне вивантаження, яке ви робите незалежно від того, стоїть міграція в календарі чи ні.

Історія кліків - це вже зовсім інша справа. Агрегований експорт, коли постачальник його пропонує, дає лічильник за весь час або грубий щоденний підсумок - корисний для підсумкового числа, але марний, щойно вам потрібна деталізація по днях чи реферерах. Власний експорт Bitly - показовий приклад: він видає лічильник за весь час для кожного посилання і нічого на рівні окремих подій, і це закономірність, характерна для більшості категорії, а не особливість саме Bitly. Щойно експорт втрачає цю деталізацію, вона зникає назавжди.

Куди зникають необроблені події кліків

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

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

Питання, які варто поставити постачальнику перед підписанням

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

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

Регулярний графік експорту, що зберігає вашу незалежність

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

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

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

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

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

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

Що насправді охоплює стаття 20 GDPR у цьому питанні

Питання переносимості даних посилань постійно виникає в перемовинах про закупівлю, і точне розуміння того, чого насправді сягає ця стаття, змінює хід перемовин.

Стаття 20 GDPR надає суб'єкту даних право отримати персональні дані, які він надав контролеру, у структурованому, машинозчитуваному форматі, і передати їх іншому контролеру - але лише для обробки на підставі згоди чи договору, і лише автоматизованими засобами. Настанови робочої групи WP29 щодо переносимості даних звужують це ще більше: право охоплює дані, надані безпосередньо або згенеровані через власне використання сервісу суб'єктом даних, а не дані, виведені про нього.

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

Перевірка експорту, перш ніж йому довіряти

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

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

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

Пов'язане в блозі

• Міграція з Bitly на Elido: технічний гід
• Міграція з Bitly без втрати посилань: гід із поширених збоїв
• GDPR для сервісів скорочення посилань: що насправді хоче побачити ваш DPO
• Термін зберігання даних про кліки: скільки тримати журнали аналітики
• API сервісу скорочення посилань: ліміти запитів, повтори, ідемпотентність