독자를 지켜보기 위해 스크립트 하나를 설치했습니다.
그것은 되받아 감시하며, 다른 곳으로 보고합니다.

흔히 그렇습니다. 다만 그 이유는 "셀프 호스팅이면 괜찮다"보다 더 정밀합니다. 여기에는 두 개의 별개 규칙이 작동합니다. ePrivacy 지침 5(3)조 — 흔히 쿠키법이라 부르는 그 조항 — 은 방문자가 요청한 서비스에 반드시 필요한 경우가 아니라면, 방문자의 기기에 정보를 저장하거나 그로부터 정보를 읽어 오는 데 동의를 요구합니다. 이는 쿠키뿐 아니라 localStorage, sessionStorage, 그 외에 남겨 두는 모든 것에 적용되며, 그 데이터가 개인정보인지 여부와도 무관하게 적용됩니다. 기기에 아무것도 기록하지 않는 도구는 이 조항을 그저 발동시키지 않습니다. GDPR은 두 번째 규칙이며 이는 사라지지 않습니다. 모든 요청에서 여전히 IP 주소와 사용자 에이전트 문자열을 수신하게 되며, IP 주소는 웹사이트 운영자의 손에서는 개인정보입니다(유럽사법재판소, Breyer 사건, C-582/14). 쿠키를 쓰지 않는 분석 서버가 하는 일은, 매일 회전하는 솔트로 그 IP를 해시한 뒤 폐기하는 것입니다. 그래서 데이터베이스에 남는 것은 한 사람이 아니라 하루 단위, 사이트 단위의 가명입니다. 이는 좁고 잘 문서화된 처리 작업으로, 대부분의 운영자가 정당한 이익을 근거로 삼고 있으며, 여러 감독 기관이 순수한 관객 측정이 동의 대상에서 제외되는 기준을 발표한 바 있습니다. 이는 정당화 가능한 입장이지 마법의 단어가 아닙니다. 무엇을, 왜, 얼마나 오래 수집하는지를 적어 두고, 벤더의 랜딩 페이지가 아니라 여러분 자신의 규제 기관이 낸 지침을 읽으십시오. 이 페이지의 어떤 내용도 법률 자문이 아닙니다.

Umami입니다. 단일 Node 애플리케이션과 PostgreSQL 데이터베이스 하나로 이루어져 있고, 메모리 1 GB 안에서도 편안하게 돌아가며, 대시보드는 처음 봐도 읽기 쉽고, 기본값부터 쿠키가 없으며, 인스턴스 하나로 여러분이 소유한 모든 사이트를 즐겁게 서비스할 수 있습니다. 블로그, 문서 사이트, 상점, 회사 사이트에서 Google Analytics를 교체하려는 압도적 다수의 사람들에게는 이것이 정답이며, 나머지 셋은 굳이 겪지 않아도 될 고민입니다. 대신 퍼널, 수익 목표, 더 강력한 공개 대시보드를 원하고 그를 위해 ClickHouse를 기꺼이 운영하겠다면 Plausible Community Edition을 고르십시오. 세그먼트, 코호트, 커스텀 리포트, 이커머스 어트리뷰션, 원본 로그 임포트 등 Google Analytics의 기능 집합이 정말로 필요하고, 예약된 아카이빙 작업이 딸린 대형 PHP 애플리케이션을 운영하는 것을 받아들일 수 있다면 Matomo를 고르십시오. 페이지에 JavaScript를 전혀 두고 싶지 않다면 GoAccess를 고르십시오.

이 둘은 서로 다른 것을 세고 있으며, 그 차이는 두 방향으로 동시에 벌어지기 때문입니다. 위쪽 방향: 동의 배너 뒤에 있는 Google Analytics는 수락 버튼을 누른 방문자만 볼 수 있는데, 유럽에서는 이 비율이 흔히 절반 정도이며, 배너 없는 쿠키리스 카운터는 모든 사람을 봅니다. 또 다른 위쪽 방향: 새 엔드포인트는 여러분 자신의 도메인에 있으며, 잘 알려진 트래커로 가는 요청을 걸러내는 필터 목록에 올라 있지 않습니다. 아래쪽 방향: 매일 회전하는 해시는 내일의 같은 사람을 알아보지 못하므로, 월요일과 목요일에 방문한 독자는 재방문자 한 명이 아니라 방문자 두 명으로 집계됩니다 — 세션은 하루 안에서만 이어지고 날짜나 기기를 넘어서는 이어지지 않습니다. 또 다른 아래쪽 방향: 대부분의 셀프 호스팅 도구는 보수적인 봇 필터를 기본 제공하며 Discover식의 부풀림이 없습니다. 실용적인 조언은 두 수치를 맞추려는 시도를 그만두는 것입니다. 2주 동안 두 도구를 함께 돌려서 자신만의 비율을 파악하고, 그것을 메모지에 적어 둔 다음, Google 태그를 삭제하고 새 수치를 이제부터의 기준선으로 사용하십시오. 의사 결정에서 중요한 것은 추세의 모양과 페이지·소스 간의 상대적 순위이며, 둘 다 이전 과정에서 그대로 유지됩니다.

