PDF 읽기 확인이 작동하는 방식 및 형식에 내장되지 않은 이유
이메일 클라이언트는 수십 년 동안 읽음 확인 기능을 지원하여 수신자가 메시지를 열면 보낸 사람에게 자동 알림을 보냅니다. 이 기능은 비즈니스 커뮤니케이션에서 매우 일상적으로 사용되어 많은 사람들이 중요한 비즈니스 문서를 보내는 데 가장 일반적인 형식인 PDF 문서에도 이 기능이 있어야 한다고 가정합니다. 그러나 PDF 형식 사양에는 기본 읽음 확인 메커니즘이 포함되어 있지 않습니다. 표준 PDF 리더에서 열린 표준 PDF 파일은 기본적으로 열릴 때 누구에게도 알림을 보내지 않습니다.
서버측 추적은 이러한 모든 함정을 방지합니다.
링크 기반 전달이 보다 안정적인 경로입니다.
이러한 부재의 기술적인 이유는 PDF가 독립적인 오프라인 문서로 설계되었기 때문입니다. 2008년부터 ISO에서 유지 관리하는 형식 사양은 PDF가 시각적으로 렌더링되는 방식을 정의하지만 네트워크 통신 동작을 정의하지는 않습니다. 인터넷에 연결되지 않은 장치에서 열린 PDF 파일은 연결된 장치에서 열린 동일한 파일과 동일하게 렌더링되어야 합니다. 의도적으로 네트워크에 구애받지 않는 형식에 필수 네트워크 콜백을 추가하면 해당 설계 원칙이 깨집니다.
일부 PDF 보안 솔루션은 문서가 열릴 때 네트워크 요청을 시도하는 JavaScript를 PDF에 포함시켜 이러한 제한을 우회합니다. 이 접근 방식은 작동할 수 있지만 보안상의 이유로 대부분의 PDF 리더가 기본적으로 JavaScript 실행을 차단하므로 신뢰할 수 없습니다. 사용자가 비활성화하지 않은 경우 Adobe Acrobat은 포함된 JavaScript를 실행할 수 있습니다. Chrome의 PDFium 및 Firefox의 PDF.js를 포함한 브라우저 기반 PDF 뷰어는 PDF JavaScript를 전혀 실행하지 않습니다. 따라서 PDF JavaScript를 기반으로 구축된 읽음 확인 메커니즘은 일부 수신자에게는 실행되고 다른 수신자에게는 자동으로 실패하므로 배달 확인이 필요한 모든 목적에 적합하지 않습니다.
JavaScript 기반 읽기 확인 방법 및 신뢰성 제한
가장 일반적인 DIY 읽음 확인 구현은 문서 열기 이벤트에서 실행되는 JavaScript 작업을 PDF에 포함합니다. 스크립트는 고유한 문서 식별자와 현재 타임스탬프를 포함하는 URL을 구성한 다음 일반적으로 숨겨진 이미지 또는 XMLHttpRequest로 해당 URL을 로드하려고 시도합니다. 대상 URL을 수신하는 웹 서버는 요청을 기록하고 해당 식별자를 가진 문서가 당시 열렸음을 기록합니다.
실제로 신뢰성 문제는 심각합니다. Adobe Acrobat은 PDF가 외부 사이트에 연결을 시도할 때 사용자에게 경고하고 연결을 차단하는 옵션을 제공합니다. 대부분의 기업 PDF 배포에서는 보안 정책에 따라 기본적으로 외부 연결을 차단하도록 Acrobat을 구성합니다. 브라우저 기반 뷰어는 JavaScript 엔진이 스크립트에 필요한 네트워킹 API를 구현하지 않기 때문에 요청을 완전히 무시합니다. 모바일 PDF 리더도 마찬가지로 내장된 JavaScript 네트워크 호출을 차단하거나 무시합니다. 보낸 사람은 JavaScript가 활성화되고 외부 연결이 허용된 데스크톱 Acrobat을 사용하는 수신자로부터만 읽음 확인을 받습니다. 이는 일반적인 수신자 집단에서 소수입니다.
JavaScript가 성공적으로 실행되더라도 읽음 확인은 제한된 정보를 제공합니다. JavaScript를 실행하는 PDF 리더로 PDF를 열었다는 것만 확인합니다. 사람이 문서를 읽었는지, 문서가 올바르게 렌더링되었는지, 수신자가 첫 페이지를 스크롤했는지는 확인하지 않습니다. 들어오는 모든 PDF를 열고 색인화하는 자동화된 문서 처리 시스템에서 생성된 읽음 확인은 실제 수신자가 여는 것과 구별할 수 없는 오탐지를 생성합니다.
호스팅 PDF 링크를 통한 서버측 추적
내장된 JavaScript에 대한 보다 안정적인 대안은 호스팅된 PDF 링크를 사용한 서버측 추적입니다. 발신자는 PDF를 이메일에 첨부하는 대신 문서를 웹 서버에 업로드하고 수신자에게 문서를 보거나 다운로드할 수 있는 링크를 보냅니다. 서버는 각 액세스의 타임스탬프, IP 주소 및 브라우저 사용자 에이전트 문자열을 포함하여 PDF URL에 대한 모든 요청을 기록합니다. 이 서버 측 접근 방식은 PDF가 제공되기 전에 HTTP 요청 수준에서 추적이 발생하므로 수신자의 PDF 리더, JavaScript 설정 또는 장치 유형에 관계없이 모든 액세스를 캡처합니다.
서버 측 추적은 또한 보다 세부적인 분석을 가능하게 합니다. 서버는 수신자가 전체 파일을 다운로드했는지 아니면 처음 몇 킬로바이트만 가져왔는지 기록할 수 있습니다. 이는 수신자가 문서를 보았거나 링크만 클릭했을 가능성이 있는지를 나타냅니다. 페이지별 로딩을 지원하는 뷰어를 통해 PDF가 제공되는 경우 서버는 액세스된 페이지와 액세스 시간을 추적할 수 있습니다. 이러한 참여 지표는 단순한 공개/미공개 바이너리 신호보다 문서 상호 작용에 대한 훨씬 더 풍부한 그림을 제공합니다.
서버 측 추적의 주요 단점은 문서 전달 워크플로우를 이메일 첨부에서 호스팅 링크로 변경해야 한다는 것입니다. 이메일 첨부 파일로 PDF를 받는 데 익숙한 수신자는 호스팅된 문서에 액세스하기 위해 추가 클릭이 불편할 수 있습니다. 첨부 파일 기반 전달이 요구되는 PDF 공유 워크플로의 경우 서버측 추적은 첨부 파일 모델을 대체할 수 없습니다. 링크 기반 전달이 허용되는 워크플로의 경우 가장 안정적인 읽기 추적을 제공합니다.
PDF 읽기 추적을 위해 타사 문서 분석 플랫폼 사용
몇몇 상업용 문서 분석 플랫폼은 PDF 읽기 추적을 관리형 서비스로 제공합니다. 이러한 플랫폼은 각 문서와 각 수신자에 대해 고유한 추적 링크를 생성하고, 자체 인프라에서 PDF를 호스팅하며, 열림 시간, 예상 읽기 시간, 페이지 수준 참여 및 수신자가 다른 사람과 링크를 공유하는 경우 향후 추적을 보여주는 대시보드를 제공합니다.
엔터프라이즈급 플랫폼은 문서 추적에 수반되는 개인 정보 보호 및 규정 준수 문제를 해결합니다. 수신자에게 투명성 알림을 제공하고, 추적 공개에 대한 GDPR 및 CCPA 요구 사항을 준수하며, 추적 데이터 저장 기간을 제한하는 데이터 보존 정책을 제공합니다. 또한 CRM 및 문서 관리 시스템과의 통합을 지원하므로 읽기 상태 업데이트가 영업, 법무 및 규정 준수 팀이 이미 작업하고 있는 시스템에 자동으로 전달됩니다.
계약 제안, 규제 통지 또는 주주 커뮤니케이션과 같이 법적으로 중요한 문서에 대한 신뢰할 수 있는 읽기 확인이 필요한 조직의 경우 서버 측 링크 추적과 상용 분석 플랫폼의 결합을 통해 전달 및 액세스에 대한 방어 가능한 증거를 제공할 수 있습니다. 플랫폼의 분석과 결합된 서버 로그는 자체 보고된 이메일 읽음 확인 또는 신뢰할 수 없는 내장 JavaScript 알림보다 훨씬 강력한 감사 추적을 생성합니다.
타사 서비스 없이 PDF 읽기 확인 시스템을 직접 구축할 수 있습니까?
자체 호스팅 PDF 읽기 추적 시스템을 구축하려면 PDF 및 로그 액세스 요청을 호스팅하는 웹 서버, 추적 식별자 및 액세스 기록을 저장하는 데이터베이스, 고유하게 식별 가능한 PDF를 생성하는 문서 생성 워크플로라는 세 가지 구성 요소가 필요합니다.
각 구성 요소는 개별적으로 간단합니다. 통합과 운영 유지 관리에 노력이 축적됩니다.
웹 서버 구성 요소가 가장 간단합니다. 액세스 로깅이 활성화된 모든 표준 HTTP 서버, Apache, Nginx 또는 클라우드 스토리지 서비스는 PDF URL에 액세스할 때 기록할 수 있습니다. 데이터베이스 구성 요소는 문서 식별자를 수신자 이메일 주소 또는 이름에 매핑하는 테이블과 타임스탬프 및 IP 주소와 함께 각 액세스 이벤트를 기록하는 테이블을 저장합니다. 간단한 웹 애플리케이션 대시보드는 이러한 테이블을 쿼리하여 전송된 각 문서의 읽기 상태를 표시합니다.
운영상의 복잡성은 시간이 지남에 따라 시스템을 유지 관리하는 데서 발생합니다. 액세스 로그는 누적되며 순환 및 보관 정책이 필요합니다. 액세스 로그의 IP 주소는 GDPR에 따라 개인 데이터로 간주될 수 있으므로 시스템에서 데이터 보존 및 삭제 기능을 구현해야 합니다. 추적 시스템이 일시적으로라도 오프라인 상태가 되면 문서 링크를 클릭하는 수신자는 문서 대신 오류 메시지를 받게 되는데, 이는 전혀 추적하지 않는 것보다 더 나쁩니다. 서버 측 추적 기능이 있는 대화형 PDF은 기존 웹 인프라와 개발 리소스를 갖춘 팀을 위한 합리적인 구축입니다. 이러한 리소스가 없는 팀의 경우 상용 플랫폼이 더 실용적인 선택입니다.
WukongPDF의 문서 공유 기능에는 각 수신자가 공유 문서를 열 때 기록하는 액세스 추적 기능이 있는 링크 기반 전달이 포함됩니다. 이 서버 측 접근 방식은 내장된 JavaScript 추적의 제한 없이 안정적인 읽기 확인을 제공하며, 추적 데이터는 별도의 분석 플랫폼이 필요하지 않고 문서 관리 워크플로와 통합됩니다.
PDF 읽기 추적의 개인 정보 보호 차원은 모든 구현에서 명시적인 주의를 기울일 가치가 있습니다. 추적된 문서의 수신자에게는 자신의 액세스가 기록되고, 어떤 데이터가 기록되며, 해당 데이터가 보존되는 기간 및 목적이 무엇인지 알려야 합니다. GDPR이 적용되는 관할권에서는 이러한 공개가 단순한 모범 사례가 아닌 법적 요구 사항입니다. 모든 상황에서 투명한 추적 관행은 문서 수신자와의 신뢰를 유지하는 동시에 발신자에게 필요한 배달 확인을 제공합니다.
궁극적으로 맞춤형 읽음 확인 시스템 구축과 상용 플랫폼 사용 사이의 선택은 조직의 기술 리소스, 문서 양 및 읽음 확인에 대한 법적 방어 요건에 따라 결정되는 제작 대 구매 결정으로 귀결됩니다. 매달 몇 개의 추적 문서를 보내는 조직은 기본 서버 측 로깅 및 수동 상태 확인을 통해 관리할 수 있습니다. 특히 읽기 확인이 규정 준수에 중요한 법률, 금융 또는 규제 상황에서 매주 수백 개의 추적 문서를 보내는 조직은 전용 문서 분석 플랫폼이 제공하는 신뢰성, 감사 추적 및 지원의 이점을 누릴 수 있습니다.
수신자 작업, 소프트웨어 설치, JavaScript 권한 변경이 필요하지 않은 문서 추적 보내기는 가장 신뢰할 수 있는 읽기 확인 데이터를 생성합니다. 서버측 링크 추적은 이러한 세 가지 목표를 모두 달성하며 전문 비즈니스 커뮤니케이션 워크플로에서 PDF 읽음 확인 구현에 대한 현재 모범 사례를 나타냅니다.