Linkdata exporteren: de vier dingen die je kunt meenemen

Een URL-verkorter bevat vier soorten data, en slechts één daarvan reist schoon mee als je vertrekt. De linktabel - slugs, bestemmingen, tags en de domeinen waarop ze staan - is waarvoor elke serieuze leverancier je linkdata laat exporteren, meestal als CSV of via een API, omdat het schema eenvoudig is en elk platform een basisimporter nodig heeft om nieuwe klanten te winnen. Geaggregeerde clicktellingen zijn meestal ook beschikbaar, al varieert de granulariteit. Ruwe clickevents - de record per click met tijdstempel, referrer, apparaat en IP - zijn de uitzondering: de meeste leveranciers stellen ze nooit beschikbaar, omdat het exportoppervlak nooit is gebouwd voor het ophalen van de volledige geschiedenis. Accountmetadata - tags, domeinen, gebruikers - zit ertussenin, exporteerbaar in stukjes in plaats van in één schone export.

Behandel de linktabel als de enige categorie waarop je kunt rekenen dat die meegaat, houd er rekening mee dat je de ruwe clickgeschiedenis volledig kwijtraakt, en vraag een schriftelijk antwoord over geaggregeerde tellingen voordat je iets ondertekent. Dit is niet nog een migratieverhaal - de Bitly-migratiegids behandelt die overstap al. Dit is de vaste gewoonte om je eigen data eruit te halen, of je nu migreert of niet.

Wat een platform voor korte links daadwerkelijk bevat

Elke verkorter is opgebouwd rond dezelfde vier gegevenscategorieën. Weten welke welke is voordat je een export nodig hebt, bepaalt of een migratie of audit een middag of een kwartaal kost.

• Linktabel: slug, bestemmings-URL, aanmaakdatum, tags, map, en het aangepaste domein waaraan een link is toegewezen.
• Geaggregeerde clicktellingen: een totaal per link over de hele looptijd, soms een uitsplitsing per dag, af en toe opgesplitst naar land of referrer.
• Ruwe clickevents: één rij per click, met de tijdstempel, het IP-adres, de user agent en de referrer die deze heeft veroorzaakt.
• Accountmetadata: workspace-instellingen, records van aangepaste domeinen, de lijst met teamleden, API-sleutels, tagtaxonomie.

De vier categorieën worden niet gelijk beschikbaar gesteld, en het gat daartussen is het hele onderwerp van dit artikel.

Waarom de linktabel meereist en clickgeschiedenis meestal niet

De linktabel is overdraagbaar omdat het schema met opzet saai is. Een slug, een bestemming, een handvol optionele velden - elke leverancier ondersteunt een CSV-import om nieuwe klanten te winnen, wat betekent dat elke leverancier ook een vorm van CSV-export heeft, al was het maar zodat de marketingpagina van een concurrent kan beloven dat je "in een middag overstapt." De Bitly-gids voor faalmodi behandelt wat er daadwerkelijk misgaat als je die tabel verplaatst - hoofdlettergebruik in slugs, trailing slashes, botsingen in deeplink-paden. Dit artikel gaat over een ander moment: de routine-export die je neemt, ongeacht of er een migratie op de planning staat.

Clickgeschiedenis is een ander beestje. Een geaggregeerde export, als een leverancier er een aanbiedt, geeft je een teller over de hele looptijd of een grof dagtotaal - nuttig voor een koptekstcijfer, nutteloos zodra je detail per dag of per referrer nodig hebt. Bitly's eigen export is een duidelijk voorbeeld: die geeft je de teller over de hele looptijd per link en niets op eventniveau, een patroon dat voor het grootste deel van de categorie geldt, niet iets specifieks voor Bitly. Zodra een export die granulariteit laat vallen, is die voorgoed verdwenen.

Waar ruwe clickevents verdwijnen

Ruwe clickevents verdwijnen om een structurele reden, niet uit gierigheid. Click-event-opslag is gebouwd om binnen het eigen dashboard van de leverancier te bevragen, niet voor bulkophaling. Het API-oppervlak dat een klant door miljoenen individuele clickrijen zou laten bladeren, is een heel andere technische investering dan een grafiek in een dashboard, en de meeste leveranciers bouwen dat nooit, omdat de meeste klanten er nooit om vragen voordat ze het nodig hebben.

Het gevolg is bot: zodra je account voorbij het bewaarvenster voor ruwe events veroudert, of een downgrade van je abonnement de API-tier afsnijdt die er toegang toe gaf, is die data voorgoed verdwenen. De linktabel overleeft een accountwijziging meestal wel; de clickgeschiedenis eronder niet. Zelfs waar een API voor ruwe events bestaat, loopt het ophalen van een volledige geschiedenis tegen dezelfde mechaniek aan die elke grote aanroep tegen een verkorter-API beheerst - zie rate limits, retries en idempotency bij een verkorter-API voor hoe je een meerdaagse export spreidt zonder de limiter te raken. Als je team clickgeschiedenis blijft bevragen in plaats van alleen archiveren, is Elido's linkanalytics zo gebouwd dat het grootste deel van dat bevragen zonder export gebeurt.

Vragen om een leverancier te stellen voordat je tekent

Stel deze vragen voordat je tekent, niet nadat de downgrademelding binnenkomt. Een leverancier die alle zes schriftelijk beantwoordt tijdens het verkoopgesprek, is er een die je kunt vertrouwen om ze een jaar later nog steeds te beantwoorden.

Als niets hiervan ergens in de documentatie van je leverancier staat, is die stilte het antwoord op vraag één. Elido's API en SDK's publiceren de exporteindpunten, rate limits en het bewaarvenster in dezelfde referentiedocumentatie als al het andere - je eigen data terugkrijgen zou nooit een supportticket mogen vereisen.

