봇 트래픽과 클릭 품질: 여러분의 클릭 수는 무엇을 세고 있습니까

어떤 리디렉션 서비스든 요청을 몇 건 처리했는지는 알려 줍니다. 그 요청 가운데 몇 건이 사람이었는지 알려 주는 서비스는 거의 없는데, 모든 보고서가 말없이 담고 있다고 전제하는 숫자가 바로 그것입니다. 링크는 열린 웹에 놓여 있습니다. 색인되고, 미리보기가 만들어지고, 검사받고, 감시받고, 긁혀 갑니다. 그 상당 부분은 게시하고 몇 초 안에, 아직 아무도 그 글을 보지 않은 시점에 일어납니다.

이 글은 원본 카운터와 고객 회의에서 방어할 수 있는 숫자 사이에 놓인 계층을 다룹니다. 어떤 자동화를 통과시키고 싶은지, 크롤러를 이름으로 식별하는 것이 왜 식별이 아닌지, 네트워크 종류가 무엇을 증명하는지, 그리고 그것을 어떻게 규칙과 정직한 보고서로 바꾸는지입니다.

원본 카운터는 요청 카운터입니다

리디렉션 엔진은 도착한 것을 셉니다. 그것이 이 방식의 미덕입니다. 여러분이 통제하지 못하는 목적지에도 동작하고, 차단기에서 살아남으며, 세션도 유입 경로도 없는 포스터의 QR 스캔까지 셉니다. 링크 클릭 추적 가이드에서 다룬 그대로입니다. 동시에 그 숫자에 단서가 필요한 이유이기도 합니다.

단축 링크에 도달하는 자동화된 트래픽은 알아볼 수 있는 몇 가지 무리로 나뉩니다.

• 링크 검사기. 이메일 사업자, 메시징 플랫폼, 보안 게이트웨이는 전달 시점에 링크가 어디로 가는지 확인하려고 링크를 가져갑니다. 발송 직후 1분 사이, 아직 전달이 끝나기도 전에 링크에 클릭이 쌓이는 이유입니다.
• 미리보기 수집기. 소셜 네트워크와 채팅 앱은 제목과 이미지가 담긴 카드를 만들려고 링크를 가져갑니다. 제대로 만든 리디렉터는 이들을 라우팅해서 집계하는 대신 메타데이터로 응답합니다.
• 검색과 SEO 크롤러. 검색 색인기, 그리고 눈에 띄는 것은 무엇이든 훑고 다니는 상용 SEO 도구입니다.
• 모니터. 여러분 자신의 것을 포함한 가동 상태 점검입니다. HEAD 요청에 클릭을 세지 않고 응답하는 것도 이 때문입니다.
• 스크래퍼와 탐침. 가격 수집기, 주소 수확기, 그리고 다른 곳으로 돌려 쓸 링크를 찾아다니는 스캐너입니다.

이 가운데 둘은 여러분이 부른 트래픽이고, 하나는 중립적인 인프라이며, 하나는 반갑지 않습니다. "봇 차단"은 이들을 모두 똑같이 다룹니다.

좋은 봇, 그리고 그들을 식별하는 단 한 가지

사용자 에이전트는 주장일 뿐입니다

사용자 에이전트는 보내는 쪽이 직접 적는 헤더입니다. 무엇이든 그 자리에 아무 문구나 넣을 수 있으므로 스스로를 Googlebot이라고 부르는 요청은 아무것도 증명하지 못하며, 스스로를 Chrome이라고 부르는 스크래퍼가 자기 정체를 밝히는 스크래퍼보다 흔합니다. 그래도 사용자 에이전트 대조는 제 몫을 합니다. 정직하게 자기를 밝히는 자동화를 잡아내고 다른 신호를 뒷받침하기 때문입니다. 다만 분류기 안에서 이것은 분명히 약한 신호입니다. 확인은 해 주되 결정은 하지 않습니다.

검증은 보내는 쪽이 통제하지 못하는 것을 시험합니다

요청이 도착한 주소는 보내는 쪽이 쓸모 있는 방식으로 고를 수 있는 것이 아니며, 그래서 시험 대상으로 알맞습니다. 방법은 두 가지입니다.

일부 사업자는 자사 크롤러가 쓰는 주소 대역을 공개합니다. Google과 Bing, Apple이 모두 그렇게 하며, 그 파일은 하루에 한 번 빠른 조회용 구조로 받아 둡니다. 그래서 목록에 있는 대역에서 온 요청은 요청 시점에 네트워크 작업을 전혀 하지 않고도 확인됩니다.

공개 목록이 없는 크롤러, 이를테면 Yandex와 DuckDuckGo, Baidu, Petal의 검증은 두 단계짜리 이름 확인이며, 두 단계 모두 반드시 필요합니다.

