트래픽 데이터에서 크롤러를 탐지하고 표시하는 방식 개선

관리자 대시보드에서 이제 크롤러 트래픽을 식별할 수 있습니다. 이는 실제 브라우저의 JavaScript를 사용하지만 인간 방문자가 아닌 자동화 봇 및 스크레이퍼를 의미하며, 이러한 페이지뷰를 실제 트래픽 수치와 분리하여 확인할 수 있습니다.

이 주제에서는 이러한 트래픽을 식별하기 위해 우리가 취한 접근 방식과 이 기능을 오늘 바로 활성화하는 방법에 대해 공유하겠습니다.

:microscope: 변경된 사항

Discourse는 표준 봇 사용자 에이전트(예: Googlebot)로 자신을 식별하는 Crawlers(크롤러)를 사이트 트래픽 데이터의 별도 범주로 필터링해 왔습니다. 그러나 현대의 자동화 트래픽은 더 교묘합니다. 완전한 브라우저를 실행하고 JavaScript를 실행하며, 실제 방문인 것처럼 페이지뷰 데이터에 섞여 들어갑니다. 관리자들은 Anonymous(익명) 페이지뷰에서 트래픽 급증을 발견했는데, 이는 스크레이퍼에 의한 것이었거나, AI 봇으로 인해 방문자 수가 부풀려진 경우였습니다. 이들은 실제 익명(즉, 로그인하지 않은) 인간 트래픽과 이를 구별할 방법이 없었습니다.

이 업데이트는 사이트 트래픽 데이터에 Likely Crawlers(예상 크롤러) 범주를 추가합니다. 개선된 크롤러 감지가 활성화되면, 우리의 휴리스틱이 자동화로 판단되는 페이지뷰가 별도로 분리되어 표시되므로 인간 트래픽 수치가 더 정확해집니다.

감지 방식

이 시스템은 행동 신호 세트를 사용하여 각 브라우저 페이지뷰에 점수를 부여합니다:

  • Automation user agent(자동화 사용자 에이전트) — UA가 헤드리스 브라우저나 자동화 도구(HeadlessChrome, Playwright, Puppeteer, Selenium, PhantomJS, jsdom)를 명시적으로 지칭하는 경우
  • Verified crawler ASN(확인된 크롤러 ASN) — IP의 자율 시스템 번호(ASN)가 알려진 크롤러 네트워크(Baidu, Ahrefs, Yandex, Internet Archive 등)인 경우
  • Datacenter ASN(데이터센터 ASN) — IP가 주요 클라우드 또는 호스팅 제공업체의 주소 공간에 있는 경우
  • Velocity(속도) — IP + 사용자 에이전트가 시간당 비정상적으로 많은 페이지뷰를 생성하는 경우
  • Rapid navigation(빠른 탐색) — 페이지뷰 사이의 중앙값 간격이 5초 미만인 경우
  • Session churn(세션 변동) — 동일한 IP + 사용자 에이전트에서 짧은 세션(대부분 페이지 1개)이 많이 발생하는 경우
  • Missing engagement(참여 부재) — 해당 세션 및 인접 세션에서 마우스 움직임, 키 입력, 스크롤과 같은 인간 유사 상호작용이 기록되지 않은 경우
  • Bad referrer ratio(잘못된 리퍼러 비율) — 대부분의 페이지뷰가 리퍼러 없이 또는 외부 리퍼러로 도착하여 사이트 내 탐색이 아닌 직접 URL 접근을 시사하는 경우
  • Single direct request(단일 직접 요청) — 리퍼러가 없는 단일 비참여 페이지뷰. URL에 로케일 매개변수가 포함된 경우 더 높은 점수를 부여
  • Rapid IP rotation(빠른 IP 로테이션) — 단일 세션 내에서 여러 IP가 사용되며, 인간이 할 수 있는 속도보다 빠르게 순환하는 경우
  • Stale Chromium(구형 Chromium) — 참여 신호가 없는 구형 Chrome 버전

여러 신호에서 나온 점수는 누적됩니다. 페이지뷰가 위의 신호 중 특정 양을 포함하면 likely crawler(예상 크롤러)로 분류됩니다.

:gear: 커뮤니티에서 개선된 크롤러 감지 활성화하기

현재로서는 이것이 실험적 변경으로 간주됩니다. 우리는 여전히 감지 휴리스틱을 조정하고 있으며 피드백을 환영합니다.

활성화하려면 관리자 영역의 Upcoming changes 페이지로 이동하여 Improved crawler detection(개선된 크롤러 감지) 항목을 찾으세요. Enabled for…(활성화 대상…) 필드를 업데이트하여 사이트를 옵트인합니다.

