이미 마켓플레이스 데이터를 수집하고 있는 팀들은 Walmart를 Amazon과 같은 방식으로 접근하려는 경향이 있는데, 그 결과 수치가 놓치기 쉬운 방식으로 틀어진다. 에러는 나지 않는다. 가격도 그럴듯해 보인다. 다만 댈러스나 탬파의 실제 쇼핑객이 보는 것과 일치하지 않으며, 이 불일치는 무작위가 아니라 체계적이다.
이유는 구조적인 것이다. Walmart는 매장 네트워크 위에 웹사이트가 얹혀 있는 형태이지, 전국 단일 카탈로그가 아니다. 가격과 재고는 특정 매장을 기준으로 결정되며, 그 매장은 당신이 통제하지 못할 수도 있는 신호에 따라 자동으로 선택된다.
매장이 진실의 단위다
전체 상품 구성의 상당 부분에서 다음 세 가지가 매장별로 달라진다:
가격. 롤백, 클리어런스, 지역별 가격 정책으로 인해 40마일 떨어진 두 매장에서 같은 상품의 가격이 다를 수 있다.
재고. 매장 내 재고는 정의상 위치별로 존재하며, 세션이 연결된 매장과 배송 센터에 따라 제공되는 배송 및 픽업 옵션도 달라진다.
상품 구성. 일부 상품은 특정 매장에서 아예 취급되지 않으며, 이는 품절이 아니라 상품 자체가 없는 것으로 나타난다.
수집 계층이 매장을 고정하지 않으면, 사이트는 요청의 겉보기 위치를 기준으로 매장을 대신 선택하며, 내일은 다른 매장을 선택할 수도 있다. 그 결과로 나오는 시계열은 가격 변동이 일부는 실제이고 일부는 매장이 당신도 모르게 바뀐 것이 뒤섞인 형태가 된다. 이는 데이터 누락보다 더 나쁜데, 마치 추세처럼 보이기 때문이다.
같은 함정은 지역 배송을 운영하는 모든 리테일러에 적용된다. 이 논리의 일반적인 버전은 제품 재고 및 가용성 모니터링에 나와 있다.
두 가지 신호가 어느 매장을 받을지 결정한다
요청이 오는 것처럼 보이는 위치, 즉 IP 주소와 그 지리적 위치가 있고, 세션에서 명시적으로 선택하는 매장이나 ZIP 코드가 있다. 이 둘은 서로 다른 메커니즘이며 서로 일치해야 한다.
버지니아의 데이터센터 IP가 피닉스 매장을 요청하는 세션과 함께 있는 것은 일관성 없는 조합이다. 때로는 작동하기도 하지만, 때로는 조용히 다른 것으로 해석되기도 하며, 이는 리테일 안티봇 시스템이 크게 가중치를 두는 바로 그런 신호다. 문의하는 대도시권 내의 레지덴셜 IP를 사용하면 조합이 일관되게 맞아떨어지는데, 핵심은 위치를 주장하는 것이 아니라 쇼핑객을 재현하는 것이라는 점이다.
지리적 위치를 고정한 다음, 세션을 고정하라
Shifter 게이트웨이에서는 타겟팅이 별도의 API 호출이 아니라 사용자 이름에 들어간다. p.shifter.io:443을 지정하고 위치와 세션을 자격 증명에 인코딩한다:
customer-USERNAME-country-us-city-dallas-sid-store2354-ttl-600:PASSWORD여기서 세 부분이 중요하다. country-us와 city-dallas는 올바른 대도시권에서 트래픽이 나가도록 한다. sid-store2354는 고정 세션에 이름을 붙이므로, 이 식별자가 태그된 모든 요청은 동일한 IP에서 나간다. ttl-600은 그 IP를 10분간 유지하는데, 이는 매장을 선택하고, 카테고리를 탐색하고, 위치가 크롤링 도중 바뀌지 않은 채로 일련의 상품 페이지를 읽기에 충분한 시간이다.
ttl은 sid와 함께 사용될 때만 의미가 있다는 점에 유의하라. 세션 식별자가 없으면 유지할 대상이 없으므로 기본 로테이션이 적용된다.
기억해야 할 개념 모델은 이렇다: 매장당 하나의 고정 세션을 사용하고, 그 매장에 대해 확인하는 모든 항목에 재사용하는 것이지, 요청마다 하나의 세션을 쓰는 것이 아니다. 모든 상품 페이지마다 로테이션하는 것이 여기서 가장 흔한 설정 실수인데, 이는 매장 결정 과정을 계속 재발동시켜서 애초에 없애려던 바로 그 드리프트를 만들어낸다. 트레이드오프는 고정 세션 대 로테이팅 세션에 정리되어 있다.
도시는 공백을 언더스코어로 바꾼 소문자 이름을 사용하고, 국가는 ISO alpha-2 코드를 사용한다. 필터가 너무 좁아서 채울 수 없는 경우, 게이트웨이는 조용히 다른 곳의 출구를 주는 대신 502를 응답하는데, 매장 정확도가 전부인 상황에서는 이것이 원하는 동작이다.
가격뿐 아니라 매장도 기록하라
대부분의 Walmart 패널은 스키마에서 승패가 갈린다. “상품 X는 화요일에 $14.98였다”라는 행은 사용 가능한 관측치가 아닌데, 가격을 결정하는 요소를 빠뜨렸기 때문이다.
최소한 다음을 캡처하라:
- 상품 식별자
- 세션이 실제로 해석된 매장 식별자
- 가격, 그리고 별도로 취소선 가격이나 이전 가격
- 재고 상태(매장 내, 픽업, 배송으로 구분)
- 판매자(서드파티 리스팅은 퍼스트파티 리스팅과 다르게 동작하므로)
- 요청이 나간 국가와 도시
- UTC 기준 수집 타임스탬프
매장 식별자는 요청한 값에서 가정하는 것이 아니라 응답에서 다시 읽어와야 한다. 이 필드 하나가 설명할 수 없는 가격 급등을 눈에 보이는 매장 변경으로 바꿔주며, 방어할 수 있는 패널과 사과해야 하는 차트 사이의 차이를 만든다.
확인이 실패하는 네 가지 방식을 구분하라
리테일 수집은 분리하지 않으면 모두 “데이터 없음”처럼 보이는 실패 모드를 만들어낸다:
차단됨. 챌린지나 인터스티셜을 받았다. 관측치가 누락된 것이며, 재시도해야지 재고 없음으로 기록해서는 안 된다.
품절. 이 매장에서 상품이 이용 불가능하다고 표시하는 유효한 페이지다. 이는 실제 데이터이며 시계열에 포함되어야 한다.
취급하지 않음. 이 매장의 상품 구성에 해당 상품이 존재하지 않는다. 이 역시 실제 데이터이며 품절과는 다르다.
잘못된 매장. 페이지는 렌더링되었지만 요청하지 않은 매장에 대한 것이다. 이것이 위험한 경우인데, 깔끔해 보이는 행이지만 값이 틀렸기 때문이다.
이 중 재시도를 정당화하는 것은 첫 번째뿐이다. 중간의 둘을 섞으면 실제 상품 구성 차이가 평평해지고, 네 번째를 유효한 것으로 취급하면 잘못된 수치가 대시보드에 도달하게 된다. 전송 측면에서는 407이 자격 증명이나 형식이 잘못된 타겟팅 플래그를 의미하고, 502는 필터에 맞는 출구가 없음을 의미하며, 509는 대역폭 할당량이 소진되었음을 의미한다.
주기, 그리고 왜 지루해야 하는가
가격 패널은 높은 빈도를 향한 강한 유혹이 있다. 두 가지 이유로 이를 자제하라.
첫째, 리테일 사이트에 대한 요청량은 수집 패턴이 발각될 가능성이 가장 높은 신호이며, 해결책은 더 많은 IP가 아니라 수요처럼 보이는 스케줄이다. 확인을 하루에 걸쳐 분산시키고, 매장당 동시성을 적절히 유지하며, 오류가 나면 밀어붙이는 대신 백오프하라. 이 메커니즘은 속도 제한 및 요청 스로틀링에서 다룬다.
둘째는 비용이다. 레지덴셜 트래픽은 대역폭 기준으로 과금되므로, 조절해야 할 것은 시간당 요청 수가 아니라 관측당 바이트 수다. 이미지를 건너뛰고, 필요한 필드를 담은 가장 가벼운 응답을 선호하며, 세 개 항목만 필요할 때 전체 카테고리 페이지를 다시 가져오지 마라. 더 자세한 처리 방법은 프록시 대역폭 비용 절감에 나와 있다.
대부분의 리테일 패널의 경우, 매장당 상품당 하루 한 번의 확인으로 중요한 변동을 감지하기에 충분하며, 더 빠른 주기는 고가치 상품의 소규모 감시 목록을 위해 남겨둔다.
Walmart 패널 규모 산정
대역폭은 단순한 곱셈을 따른다: 추적하는 상품 수 곱하기 추적하는 매장 수 곱하기 하루 확인 횟수 곱하기 확인당 바이트 수. 매장 배수는 사람들이 가장 자주 잊는 요소이면서 가장 빠르게 커지는 요소인데, 5천 개 상품 패널에 20개 대도시권을 추가하면 회당 관측치가 10만 개가 되기 때문이다.
실제로 의사 결정을 내리는 시장을 반영하는 좁은 매장 집합으로 시작하고, 일주일간 확인당 실제 바이트 수를 측정한 다음 확장하라. 구체적인 방법은 월간 레지덴셜 프록시 대역폭 추정에 있으며, 현재 요금은 레지덴셜 프록시 가격 페이지에서 확인할 수 있다.
FAQ
세션에서 이미 ZIP을 선택하고 있다면 레지덴셜 IP가 필요한가?
일관성을 위해서는 그렇다. 다른 지역의 데이터센터 대역에서 접속하면서 위치를 선택하는 것은 일관성 없는 조합이며, 그렇게 취급된다. 명시적 선택은 사이트에 원하는 것을 알려주지만, IP는 사이트가 믿는 것이다.
하나의 세션은 몇 개의 매장을 다뤄야 하는가?
하나다. 하나의 매장에 대한 상품들에 걸쳐 고정 세션을 재사용한 다음, 다음 매장을 위해 새 세션을 받아라. 하나의 세션 안에서 매장을 섞는 것이 귀속 오류를 만드는 원인이다.
Walmart 데이터 수집은 Amazon과 다른가?
메커니즘은 겹치지만, 매장 차원은 Walmart에 특화된 것이며 스키마를 바꾼다. 기존 마켓플레이스 파이프라인을 확장하는 경우, 프록시를 이용한 Amazon 상품 데이터 스크래핑에서 이어지는 부분을 다룬다.
서드파티 마켓플레이스 리스팅은 어떤가?
판매자 필드를 캡처하고 퍼스트파티와 서드파티 행을 별도의 시계열로 취급하라. 이 둘을 혼합하면 가격 정책과는 무관한 이유로 급등하는 가격 이력이 만들어진다.
결론
Walmart 가격 및 재고 데이터는 매장에 연결되어 있을 때만 의미가 있으며, 매장에 연결한다는 것은 요청의 겉보기 위치와 그것을 해석한 세션의 지속성을 모두 통제한다는 뜻이다. 지오 타겟팅된 레지덴셜 출구와 고정 세션이 그 통제력을 주며, 해석된 매장을 기록하는 것이 그것을 증명할 능력을 준다.
이 두 가지를 제대로 하면 나머지 파이프라인은 평범한 리테일 수집이 된다. 잘못하면 자신 있게, 일관되게 틀린 대시보드를 갖게 될 것이다. 더 폭넓은 리테일 맥락은 전자상거래 활동을 위한 프록시와 가격 인텔리전스 사용 사례에 나와 있다.