Claim: "Googlebot" in the user agent

Step 1  reverse lookup of the address
        <address>  ->  crawl-<address>.googlebot.com   ends in the crawler's domain
Step 2  forward lookup of that name
        crawl-<address>.googlebot.com  ->  <address>    matches the original address
        verdict: verified crawler

Same claim, different address

Step 1  203.0.113.9  ->  host9.example-hosting.net     not the crawler's domain
        verdict: not verified, the claim is rejected

정방향 단계는 선택이 아닙니다. 주소 대역을 통제하는 쪽은 대개 그 역방향 레코드를 원하는 대로 설정할 수 있으므로, 역방향 이름 하나만으로는 얼마든지 지어낼 수 있습니다. 그 이름을 정방향으로 풀어 원래 주소가 되돌아오는 것을 확인해야 고리가 닫힙니다.

리디렉터 앞에 놓인 CDN도 자체적으로 검증된 봇 분류를 수행하며, 이 판정은 보내는 쪽이 위조할 수도 없고 읽는 비용도 크지 않습니다. 그래서 확인은 권위가 높은 순서대로 받습니다. 공개 목록, CDN 검증, 역방향과 정방향 이름 확인, 그다음이 주소 데이터베이스에서 알려진 검색 엔진 크롤러 대역에 속하는지 여부입니다.

이름 확인이 방문자를 기다리게 하는 일이 없는 이유

역방향 조회는 지연 시간을 예측할 수 없는 네트워크 요청이고, 리디렉션은 밀리초가 사람 눈에 그대로 드러나는 유일한 지점입니다. 그래서 이 조회는 결코 동기적으로 실행되지 않습니다. 규칙이 크롤러가 검증되었는지 묻는데 답이 캐시에 없으면, 규칙은 검증되지 않은 것으로 처리하고 조회는 백그라운드에서 돌며, 같은 주소에서 오는 다음 클릭 때에는 답이 캐시에 있습니다. "검증되지 않음" 쪽으로 기울어 틀리면 올바른 분류 하나를 잃지만, 동기 조회 쪽으로 기울어 틀리면 실제 사람이 요청마다 지연을 치릅니다.

네트워크 종류는 맥락이지 판결이 아닙니다

방문자가 스스로를 무엇이라고 주장하는지와 별개로, 그가 지나온 주소 대역에는 이미 알려진 성격이 있습니다. 이 기능을 떠받치는 상용 주소 데이터베이스는 대역을 몇 가지 종류로 나눕니다.

| 종류 | 이 대역이 무엇인지 | 데이터베이스에 담긴 IPv4 대역 중 비중 | | --- | --- | --- | | 목록에 없음 | 대체로 가정용과 회사용인 일반 주소 | 72.1% | | 데이터센터, 호스팅, 클라우드 | 서버, 클라우드 인스턴스, 호스팅형 브라우저 | 15.3% | | 공개 프록시 | 누구나 거쳐 갈 수 있는 열린 중계기 | 9.2% | | 상용 VPN | 개인용과 업무용 VPN 서비스 | 3.2% | | 검색 엔진 크롤러 | 크롤러의 것으로 알려진 대역 | 0.17% | | TOR 출구 노드 | TOR 네트워크의 출구 지점 | 0.005% | | 웹 익명화 서비스 | 브라우저로 쓰는 프록시 페이지 | 0.005% |

이 표는 잘못 읽기 쉬우니 주의해서 보십시오. 저 비중은 참조 데이터베이스에 담긴 주소 대역의 비중이지 누군가의 트래픽 비중이 아닙니다. 가정용 ISP 대역 하나는 엄청나게 많은 사람을 담당하지만, 호스팅 대역 하나는 아무도 담당하지 않을 수 있습니다. 이 표가 말해 주는 것은 분류가 무엇인지, 그리고 주소 공간이 그 분류로 얼마나 잘게 나뉘는지뿐이며, 여러분의 캠페인이 무엇을 받았는지에 대해서는 아무 말도 하지 않습니다.

숫자보다 해석이 중요합니다. 데이터센터 주소라고 해서 봇인 것은 아닙니다. 회사 네트워크는 직원을 클라우드 인프라를 거쳐 내보내고, 개인정보에 민감한 소비자는 쇼핑까지 포함해 모든 일에 상용 VPN을 쓰며, 호스팅형 브라우저로 웹을 읽는 것도 평범한 일입니다. 데이터센터 클릭을 모조리 지우면 실제 고객이 지워집니다. 네트워크 종류는 확신을 옮길 뿐이며, 그 자체로는 라우팅에 관한 사실 하나일 뿐입니다.

품질 점수와 그 쓰임새