Een geplande exportroutine die je onafhankelijk houdt

De oplossing is een gewoonte, geen eenmalig project. Neem een volledige export volgens een schema, voordat een downgrade of een factuurgeschil de vraag afdwingt, en je bent niet langer gijzelaar van wat je leverancier dit kwartaal besluit dat jouw abonnementstier waard is.

Plan de export. Wekelijks voor een actieve workspace, maandelijks voor een rustige. Een geplande taak die de eindpunten voor linktabel en geaggregeerde tellingen aanroept is een paar regels script; het punt is dat die onbemand draait.

Bewaar hem buiten de leverancier. Een bestemming die je zelf beheert, niet een map binnen het product waar je uit exporteert - je eigen opslag, een gedeelde drive, een repository. Als de verkorter morgen verdwijnt, moet de export dat overleven. Dezelfde spreadsheetvorm die wordt gebruikt om campagnelinks bulksgewijs vanuit een sheet te importeren werkt net zo goed andersom, één rij per link.

Controleer het aantal rijen. Vergelijk het aantal rijen in de verse export met het aantal links dat je dashboard rapporteert. Een verschil van minder dan een procent of twee is normaal - gearchiveerde links die je bewust hebt laten vallen. Een groter verschil betekent dat de export iets heeft gemist.

Bewaar de laatste bekend-goede kopie. Bewaar de laatste twee of drie exports, niet alleen de nieuwste. Een corrupte export die je enige kopie overschrijft, ondermijnt het hele punt van het volgens een schema downloaden van linkanalytics.

Deze gewoonte dekt ook een stillere dreiging: gewone link rot. De bestemmingen achter je slugs vervallen op hun eigen tijdlijn, ongeacht wat je verkorter doet - zie link rot voorkomen bij campagnes met korte URL's voor de detectiekant van dat probleem. Een vaste export geeft je de inventaris om die detectie tegen af te zetten, onafhankelijk van welk dashboard je dit jaar ook betaalt.

Wat GDPR-artikel 20 hier daadwerkelijk dekt

Overdraagbaarheid van linkdata komt voortdurend ter sprake in inkoopgesprekken, en precies zijn over wat het artikel daadwerkelijk bestrijkt, verandert de onderhandeling.

Artikel 20 van de GDPR geeft een betrokkene het recht om persoonsgegevens die deze aan een verwerkingsverantwoordelijke heeft verstrekt, in een gestructureerd, machinaal leesbaar formaat te ontvangen, en om ze naar een andere verwerkingsverantwoordelijke te laten overbrengen - maar alleen voor verwerking op basis van toestemming of contract, en alleen met geautomatiseerde middelen. De WP29-richtsnoeren over gegevensoverdraagbaarheid bakenen dit verder af: het recht dekt data die de betrokkene direct heeft verstrekt of die is gegenereerd door diens eigen gebruik van een dienst, niet data die over hem is afgeleid.

Daar volgen twee gevolgen uit. Ten eerste is dit het recht van een individu tegenover een verwerkingsverantwoordelijke, niet het recht van een bedrijf op zijn eigen geaggregeerde analytics - geen enkele GDPR-aanspraak geeft je marketingteam op verzoek zijn clickgeschiedenis terug. Ten tweede draait het meeste clicktracking op campagneniveau op gerechtvaardigd belang in plaats van toestemming of contract, zoals de GDPR-cornerstone voor URL-verkorters in detail behandelt, en artikel 20 is niet van toepassing op verwerking op die grondslag, ongeacht van wie de data is. Je clickgeschiedenis bij een leverancier vandaan krijgen is een inkoopkwestie, geregeld door het contract en de export-API hierboven, geen gegevensbeschermingsartikel. Of de onderliggende IP- of apparaatdata überhaupt persoonsgegevens zijn, en hoe lang je gerechtigd bent ze te bewaren, wordt apart behandeld in bewaartermijn van clickdata.

Een export verifiëren voordat je die vertrouwt

Een export die je niet hebt gecontroleerd is een gerucht, geen record. Voer drie controles uit voordat je die ergens archiveert of de bron verwijdert.

Tel de rijen en vergelijk ze met het linktotaal van het dashboard; onderzoek elk verschil groter dan een procent of twee. Open het bestand in de tool die je daadwerkelijk gaat gebruiken - een csv export die er prima uitziet in een teksteditor kan nog steeds een kapot scheidingsteken hebben of een encoding-probleem dat een spreadsheet pas bij het parsen aan het licht brengt, en daarom is het de moeite waard een voorbeeld te toetsen aan RFC 4180 in plaats van er zomaar van uit te gaan. Controleer steekproefsgewijs een handvol bekende links, met opzet inclusief één die je hebt gearchiveerd of verwijderd, want inactieve links stilzwijgend uitsluiten is veruit de meest voorkomende manier waarop een export compleet lijkt terwijl dat niet zo is.

Ik heb meegemaakt dat een compliance-review een week stilviel door een export die elke link miste die was aangemaakt voor een abonnementsupgrade van achttien maanden eerder - niemand had de tool verteld dat die links onder een ander intern ID bestonden. Dertig minuten rijen tellen had dat kunnen opvangen voordat de review begon.

Gerelateerd op de blog

• Migreren van Bitly naar Elido: een technische gids
• Migreren van Bitly zonder links te breken: een gids voor faalmodi
• GDPR voor URL-verkorters: wat je DPO daadwerkelijk wil zien
• Bewaartermijn van clickdata: hoe lang bewaar je analyticslogs
• URL-verkorter-API: rate limits, retries, idempotency