로컬 비즈니스 데이터, 즉 Google Maps와 각종 디렉토리에 등록된 모든 비즈니스의 이름, 주소, 전화번호, 영업시간, 카테고리, 평점, 순위는 놀라울 만큼 많은 작업의 기반이 된다. 로컬 SEO 순위 추적, B2B 리드 목록 작성, 시장 조사, 등록 정보 검증, 평판 모니터링이 그렇다. 하지만 이 데이터를 수집하려는 대부분의 시도를 조용히 무너뜨리는 함정이 하나 있다. 로컬 데이터는 위치별로 다르게 제공된다는 점이다. Google Maps가 시카고에 있는 검색자에게 보여주는 결과는 베를린에 있는 검색자에게 보여주는 결과와 다르며, 한 도시에서 로컬팩 순위를 차지한 비즈니스가 다른 도시에서는 다른 순위를 갖는다.
이 한 가지 사실만으로도 로컬 데이터 수집은 접근성 문제가 된다. 데이터센터 IP나 단일 사무실 위치에서 Maps나 디렉토리를 스크랩하려고 하면 차단당하거나 CAPTCHA를 만나거나, 더 나쁘게는 다른 누군가의 로컬 결과를 진짜인 것처럼 제공받게 된다. 이 지점에서 레지덴셜 프록시가 등장한다. 레지덴셜 프록시를 사용하면 실제로 그 도시에 서 있는 사용자가 보는 것과 정확히 같은 방식으로 로컬 비즈니스 데이터를 수집할 수 있으며, 이것이야말로 데이터가 정확하게 나오는 유일한 방법이다. 어떻게, 그리고 왜 중요한지 살펴보자.
”로컬 비즈니스 데이터”가 실제로 포괄하는 범위
핵심적으로 이것은 사람들이 로컬 비즈니스를 찾는 여러 표면에서 비즈니스 등록 정보와 그 신호들을 체계적으로 수집하는 작업이다.
- 지도 및 등록 플랫폼 — Google Maps와 Business Profiles, 그리고 더 넓은 디렉토리 생태계로, 이름/주소/전화번호(NAP), 영업시간, 카테고리의 주요 출처다.
- 로컬 검색 결과 — “근처” 및 도시명이 포함된 쿼리에 나타나는 로컬팩과 지도 결과로, 여기서 로컬 순위가 결정된다.
- 평점 및 리뷰 — 평판과 순위를 좌우하는 별점, 리뷰 수, 리뷰 텍스트.
- 속성 및 풍부한 데이터 — 사진, 인기 시간대, 서비스 옵션, 카테고리 태그.
팀들은 이를 로컬 SEO와 순위 추적(도시별로 비즈니스가 로컬팩에서 어디에 위치하는가?), 리드 생성(카테고리와 지역별 비즈니스 목록 작성), 경쟁 및 시장 조사(각 시장에서 경쟁이 얼마나 치열한가?), NAP 검증 및 데이터 보강, 다지점 평판 모니터링에 활용한다. 이 모든 것은 실제 로컬 검색자가 실제로 보는 것을 포착하는 것에 달려 있다. 그리고 그들이 보는 것은 전적으로 그들이 어디서 검색하는지에 달려 있다.
왜 이것이 프록시 문제인가
로컬 데이터의 세 가지 특성이 그 수집을 프록시 계층에 정면으로 걸리는 문제로 만든다.
로컬 결과는 도시 단위까지 지역별로 제공된다. 이것이 가장 큰 문제다. 지도 순위, 로컬팩, “근처” 결과는 검색자의 실제 위치를 기반으로 계산된다. 자기 동네에서 1위인 레스토랑이 몇 개 도시만 떨어져도 전혀 나타나지 않을 수 있다. 모든 수집이 한 위치에서 이뤄진다면, 그 한 도시의 로컬 결과만 측정하고서 이를 보편적인 것으로 부르게 되는데, 이는 다른 모든 시장에 대해서는 단순히 잘못된 데이터다. 특정 도시에서 비즈니스의 실제 로컬 순위를 확인하려면 그 도시에서 쿼리해야 하며, 이는 정확히 도시 단위 타겟팅이 존재하는 이유다. 디렉토리들은 여기에 자체적인 지역 개인화까지 더한다.
이런 소스들은 강력하게 방어되고 있다. Maps와 주요 디렉토리들은 공격적인 봇 차단 시스템을 운영한다. 데이터센터 IP는 즉시 감지되어 CAPTCHA, 차단, 또는 축소된 결과를 받게 되므로, 실제 등록 정보가 아니라 봇용 버전을 기록하게 된다. (메커니즘은 스크레이퍼가 차단되는 이유에서 다룬다.) 레지덴셜 IP는 실제 사용자의 신뢰도를 가지므로, 실제 사용자가 받는 완전하고 진짜인 로컬 결과를 볼 수 있다.
커버리지 범위가 넓고 반복적이다. 여러 도시에 걸쳐 많은 비즈니스, 카테고리, 쿼리를 시간에 따라 추적하는 것은 상당한 요청량을 필요로 한다. 소수의 IP만으로는 속도 제한에 걸려 부분적이고 편향된 샘플만 얻게 되며, 소스가 가장 강력하게 방어하는 고가치 쿼리를 정확히 놓치게 된다. 크고 로테이팅되는 IP 풀이 있어야 커버리지가 완전해진다.
이 세 가지 문제에 대한 해결책은 동일하다. 각 대상 도시에 실제로 위치한 진짜 사용자처럼 보이는 IP에서 수집하는 것이다.
레지덴셜 프록시가 들어맞는 지점
레지덴셜 프록시는 요청을 실제 소비자 IP를 통해 라우팅하므로, Maps와 디렉토리는 진짜 로컬 사용자에게 응답하듯 당신에게 응답한다. 로컬 비즈니스 데이터에 특히, 이는 다음을 가능하게 한다.
멀리서 근사한 결과가 아닌 진짜 로컬 결과. 도시 단위까지 지오 타겟팅을 함으로써, 당신은 그 도시에 서 있는 사용자로서 로컬팩과 지도 결과를 쿼리하게 되므로, 당신이 포착하는 순위, 등록 정보, “근처” 결과는 실제 현지인들이 보는 것과 동일하다. 이것이 고객에게 청구할 수 있는 로컬 순위 보고서와 단순한 추측의 차이다.
봇용 버전이 아닌 실제 등록 정보. 레지덴셜 IP는 실제 사용자의 신뢰도를 가지므로, 의심스러운 트래픽에 제공되는 축소되거나 차단된 페이지가 아니라 완전한 비즈니스 프로필, 평점, 영업시간, 속성, 리뷰 수를 얻는다.
모든 시장에 걸친 완전한 커버리지. 크고 로테이팅되는 IP 풀은 요청을 분산시켜 차단당하지 않고 여러 도시에 걸친 많은 비즈니스를 지속적으로 추적할 수 있게 하여, 로컬 데이터셋을 듬성듬성하지 않고 완전하게 유지한다. (데이터 수집을 위한 레지덴셜 프록시와 동일한 수집 품질 원칙이 여기에도 적용되며, 밀접하게 관련된 지역화된 Google 검색 결과와도 짝을 이룬다.)
간단히 말해서, 레지덴셜 프록시는 “우리 사무실이 우연히 본 로컬 결과”를 “우리가 관심 있는 모든 도시에서 실제 고객이 보는 로컬 결과”로 바꿔준다.
작동 방식
Shifter 게이트웨이에서는 프록시 사용자 이름에 도시를 인코딩하여 선택할 수 있다. 엔드포인트 하나로, 관리할 IP 목록도 없다.
# 시카고 검색자로서 로컬 결과 수집curl -x customer-USERNAME-country-us-city-chicago:PASSWORD@p.shifter.io:443 https://maps-or-directory.example
# 같은 비즈니스 카테고리, 다른 시장curl -x customer-USERNAME-country-de-city-munich:PASSWORD@p.shifter.io:443 https://maps-or-directory.example나쁜 데이터를 막아주는 규칙은 이것이다. 쿼리 위치를 프록시 위치와 일치시켜라. 시카고에 대한 결과를 요청한다면 시카고 레지덴셜 IP를 통해 라우팅해야 하며, 다른 도시의 IP에서 한 도시의 결과를 요청해서는 안 된다. 그렇지 않으면 플랫폼 자체의 위치 신호가 당신의 쿼리와 모순되어 순위가 무의미해진다. 여러 단계에 걸친 결과를 페이지 넘길 때는 시퀀스가 한 사용자처럼 보이도록 고정 세션을 유지하라. 다음 도시나 비즈니스로 이동할 때는 풀 전체에서 로테이션하라. 같은 게이트웨이, 요청마다 다른 타겟팅으로, 당신이 구축한 어떤 수집 파이프라인에도 공급할 수 있다. (가끔이 아니라 지속적으로 차단당한다면 이는 지역이 아니라 IP 품질이나 요청 행동을 가리키는 것이니, 스크래핑 시 차단을 피하는 방법을 참고하라.)
책임감 있게 사용하기
로컬 비즈니스 데이터는 대부분 공개적으로 노출된 것이다. 즉 어떤 검색자든 볼 수 있는 등록 정보, 영업시간, 평점이다. 이는 법적으로 견고한 기반을 제공하지만, 책임감 있게 수집해야 한다. 공개 비즈니스 정보를 수집하고, 각 플랫폼의 이용약관과 속도 제한을 준수하며, 쿼리하는 서비스를 저하시키지 말고, 개인 데이터는 피해야 한다. 리뷰어의 신원이나 리뷰에 첨부된 개인 정보는 수집 대상이 아니다. 프록시는 요청이 어느 IP에서 오는지를 바꿀 뿐, 그 요청을 해야 하는지 여부를 바꾸지는 않는다. Shifter에서 허용되는 것에 대한 기준은 우리의 허용 사용 정책에 있다.
FAQ
Google Maps나 로컬 디렉토리를 스크랩하는 데 왜 프록시가 필요한가? 로컬 결과가 물리적 위치에 따라 제공되며 이런 플랫폼들이 강력하게 방어되고 있기 때문이다. 한 위치나 데이터센터 IP에서는 한 도시의 결과(또는 차단/CAPTCHA 버전)만 보게 된다. 레지덴셜 프록시를 사용하면 각 대상 도시의 실제 사용자로서 쿼리할 수 있으므로, 당신이 수집하는 순위와 등록 정보가 실제 로컬 데이터가 된다.
로컬 순위가 정말 도시마다 그렇게 많이 바뀌는가? 그렇다. 로컬팩과 지도 순위는 검색자의 위치를 기반으로 계산되며, 한 비즈니스가 자기 도시에서는 1위이지만 몇 개 도시 떨어지면 나타나지 않을 수 있다. 한 곳에서만 측정하면 그 도시의 답만 얻게 되고 다른 모든 곳을 잘못 나타내게 된다.
이 방법으로 어떤 로컬 데이터를 수집할 수 있는가? 비즈니스 이름, 주소, 전화번호, 영업시간, 카테고리, 평점 및 리뷰 수, 속성, 로컬팩/지도 순위 등, 위치에 따라 달라지는 모든 공개 등록 신호는 도시 단위 레지덴셜 수집의 혜택을 받는다.
로컬 데이터에는 레지덴셜과 데이터센터 프록시 중 무엇이 나은가? 레지덴셜이다. Maps와 디렉토리는 데이터센터 IP를 탐지하고 다르게 취급하므로, 데이터센터를 사용하면 차단되거나 축소된 결과를 받게 된다. 레지덴셜 IP는 진짜 로컬 검색자가 보는 것과 같은 실제, 지리적으로 정확한 등록 정보와 순위를 볼 수 있다.
로컬 비즈니스 데이터를 스크랩하는 것은 합법적인가? 로컬 등록 정보는 공개적으로 노출되어 있으며, 수집은 일반적으로 공개 데이터를 다루는 것이므로 책임감 있게(이용약관과 속도 제한을 준수하고, 리뷰어 신원 같은 개인 데이터를 피하며) 수행할 경우 대체로 문제가 없다. 프록시는 근본적인 활동의 합법성을 바꾸지 않으니, 불확실한 부분에 대해서는 법률 자문을 받는 것이 좋다.
결론
로컬 비즈니스 데이터는 실제 로컬 검색자가 실제로 보는 데이터일 때만 유용하며, Maps와 디렉토리가 물리적 위치에 따라 결과를 제공하고 봇에 강력하게 방어하기 때문에, 한 사무실 IP에서 수집하면 한 도시의 답을 마치 진실인 것처럼 얻게 된다. 이를 제대로 하려면 각 대상 도시에서 실제 사용자로서 쿼리해야 하며, 이것이 바로 레지덴셜 프록시가 제공하는 것이다. 진짜 로컬 순위와 등록 정보, 봇 버전이 아닌 완전한 실제 프로필, 그리고 차단당하지 않고 모든 시장에 걸친 완전한 커버리지다.
당신의 팀이 로컬 SEO, 리드 생성, 또는 다지점 모니터링을 한다면, 도시 단위 타겟팅을 갖춘 양질의 레지덴셜 프록시 네트워크가 로컬 그림을 근사치가 아닌 정확한 것으로 만들어준다. 풀의 품질이 그 커버리지가 얼마나 완전한지를 결정하므로, 평가할 때 IP 평판을 이해하는 것이 도움이 된다. 가격 페이지에는 당신에게 중요한 도시와 카테고리를 대상으로 시험해볼 수 있는 GB당 요금제가 있다.