분류기는 두 가지를 내놓습니다. 하나는 방문자 종류로 사람, 검색 크롤러, 라이브러리, 데이터센터, VPN, TOR, 알 수 없음 가운데 하나이고, 다른 하나는 1에서 100까지의 품질 점수와 그 점수가 나온 근거입니다. 입력은 위에서 다룬 것들에 행동 신호가 더해집니다. 같은 주소가 1분 안에 같은 링크를 몇 번이나 두드리는지, 요청이 언어 설정을 담고 있기는 한지, 헤더 구성이 사용자 에이전트가 주장하는 플랫폼과 맞아떨어지는지입니다.

점수는 일부러 스위치로 만들지 않았습니다. 점수가 낮다는 이유로 차단되는 것은 아무것도 없습니다. 점수는 판정을 설명하고 보고서에 반영될 뿐이며, 차단은 따로 명시해서 설정합니다. 오탐의 비용은 한쪽으로 크게 기울어 있습니다. 봇을 사람으로 세면 백분율이 일그러지는 데 그치지만, 고객을 봇으로 차단하면 그 사람은 페이지에 닿지 못하고 여러분에게 아무 말도 해 주지 않습니다.

종류와 점수, 근거는 지역 정보와 트래픽 품질 분류에 나타나며, 그 안에서 미디어 바이어가 손을 뻗는 것은 네트워크 표입니다. 자율 시스템 번호, 제공업체 이름, 대역 종류, 총 클릭 수와 사람의 클릭 수가 각각 다른 열에 놓입니다. 제공업체별로 본 이 마지막 두 열의 차이가 대개 트래픽 구매의 전말입니다. 전체 항목은 지역 분석 문서에 정리되어 있습니다.

판정을 결정으로 바꾸기

판정은 그것을 가지고 무언가를 할 수 있을 때에만 쓸모가 있습니다. 트래픽 필터링 규칙은 순서가 있는 조건 목록을 링크에 붙이고, 리디렉션 목적지가 정해지기 전에 엣지에서 평가하며, 가장 먼저 일치한 규칙이 결과를 정합니다. 규칙이 하나도 없는 링크는 추가 작업을 단 한 번도 수행하지 않습니다.

여기서 관련 있는 조건은 방문자 종류, 검증된 크롤러 여부, 네트워크 종류, 품질 점수 기준선이며, 여기에 지역, 자율 시스템, 주소 목록, 기기, 언어, 유입 경로, 사용자 에이전트 패턴, 캠페인 태그, 현지 시각, 첫 방문과 재방문의 구분이 함께 놓입니다. 결과는 통과, 404 차단, 410 차단, 다른 목적지로 보내기, 브랜드 안내 페이지 보여 주기, 또는 방문을 의심스러운 것으로 표시하면서 통과시키기입니다.

이것을 실제 운영에서 안심하고 돌릴 수 있는지는 세 가지 설계 세부가 결정합니다.

조건은 세 가지 값을 갖습니다. 충족됨, 충족되지 않음, 또는 데이터가 없어 답할 수 없음 가운데 하나이며, 답할 수 없음은 결코 일치로 세지 않습니다. 주소 데이터베이스를 쓸 수 없으면 네트워크 종류를 조건으로 삼은 규칙은 걸리지 않고 방문자는 평소 목적지에 도착합니다. 필터링은 열린 쪽으로 실패하며, 결코 닫힌 쪽으로 실패하지 않습니다.

뒤집기는 확실한 답만 뒤집습니다. "독일을 제외한 전부"라고 쓴 규칙은 국가를 판별하지 못한 방문자에게 조용히 걸리지 않습니다. 선의로 만든 지역 규칙이 장애로 변하는 가장 흔한 경로가 바로 이것입니다.

통과 동작이 있는 이유는 필터를 확인할 수 있게 하려는 것입니다. 트래픽을 통과시키면서 규칙이 걸렸다는 사실만 기록하는 규칙이야말로, 무언가를 차단하게 두기 전에 필터를 시험하는 방법입니다. 통과 모드로 돌리고, 필터링 분류를 읽고, 의도한 것을 잡아내는지 확인한 다음에 동작을 바꾸십시오.

데이터센터에 관한 정책이 링크 하나에 관한 이야기인 경우는 거의 없으므로, 일반 정책은 워크스페이스 전체 규칙 묶음에 두고, 먼저 평가되는 링크 자체의 규칙으로 그 일반적인 금지 위에 예외를 얹으십시오. 여러분의 가동 상태 모니터가 자기가 지켜보는 그 링크에서 계속 동작하는 것도 이 방식 덕분입니다. 규칙과 주소 목록의 한도는 트래픽 규칙 문서에 정리되어 있습니다.