활성화되면 관리자 대시보드의 Site Traffic(사이트 트래픽) 섹션에서 예상 크롤러가 별도 범주로 표시됩니다.

:warning: 중요한 참고 사항:

  • 이것은 완벽한 과학이 아니며, 우리는 시간이 지남에 따라 휴리스틱을 계속 정교하게 다듬어 나갈 것입니다. 그러나 이러한 계산이 업데이트될 때 과거 데이터에 대한 백필(backfill)은 수행하지 않습니다.
  • 페이지뷰를 예상 크롤러로 분류하는 것은 요청을 거부하거나 속도 제한(rate-limit)을 걸지 않습니다.
  • 예상 크롤러 페이지뷰는 리퍼러, 국가 및 기타 트래픽 분류에서 제외됩니다 — 현재 알려진 크롤러가 처리되는 방식과 동일합니다.

:mega: 여러분의 생각은?

피드백을 듣고 싶습니다 — 특히 비정상적인 트래픽 패턴이나 설명할 수 없는 급증을 발견한 커뮤니티의 의견을 환영합니다. 여러분의 사이트에서 수치가 정확해 보이나요? 실제 사용자로 보이는 방문이 플래그가 지정되고 있나요? 이 주제에서 여러분이 보고 있는 내용을 공유해 주세요.

20개의 좋아요

좋네요. 해당 신호에 대해 로그인한 사용자도 확인하나요?

1개의 좋아요

likely crawlers는 월간 페이지뷰 한도에 여전히 포함되나요? :slightly_smiling_face:

1개의 좋아요

모델을 사용하면서 무언가를 붙여넣을 때 URL을 수정하는 것을 잊어버렸는데, 공사 중인 포럼에서 크롤러 활동량이 35,000% 급증하는 일이 발생했습니다:

아직 제가 작업 중인 내용과 관련된 실제 참조를 정리하기 위해 작은 로컬 모델을 설치하는 작업이 남아 있습니다.

이 옵션을 두 번째 필터로 사용할 수 있어서 정말 좋습니다. 만들어 주셔서 감사합니다.

좋은 질문입니다. 아직 결정하지 못한 부분이기도 합니다. 크롤러 탐지 모델을 세밀하게 조정할 필요가 있을 것으로 예상되며, 이는 선택 기능이므로 페이지뷰 한도에 어떤 영향을 미칠지 아직 알 수 없습니다.

내부적으로 해당 사항을 논의한 후 알려드리겠습니다!

3개의 좋아요

노고에 감사드립니다. 탐지 알고리즘에 만족할 정도로 개선되면, 해당 대상에 대해 조치를 취할 수 있는 기능이 로드맵에 포함될 가능성이 있나요?

2개의 좋아요

식별한 사용자 에이전트 목록, 또는 봇/크롤러로 판단되는 목록을 제공받을 수 있으면 좋겠습니다.

이렇게 하면 해당 항목들을 차단 또는 속도 제한 그룹에 추가하는 데 도움이 됩니다.

3개의 좋아요

네, 로그인한 사용자를 통한 자동화도 탐지하려고 합니다. 메타에서 신뢰 수준 0인 몇몇 "사용자"가 사이트를 스캔하고 있는 것을 발견했습니다.

1개의 좋아요

문제는 "추정되는 크롤러"가 실제로는 합법적인 사용자 에이전트를 사용하는 경우가 많다는 점입니다. 때로는 브라우저 버전이 꽤 오래된 것처럼 보일 수 있지만, 이를 봇으로 간주할 만큼 강한 신호라고 보기는 어렵습니다. 그래서 우리는 많은 지표를 수집하고 이를 조합하여 가능성(likelihood)을 측정하려고 합니다.

크롤러가 Bingbot이나 Googlebot과 같은 사용자 에이전트로 정직하게 자신을 소개하는 경우, 해당 트래픽은 바로 “크롤러” 카테고리에 분류됩니다.

1개의 좋아요

맞습니다. 팀 디스커스가 백엔드에서 가져올 수 있는 통계에 따르면, 주로 더 잘 알려지지 않은 사용자 에이전트가 많았으며, 단기적으로 액세스 패턴이 증가하는 경우가 많아서 사용자에 영향을 주지 않고 목록에서 몇 가지를 제거할 수 있었습니다.

이것은 정확한 과학은 아닙니다. 이를 특정 지역(geo)에 매핑할 수 있다면, 이를 관리하는 데 더 나은 해상도를 제공하게 될 것입니다.

2개의 좋아요