부분적으로는 그렇습니다. 그리고 그 정확한 방식을 아는 것은 그럴 만한 가치가 있습니다. 그 작동 방식이 사람들이 짐작하는 것보다 훨씬 단순하기 때문입니다. 대형 필터 목록은 패턴으로 작동합니다. 호스팅형 서비스들의 호스트명, 그리고 널리 알려진 파일명과 경로명 몇 가지입니다 — plausible.js, umami.js, matomo.php로 끝나는 요청은 어떤 서버로 가든 알아볼 수 있습니다. 소프트웨어를 stats.example.com으로 옮기더라도 기본 파일명을 그대로 쓴다면 여전히 일부 기술 성향 방문자를 잃게 됩니다. 정직한 해결책은 두 가지이며, 서로 겹쳐 적용됩니다. 스크립트와 수집 엔드포인트의 이름을 트래커 이름처럼 보이지 않는 것으로 바꾸십시오 — 이 도구들은 모두 이를 지원하며, 설정 한 줄이면 됩니다. 그리고 리버스 프록시가 전달하는, 메인 도메인의 한 경로를 통해 사이트 자체와 같은 오리진에서 이를 제공하십시오. 그러면 차단할 제3자 요청이 남지 않습니다. 이 둘을 합치면 손실 대부분을 되찾을 수 있습니다. 전부를 되찾지는 못할 것이고, 그러기를 바라서도 안 됩니다. 엄격한 필터 목록에 JavaScript까지 꺼 둔 방문자는 이미 하나의 선택을 한 것이고, 그에 대한 올바른 대응은 군비 경쟁이 아니라 서버 로그입니다.

물어볼 만한 질문이며, 답은 그 차단기가 무엇을 막아 주고 있었는지에 달려 있습니다. 필터 목록에는 뭉뚱그린 도구 하나와 매우 다른 두 대상이 있습니다. 한 사람을 만 개의 사이트에 걸쳐 추적해 프로필을 만드는 애드테크 네트워크와, 어느 사이트 운영자에게 자신의 문서 페이지가 어제 400번 읽혔다고 알려 주는 카운터입니다. 첫 번째를 막는 것은 감시에 맞서 스스로를 지키는 행동입니다. 두 번째를 막는 것은 둘을 구별하지 못하는 규칙이 낳은 부수적 피해입니다. 자신의 카운터를 자신의 도메인에서 제공하는 것은 방어망을 뚫고 트래커를 밀반입하는 일이 아니라, 원래 존재할 필요가 없었던 제3자 요청 하나를 없애는 일이며, 어차피 같은 방문은 여러분의 접근 로그에도 한 줄을 남깁니다. 이것이 정당화되지 않는 지점은, 프록시하는 대상이 여기서 설명한 것과 다른 것이 되는 순간입니다 — 사이트 간 식별자나 핑거프린팅, 혹은 광고 플랫폼으로의 파이프라인을 추가한다면 차단기가 옳았던 것이고 프록시는 거짓이 됩니다. 검증은 간단하며 한 번쯤 스스로에게 적용해 볼 만합니다. 이 엔드포인트가 정확히 무엇을 수집하는지 설명하는 페이지를 공개할 수 있고, 독자가 그것을 보고 어깨를 으쓱하고 넘길 수 있겠습니까? 그렇다면 프록시하십시오. 그렇지 않다면 문제는 프록시가 아닙니다.