첫 방문 규칙을 쓰기 전에 알아 둘 것이 하나 있습니다. 첫 방문과 재방문을 구분하려면 리디렉션 도메인에 작은 쿠키가 필요하며, 이 쿠키는 규칙이 실제로 그 질문을 던질 때에만 설정됩니다. 여기에는 개인정보 측면의 결과가 따르므로, 기본으로 켜 두는 대신 구조상 필요할 때에만 켜지도록 했습니다.

고객 보고서에서 달라지는 것

이 작업이 값을 하는 곳이 바로 여기이며, 핵심은 대부분 어떤 숫자를 지면에 올리느냐입니다.

| 보고서의 항목 | 품질 계층이 없을 때 | 있을 때 | | --- | --- | --- | | 대표 숫자 | 클릭 수 | 사람의 클릭 수, 그 옆에 총 클릭 수 | | 구성 | 없음 | 사람, 검증된 크롤러, 데이터센터, VPN, TOR, 알 수 없음 | | 제공업체 표 | 네트워크별 클릭 수 | 네트워크별 클릭 수와 사람의 클릭 수 | | 걸러진 트래픽 | 보이지 않음 | 규칙별 물량과 각 규칙이 적용한 동작 | | 급증에 대한 설명 | "화요일에 무슨 일이 있었다" | 급증이 어느 종류와 어느 네트워크에서 왔는지 |

그 보고서를 자세하기만 한 것이 아니라 정직한 것으로 만드는 습관은 두 가지입니다. 언제나 두 숫자를 함께 보여 주십시오. 총합이 옆에 없는 사람의 클릭 수는 총합이 불편한 숫자였으리라는 의심을 부릅니다. 그리고 무엇을 왜 걸렀는지 보고하십시오. 일치한 이벤트마다 규칙 식별자와 동작이 저장되므로, 그 뒤에 수정하거나 삭제한 규칙에 대해서도 필터링 분류는 여전히 제대로 읽힙니다.

대행사에게 제공업체 표는 상업적인 도구이기도 합니다. 물량은 보내는데 사람의 클릭이 거의 없는 네트워크는 공급자와 나눌 대화이며, 그 대화는 뭉뚱그린 총계보다 제공업체별 분류가 있을 때 훨씬 수월합니다. 이것이 고객 보고와 정산에 어떻게 들어맞는지는 대행사 솔루션과 제휴 마케팅 솔루션 페이지에서 다룹니다.

이 분야의 사업자들이 좀처럼 하지 않는 말이라 분명히 해 둡니다. 분류는 확률적입니다. 가정용 주소에서 진짜 브라우저를 돌리는 작정한 스크래퍼는 사람으로 분류되며, 시장에 나온 어떤 제품도 다르게 말해 주지 못합니다. 이 계층은 규모가 크고 판별이 쉬우며 스스로를 정직하게 밝히는 다수의 자동화를 걷어내고, 나머지를 조사할 근거를 남깁니다. 확실하다는 인상을 주는 보고서는 언젠가 고객 앞에서 틀립니다.

실제로 굴러가는 순서

1. 분석에서 봇 필터링은 기본으로 켜 두고, 사람이 링크를 봤을 리 없는 시점에 시작된 급증은 반대가 증명되기 전까지 자동화로 간주하십시오.
2. 대표 숫자보다 구성 분류를 먼저 읽으십시오. 그 채널치고 이례적인 자동화 비중은 그 자체가 발견입니다.
3. 네트워크 표에서 총 클릭 수와 사람의 클릭 수가 크게 벌어지는 제공업체를 확인하십시오.
4. 첫 규칙은 통과 모드로 쓰고, 일주일 동안 필터링 분류를 지켜본 다음, 규칙에 걸리는 물량이 의도한 대로 보일 때에만 차단 동작으로 올리십시오.
5. 검증된 크롤러는 계속 통과시키고, 여러분 자신의 모니터는 워크스페이스 정책보다 위에 놓인 링크 수준 규칙으로 예외 처리하십시오.
6. 사람의 클릭 수와 총 클릭 수를 함께 보고하고, 걸러진 물량은 조용히 빼는 대신 드러내십시오.

바탕에 깔린 생각은 단순합니다. 클릭은 요청이고, 요청에는 출처가 있으며, 출처는 측정할 수 있습니다. 이 일이 값어치를 하는 이유는 그다음에 따라오는 효과에 있습니다. 사람의 클릭을 기준으로 계산한 전환율은 흔들리지 않고, 호스팅 대역을 걷어낸 지역 분류는 인프라가 아니라 시장을 설명하며, 자기 트래픽의 구성을 한 번 본 고객은 숫자가 진짜냐고 더는 묻지 않습니다.