식료품 가격은 지역마다 다릅니다. 달걀 한 판이 교외 매장에서는 한 가격, 도심 매장에서는 다른 가격, 같은 진열대 상품에 자체 마크업을 붙이는 배달 앱에서는 또 다른 가격일 수 있습니다. 현지 경쟁사에 맞춰 가격을 정하거나, 브랜드의 프로모션을 확인하거나, 지역별 식품 물가를 추적한다면 전국 평균 하나가 아니라 관심 있는 도시마다의 가격이 필요합니다. 이는 가격 인텔리전스의 핵심 작업이며, 식료품은 대부분의 소매 분야보다 더 까다롭습니다.
이 가이드에서는 식료품 가격이 어디서 달라지는지, 배달 앱이 어떤 매장을 보여줄지 어떻게 정하는지, 그리고 각 도시를 현지 쇼핑객과 같은 방식으로 읽는 수집 환경을 구성하는 방법을 설명합니다.
식료품 가격이 달라지는 지점
식료품 업체가 가격표를 하나만 운영하는 경우는 드뭅니다. 보통은 다음과 같은 층이 있습니다.
- 가격 구역. 체인은 현지 경쟁과 비용에 따라 매장을 구역으로 묶습니다. 몇 킬로미터 떨어진 같은 체인의 두 매장이 서로 다른 구역에 속할 수 있습니다.
- 매장 단위 프로모션. 주간 전단과 멤버십 혜택은 지역마다 다른 경우가 많고, 일부 행사는 선택된 매장에서만 유효합니다.
- 배달 앱 마크업. 외부 배달 앱은 매장 진열 가격보다 높은 가격을 보여줄 수 있고, 지역과 시간대에 따라 달라지는 서비스 수수료와 배달비가 붙습니다.
- 재고 여부. 한 매장에는 있는 상품이 다른 매장에는 없을 수 있으며, 이는 장바구니의 실제 비용을 바꿉니다.
- 용량과 자체 브랜드. 같은 상품 라인이 지역마다 다른 용량으로 나올 수 있어, 단위 가격으로 비교하지 않으면 가격 변화가 가려집니다.
전국 단위로 한 번 수집하면 이 모든 것이 섞여 오해를 부르는 숫자 하나가 됩니다. 기록하는 모든 가격에 매장, 도시, 채널을 함께 붙여야 합니다.
배달 앱과 마트 사이트가 매장을 고르는 방식
대부분의 식료품 사이트는 사용자의 위치를 알기 전까지 전체 상품 목록을 보여주지 않습니다. 대략 다음 순서로 결정합니다.
- 저장된 매장이나 주소. 쿠키나 계정에 저장된 정보입니다.
- 매장 선택이나 배달 가능 확인에 입력한 주소 또는 우편번호.
- IP 위치. 사용자가 아무것도 고르기 전의 첫 추정입니다.
여기서 실무적인 결론이 나옵니다. IP는 올바른 도시로 들어가게 해주고, 첫 추정이 원하는 매장 근처에 떨어지게 합니다. 우편번호 단위의 정확한 매장은 사이트에 입력하는 주소로 정해집니다. 따라서 확실한 구성은 두 가지를 모두 합니다. 대상 도시의 레지덴셜 IP를 쓰고, 같은 세션에서 매장이나 배송 주소를 입력해 둘이 서로 어긋나지 않게 하는 것입니다. 도시 단위 프록시 타기팅이 중요한 경우에서 IP와 선택한 위치가 어긋날 때 사이트가 보여주는 내용이 왜 바뀔 수 있는지 다룹니다.
장바구니 구성하기
수집을 시작하기 전에 무엇을 비교할지 정하세요.
- 고정 장바구니. 생필품, 자사 인기 상품, 경쟁사가 가장 많이 프로모션하는 상품으로 50~300개를 구성합니다.
- 상품별 매칭 키. 사이트가 바코드(GTIN)를 노출하면 그것을 쓰고, 그렇지 않으면 브랜드, 상품명, 용량으로 매칭한 뒤 한 번 직접 확인합니다.
- 단위 가격. 진열 가격 옆에 kg당, 리터당, 개당 가격을 함께 기록해 용량 변경이 가격 변화처럼 보이지 않게 합니다.
- 도시별 매장 목록. 어떤 매장과 어떤 배달 지역이 그 도시를 대표하는지 정합니다.
장바구니는 바꾸지 말고 유지하세요. 매주 바꾸면 추세를 읽을 수 없습니다.
도시별로 수집하기
도시마다 그 도시를 타기팅한 레지덴셜 프록시로 세션을 열고, 사이트에서 매장을 설정한 다음 장바구니를 읽습니다. 스티키 세션 ID로 세션 내내 같은 IP를 유지해, 사이트가 쇼핑객이 도중에 다른 위치로 옮겨 다니는 것으로 보지 않게 하세요.
customer-USERNAME-country-us-city-chicago-sid-chi-store-118-ttl-900:PASSWORD세션 ID(sid)는 ttl에 지정한 초 동안 같은 출구 IP를 유지합니다. 매장마다 ID를 하나씩 써서 각 매장 방문이 한 명의 쇼핑객처럼 보이게 하세요. 큰 시장에서는 나라 전체를 한 곳에서 읽지 말고 주요 도시로 작업을 나누세요. 예를 들어 미국 페이지라면 시카고, 댈러스, 애틀랜타로 나눕니다.
Python으로 만든 최소한의 반복 코드는 다음과 같습니다.
import requests
GATEWAY = "p.shifter.io:443"
USER, PASS = "USERNAME", "PASSWORD"
def session_for(city, store_id):
s = requests.Session()
proxy = f"http://customer-{USER}-country-us-city-{city}-sid-{city}-{store_id}-ttl-900:{PASS}@{GATEWAY}"
s.proxies = {"http": proxy, "https": proxy}
return s
def read_basket(city, store_id, products):
s = session_for(city, store_id)
# 1. Set the store the way the site expects (store picker or address check).
s.post("https://grocer.example/api/store/select", json={"storeId": store_id}, timeout=30)
rows = []
for p in products:
r = s.get(f"https://grocer.example/api/product/{p['sku']}", timeout=30)
if r.status_code != 200:
rows.append({**p, "city": city, "store": store_id, "error": r.status_code})
continue
d = r.json()
rows.append({**p, "city": city, "store": store_id,
"price": d.get("price"), "unit_price": d.get("unitPrice"),
"promo": d.get("promotion"), "in_stock": d.get("available")})
return rows여기 나온 엔드포인트는 예시입니다. 많은 식료품 사이트는 매장이 설정된 뒤 JSON 엔드포인트에서 가격을 불러옵니다. 이 엔드포인트를 읽는 편이 페이지를 파싱하는 것보다 가볍고 안정적입니다.
배달 앱 읽기
배달 앱에서는 두 가지를 따로 기록해야 합니다. 앱 안의 상품 가격과 수수료입니다. 다음을 수집하세요.
- 앱 안의 상품 가격. 식료품 업체 자체 사이트의 진열 가격 옆에 기록해 마크업을 측정합니다.
- 서비스 수수료와 배달비. 수수료는 주문 금액에 따라 달라지는 경우가 많으므로 고정된 장바구니 금액 기준으로 기록합니다.
- 수집 시각. 수수료와 재고는 하루 중에도 바뀌기 때문입니다.
같은 조건끼리 비교하세요. 같은 매장, 같은 장바구니, 같은 시간대입니다.
데이터를 깨끗하게 유지하기
- 모든 가격을 도시, 매장, 채널, 시각, 단위 가격과 함께 저장하세요. 매장 정보가 없으면 변화를 설명할 수 없습니다.
- 프로모션은 평균에 섞지 말고 표시하세요. 2주짜리 행사는 가격 인하가 아닙니다.
- 누락된 상품을 살피세요. 가격이 비어 있으면 품절인 경우가 많고, 그 자체가 신호입니다.
- 개인화된 가격을 확인하세요. 로그인한 멤버십 가격은 비회원 가격과 다를 수 있습니다. 멤버십 가격을 연구하는 것이 아니라면 비회원으로 수집하세요. 지역 맞춤 가격과 동적 가격 탐지 가이드에서 둘을 구분하는 방법을 설명합니다.
- 공개된 가격만 수집하세요. 적절한 속도로 요청하고 각 사이트의 이용 약관을 지키세요.
결론
식료품 가격은 도시, 매장, 채널이 함께 붙어 있을 때만 의미가 있습니다. 장바구니를 고정하고, 각 도시를 대표할 매장을 정하고, 그 도시에 있는 레지덴셜 IP로 접속해 같은 세션 안에서 사이트에 매장을 설정하고, 단위 가격, 프로모션, 수수료를 따로 기록하세요. 생필품은 매주, 경쟁이 치열한 상품은 매일 실행하면 흐릿한 전국 숫자 하나 대신 지역 가격 변화를 실시간으로 보게 됩니다.