걱정하는 것보다는 작으며, 예외가 하나 있습니다. Umami는 Node 프로세스와 Postgres 데이터베이스로 이루어져 있습니다. 일반적인 사이트라면 메모리 1 GB 아래에서 안정되고, 데이터베이스는 페이지뷰당 텍스트 한 줄 정도의 크기로 커지므로, Sentinel — 2 vCPU, 4 GB, 120 GB NVMe, 월 $3.90 — 이면 몇 년치 여유가 있습니다. GoAccess는 거의 무시할 수 있는 수준입니다. Matomo는 중간쯤에 있습니다. PHP와 MariaDB는 아카이빙 작업이 돌기 전까지는 크게 요구하지 않지만, 그 작업이 바로 사양을 맞춰야 하는 CPU 스파이크이며, 원본 테이블은 방문당 더 많은 것을 저장하기 때문에 다른 도구보다 더 빠르게 커집니다. 예외는 Plausible Community Edition이며, 그 이유는 Plausible이 아니라 ClickHouse에 있습니다. 컬럼 스토어는 메모리를 희생해 쿼리 속도를 얻도록 만들어져 있어서, 남겨 둔 만큼 마음대로 가져다 씁니다. 제공되는 설정에서 캐시를 제한하면 4 GB에서도 돌아가고, 8 GB에서는 여유롭습니다 — 이것이 바로 $7.90의 Garrison 등급이 이 도구에는 합리적인 최저선인 이유입니다. 어느 경우든 결국 업그레이드를 강제하는 수치는 메모리가 아니라 디스크이며, 6단계에서 이를 막는 방법을 다룹니다.

네, 그리고 이는 이 도구들을 운영하는 일반적인 방식입니다. JavaScript 기반 세 도구 모두 설계상 다중 사이트를 지원합니다. 대시보드에서 각 도메인을 등록하면 각각 고유한 식별자를 받고, 같은 스크립트 엔드포인트가 이들 모두의 방문 기록을 받아들이면서도 리포트는 분리해서 유지합니다. 서버 하나, 인증서 하나, 백업 하나, 업그레이드 하나로 스무 개의 사이트를 처리할 수 있습니다. 목록이 늘어날 때 유의할 점이 두 가지 있습니다. 리포트는 사이트별로 분리되므로, 고객을 위해 사이트를 관리한다면 모두에게 관리자 계정을 넘겨주는 대신 도구 자체의 사용자·팀 권한 기능을 쓰십시오. 그리고 공유 인스턴스가 어떤 의미를 갖는지 계약으로 합의하기 전에 확인하십시오. 여러분이 그들의 방문자 데이터를 쥐고 있는 당사자가 되기 때문입니다. 또한 트래킹 엔드포인트는 공유된 이름이므로, 이를 제공하는 도메인이 목록에 있는 모든 사이트의 소스에 나타나게 됩니다 — 경쟁사가 페이지 소스를 살펴보는 고객에게는 언급할 가치가 있는 사실이며, 4단계에서 다룬 퍼스트파티 경로를 택해야 할 근거이기도 합니다.

많은 부류의 사이트에서는 로그만으로 충분하며, 이는 이용 가능한 측정 방법 중 가장 솔직한 방법입니다. 이미 존재하는 줄(라인)일 뿐이므로 추가로 수집하는 것이 전혀 없기 때문입니다. GoAccess는 웹 서버 접근 로그를 읽어 터미널 리포트나 단일 파일로 완결된 HTML 대시보드를 만들어 냅니다 — 인기 페이지, 리퍼러, 상태 코드, 대역폭, 응답 시간, 사용자 에이전트까지. 정적 사이트, 문서 세트, API라면 이것이 스크립트 태그가 알려 줄 내용의 대부분입니다. 이것이 충분한지는 두 가지 한계가 결정합니다. 로그는 페이지 내부에서 일어나는 일을 볼 수 없습니다. 스크롤 깊이도, 아웃바운드 링크 클릭도, 버튼 이벤트도, 단일 페이지 애플리케이션의 라우트 변경도 알 수 없는데, 이들 중 어느 것도 서버에 닿지 않기 때문입니다. 그리고 로그는 사람이 아니라 요청을 세므로, 캐싱과 이제는 원본 트래픽의 다수를 차지하는 봇 무리에 좌우됩니다 — 필터링은 설정 단계가 아니라 영구적인 유지보수 작업입니다. 여기에는 예상과는 반대 방향의 프라이버시 함정도 있으며, 6단계에서 이를 다룹니다. 지금 분석하고 있는 그 로그에는 전체 IP 주소가 담겨 있는데, 이는 여러분이 거부했던 JavaScript 도구가 보관하던 것보다 더 많은 개인정보입니다.

