Hoe PDF-leesbewijzen werken en waarom ze niet in het formaat zijn ingebouwd
E-mailclients ondersteunen al tientallen jaren leesbevestigingen, waarbij automatisch een melding naar de afzender wordt gestuurd wanneer de ontvanger een bericht opent. Deze mogelijkheid is zo routine geworden in de zakelijke communicatie dat veel mensen aannemen dat deze ook moet bestaan voor PDF-documenten, wat misschien wel het meest gebruikelijke formaat is voor het verzenden van belangrijke zakelijke documenten. De PDF-formaatspecificatie omvat echter geen eigen leesbevestigingsmechanisme. Een standaard PDF-bestand dat in een standaard PDF-lezer wordt geopend, stuurt standaard naar niemand een melding wanneer het wordt geopend.
Tracking aan de serverzijde vermijdt al deze valkuilen.
Linkgebaseerde levering is het betrouwbaardere pad.
De technische reden voor dit ontbreken is dat PDF's zijn ontworpen als op zichzelf staande offline documenten. De formaatspecificatie, die sinds 2008 door de ISO wordt onderhouden, definieert hoe een PDF visueel moet worden weergegeven, maar definieert geen enkel netwerkcommunicatiegedrag. Een PDF-bestand dat op een apparaat zonder internetverbinding wordt geopend, moet identiek worden weergegeven als hetzelfde bestand dat op een aangesloten apparaat is geopend. Het toevoegen van een verplichte netwerkcallback aan een formaat dat opzettelijk netwerkonafhankelijk is, zou dat ontwerpprincipe schenden.
Sommige PDF Security-oplossingen omzeilen deze beperking door JavaScript in de PDF in te sluiten, dat probeert een netwerkverzoek te doen wanneer het document wordt geopend. Deze aanpak kan werken, maar is onbetrouwbaar omdat de meeste PDF-lezers om veiligheidsredenen de uitvoering van JavaScript standaard blokkeren. Adobe Acrobat kan ingesloten JavaScript uitvoeren als de gebruiker dit niet heeft uitgeschakeld. Browsergebaseerde PDF-viewers, waaronder Chrome's PDFium en Firefox's PDF.js, voeren helemaal geen PDF JavaScript uit. Een leesbevestigingsmechanisme dat is gebouwd op PDF JavaScript zal daarom bij sommige ontvangers worden geactiveerd en bij andere stilzwijgend falen, waardoor het ongeschikt wordt voor enig doel waarvoor ontvangstbevestiging vereist is.
Op JavaScript gebaseerde methoden voor leesbevestiging en hun betrouwbaarheidsbeperkingen
Bij de meest voorkomende doe-het-zelf-implementatie voor leesbevestigingen wordt een JavaScript-actie in de PDF ingesloten die wordt geactiveerd bij het openen van het document. Het script bouwt een URL op die een unieke document-ID en de huidige tijdstempel bevat, en probeert vervolgens die URL te laden, meestal als een verborgen afbeelding of een XMLHttpRequest. Een webserver die naar de doel-URL luistert, registreert het verzoek en registreert dat het document met die identificatie op dat moment werd geopend.
Het betrouwbaarheidsprobleem is in de praktijk ernstig. Adobe Acrobat waarschuwt gebruikers wanneer een PDF probeert verbinding te maken met een externe site en geeft hen de mogelijkheid om de verbinding te blokkeren. Bij de meeste zakelijke PDF-implementaties wordt Acrobat zo geconfigureerd dat externe verbindingen standaard als beveiligingsbeleid worden geblokkeerd. Browsergebaseerde kijkers negeren het verzoek volledig omdat hun JavaScript-engines niet de netwerk-API's implementeren die het script vereist. Mobiele PDF-lezers blokkeren of negeren op vergelijkbare wijze ingebedde JavaScript-netwerkoproepen. De afzender ontvangt alleen leesbevestigingen van ontvangers die desktop Acrobat gebruiken met JavaScript ingeschakeld en waarbij externe verbindingen zijn toegestaan, wat in een typische populatie van ontvangers een minderheid is.
Zelfs als JavaScript succesvol wordt geactiveerd, biedt de leesbevestiging beperkte informatie. Het bevestigt alleen dat de PDF is geopend door een PDF-lezer die JavaScript uitvoert. Het bevestigt niet dat een mens het document heeft gelezen, dat het document correct is weergegeven of dat de ontvanger voorbij de eerste pagina heeft gescrolld. Een leesbevestiging die wordt gegenereerd door een geautomatiseerd documentverwerkingssysteem dat elke binnenkomende PDF opent en indexeert, levert een vals positief resultaat op dat niet te onderscheiden is van de opening van een echte ontvanger.
Tracking aan de serverzijde via gehoste PDF-links
Een betrouwbaarder alternatief voor ingebed JavaScript is tracking op de server met behulp van gehoste PDF-links. In plaats van de PDF bij een e-mail te voegen, uploadt de afzender het document naar een webserver en stuurt de ontvanger een link om het te bekijken of te downloaden. De server registreert elk verzoek om de PDF-URL, inclusief de tijdstempel, het IP-adres en de browsergebruikersagentreeks van elke toegang. Deze aanpak aan de serverzijde registreert elke toegang, ongeacht de PDF-lezer van de ontvanger, de JavaScript-instellingen of het apparaattype, omdat de tracking plaatsvindt op HTTP-verzoekniveau voordat de PDF zelfs maar wordt weergegeven.
Tracking aan de serverzijde maakt ook gedetailleerdere analyses mogelijk. De server kan registreren of de ontvanger het hele bestand heeft gedownload of alleen de eerste paar kilobytes heeft opgehaald, wat aangeeft of hij of zij het document waarschijnlijk heeft bekeken of alleen maar op de link heeft geklikt. Als de PDF wordt weergegeven via een viewer die pagina-voor-pagina laden ondersteunt, kan de server bijhouden welke pagina's zijn geopend en voor hoe lang. Deze betrokkenheidsstatistieken bieden een veel rijker beeld van documentinteractie dan een eenvoudig binair open/niet-geopend signaal.
Het belangrijkste nadeel van tracking op de server is dat de workflow voor documentlevering moet worden gewijzigd van e-mailbijlage naar gehoste link. Ontvangers die gewend zijn om PDF's als e-mailbijlagen te ontvangen, kunnen de extra klik om toegang te krijgen tot een gehost document ongemakkelijk vinden. Voor PDF delen-workflows waarbij op bijlagen gebaseerde levering een vereiste is, kan tracking op de server het bijlagemodel niet vervangen. Voor workflows waarbij op koppelingen gebaseerde levering acceptabel is, biedt dit veruit de meest betrouwbare leestracking die beschikbaar is.
Documentanalyseplatforms van derden gebruiken voor het volgen van PDF-lezen
Verschillende commerciële platformen voor documentanalyse bieden het volgen van PDF-lezen aan als een beheerde service. Deze platforms genereren een unieke trackinglink voor elk document en elke ontvanger, hosten de PDF op hun infrastructuur en bieden een dashboard met open tijden, schattingen van de leesduur, betrokkenheid op paginaniveau en voorwaartse tracking als de ontvanger de link met anderen deelt.
Enterprise-grade platforms pakken de privacy- en nalevingsproblemen aan die gepaard gaan met het volgen van documenten. Ze bieden transparantiekennisgevingen aan de ontvanger, voldoen aan de AVG- en CCPA-vereisten voor het bijhouden van openbaarmaking en bieden beleid voor het bewaren van gegevens dat beperkt hoe lang trackinggegevens worden opgeslagen. Ze ondersteunen ook de integratie met CRM- en documentbeheersystemen, zodat leesstatusupdates automatisch naar de systemen stromen waar verkoop-, juridische en compliance-teams al werken.
Voor organisaties die betrouwbare leesbevestiging nodig hebben voor juridisch belangrijke documenten, zoals contractaanbiedingen, mededelingen aan toezichthouders of communicatie met aandeelhouders, biedt de combinatie van linktracking op de server met een commercieel analyseplatform verdedigbaar bewijs van levering en toegang. De serverlogboeken, gecombineerd met de analyses van het platform, creëren een audittrail die aanzienlijk sterker is dan een zelfgerapporteerde e-mailleesbevestiging of een onbetrouwbare ingebedde JavaScript-melding.
Kan u zelf een PDF-leesbevestigingssysteem bouwen zonder diensten van derden
Voor het bouwen van een zelf-gehost PDF-leesvolgsysteem zijn drie componenten nodig: een webserver om de PDF's te hosten en toegangsverzoeken te loggen, een database om tracking-ID's en toegangsrecords op te slaan, en een workflow voor het genereren van documenten die uniek identificeerbare PDF's produceert.
Elk onderdeel is individueel eenvoudig. De integratie en het operationeel onderhoud zijn waar de inspanningen zich opstapelen.
De webservercomponent is het eenvoudigst. Elke standaard HTTP-server, Apache, Nginx of een cloudopslagservice waarvoor toegangsregistratie is ingeschakeld, kan opnemen wanneer een PDF-URL wordt geopend. De databasecomponent slaat een tabel op waarin de documentidentificaties worden gekoppeld aan de e-mailadressen of namen van de ontvangers, plus een tabel waarin elke toegangsgebeurtenis wordt geregistreerd met zijn tijdstempel en IP-adres. Een eenvoudig webapplicatiedashboard doorzoekt deze tabellen om de leesstatus voor elk verzonden document weer te geven.
De operationele complexiteit komt voort uit het in de loop van de tijd onderhouden van het systeem. Toegangslogboeken stapelen zich op en vereisen rotatie- en archiveringsbeleid. IP-adressen in toegangslogboeken kunnen onder de AVG als persoonlijke gegevens worden beschouwd, waardoor het systeem mogelijkheden voor het bewaren en verwijderen van gegevens moet implementeren. Als het trackingsysteem offline gaat, zelfs tijdelijk, ontvangen ontvangers die op documentlinks klikken foutmeldingen in plaats van documenten, wat erger is dan helemaal geen tracking. Een Interactieve PDF met tracking aan de serverzijde is een redelijke oplossing voor teams met bestaande webinfrastructuur en ontwikkelingsbronnen. Voor teams zonder die middelen is een commercieel platform de meer praktische keuze.
De functies voor het delen van documenten van WukongPDF omvatten op links gebaseerde levering met toegangscontrole die registreert wanneer elke ontvanger een gedeeld document opent. Deze benadering aan de serverzijde biedt betrouwbare leesbevestiging zonder de beperkingen van ingebedde JavaScript-tracking, en de trackinggegevens kunnen worden geïntegreerd met de documentbeheerworkflow in plaats van dat er een afzonderlijk analyseplatform nodig is.
De privacydimensie van het volgen van PDF-lezen verdient bij elke implementatie expliciete aandacht. Ontvangers van bijgehouden documenten moeten ervan op de hoogte worden gesteld dat hun toegang wordt geregistreerd, welke gegevens worden vastgelegd, hoe lang deze worden bewaard en voor welk doel. In rechtsgebieden die onder de AVG vallen, is deze openbaarmaking een wettelijke vereiste en niet alleen een best practice. In alle contexten zorgen transparante trackingpraktijken ervoor dat het vertrouwen bij de ontvangers van documenten behouden blijft, terwijl de afzender de ontvangstbevestiging krijgt die de afzender nodig heeft.
Uiteindelijk komt de keuze tussen het bouwen van een aangepast leesbevestigingssysteem en het gebruik van een commercieel platform neer op een make-versus-buy-beslissing die afhangt van de technische middelen van uw organisatie, het documentvolume en de wettelijke verdedigbaarheidsvereisten van uw leesbevestigingen. Organisaties die een handvol bijgehouden documenten per maand verzenden, kunnen dit beheren met eenvoudige logboekregistratie op de server en handmatige statuscontrole. Organisaties die honderden bijgehouden documenten per week verzenden, vooral in juridische, financiële of regelgevende contexten waar leesbevestigingen van belang zijn voor naleving, profiteren van de betrouwbaarheid, het audittraject en de ondersteuning die een speciaal platform voor documentanalyse biedt.
Verzenddocumenttracking waarvoor geen actie van de ontvanger, geen software-installatie en geen wijziging van JavaScript-toestemming vereist is, levert de meest betrouwbare leesbevestigingsgegevens op. Linktracking aan de serverzijde bereikt al deze drie doelen en vertegenwoordigt de huidige best practice voor de implementatie van PDF-leesbevestigingen in professionele zakelijke communicatieworkflows.