현실적으로는 불가능하며, 그것과 싸우기보다는 그것을 전제로 계획을 세우는 편이 낫습니다. 넷 중 진지한 임포트 방법을 갖춘 것은 Matomo뿐이며, 그마저도 실질적인 방법은 자신의 웹 서버 로그를 임포트하거나 이전 Matomo 인스턴스를 위한 마이그레이션 도구를 쓰는 것이지, Google이 가공한 리포트를 그대로 옮기는 방법은 아닙니다. Umami와 Plausible Community Edition은 매핑을 직접 작성할 준비가 되어 있다면 API를 통해 일괄 로드를 받아들일 수는 있지만, 그렇게 하면 집계된 데이터로부터 세션과 방문자를 사실상 지어내는 셈이 되고, 결과물은 연속적으로 보이지만 접합점 너머로는 비교할 수 없는 그래프가 됩니다. 실제로 효과가 있는 방법은 이렇습니다. 속성이 사라지기 전에 신경 쓰는 리포트를 Google에서 내보내십시오 — 월간 합계, 인기 페이지, 인기 소스, 전환 수 — CSV로 받아 다른 기록들과 같은 곳에 보관하고, 새 도구는 적어 둔 날짜를 기준으로 새로운 기준선에서 시작하십시오. 그 옛 내보내기 파일은 첫 해에 두 번 정도 참고하고 그 후로는 다시 볼 일이 없을 것이며, 어차피 그 안의 모든 수치는 다른 정의 아래서 측정된 것입니다.

생각보다 적으며, 짧다는 것 자체가 핵심입니다 — 스스로 옹호할 수 있는 한 단락이 어디선가 복사해 온 한 페이지보다 낫습니다. 어떤 도구인지, 그것을 직접 운영하고 있다는 사실을 밝히십시오. 서버의 위치와 법적 운영자 이름도 밝히십시오. "핀란드에서 대여한 서버에서"라고 말할 수 있다는 것이야말로 이 모든 작업의 핵심 이득이기 때문입니다. 방문마다 어떤 것이 기록되는지 밝히십시오. 페이지, 리퍼러, 국가, 기기 및 브라우저 종류, 그리고 매일 바뀌는 솔트로 IP 주소와 사용자 에이전트로부터 만들어 낸, 원래 IP를 복원할 수 없는 가명 식별자입니다. 무엇이 기록되지 않는지도 밝히십시오. 쿠키 없음, 사이트 간 식별자 없음, 프로필 없음, 판매되거나 공유되는 데이터 없음. 근거로 삼는 법적 근거와 보관 기간을 명시하고, 여러분이 적는 수치가 도구에 실제로 설정된 수치와 같은지 확인하십시오. 리버스 프록시가 접근 로그를 보관하고 있다면, 이는 별도의 보관 기간을 가진 별개의 처리 작업입니다 — 이를 언급하십시오, 사람들이 가장 자주 빠뜨리는 부분이기 때문입니다. 그런 다음 그 단락을 실제 설정과 계속 일치시키십시오. 2년 전의 설정을 설명하는 정책은 모호한 정책보다도 못합니다.

"페이지 조회수일 뿐"이라는 말은 분석 데이터베이스가 실제로 무엇인지 과소평가하는 표현이기 때문입니다. 1년 치를 모아 보면 그것은 여러분 사이트의 독자층 그 자체입니다 — 어떤 페이지를, 어떤 순서로, 어느 국가에서, 몇 시에, 어떤 링크를 통해 들어왔는지. 소규모 발행인이나 니치 상점에게는 이것이 사업 계획서와 소스 목록을 한 테이블에 담아 놓은 것과 같습니다. 그리고 관할권의 관점에서 보면, 이는 정확히 상대측이 여러분이 아니라 제공업체에게 요구할 종류의 데이터이기도 합니다. 여기서 두 가지 특성이 따라옵니다. 서버가 어디에 있는지는 어떤 법적 절차가 그 서버에 도달할 수 있는지를 결정합니다. 스톡홀름, 헬싱키, 오슬로, 레이캬비크에 있는 서버는 EEA 내부에 위치하므로 국제 이전 문제 자체가 컴플라이언스 파일에서 완전히 사라지며, 언론 자유 전통이 강한 네 헌정 체제 안에 놓이게 됩니다. 그리고 계정에 누구의 이름이 올라 있는지는 그 계정 자체가 무엇을 드러내는지를 결정합니다. NordBastion에서는 신분증도, 법적 이름도, 카드도 없으며, 청구는 Monero나 Bitcoin으로 결제되고, 여러분의 독자층을 담고 있는 서버는 여권이 첨부된 어딘가의 고객 데이터베이스 한 행이 아닙니다. 관할권 가이드에서 네 곳 각각의 법적 기준선을 자세히 다룹니다.