У новому технічному розборі на каналі Tech With Tim показано, як на практиці виглядає продакшн‑рівень система для масового збору цін з Amazon у різних країнах. Йдеться не про черговий «скрипт на 50 рядків», а про інфраструктуру, яка вміє працювати безперервно, масштабуватися по регіонах, зберігати історичні дані й давати до них доступ через AI‑шар. Ключовий елемент цієї системи — надійний веб‑скрейпінг без браузерної автоматизації, побудований на HTTP‑запитах, мережі резидентних проксі Thor Data та HTML‑парсері Beautiful Soup.
Цей матеріал зосереджений саме на тому, як організовано стійкий, геоспецифічний скрейпінг Amazon: від вибору підходу до роботи з проксі до розбору HTML і витягування атрибутів товарів.
Чому масштабний скрейпінг Amazon — це вже не «просто код»
Поки скрейпінг обмежується одноразовим скриптом, який знімає дані з однієї сторінки, усе здається простим: написали запит, витягнули HTML, розпарсили — готово. Але щойно з’являється потреба збирати дані постійно, з різних країн і для великої кількості товарів, проблема перестає бути суто програмістською й перетворюється на задачу побудови розподіленої системи.
На Amazon це проявляється особливо гостро. Типовий сценарій розвитку подій виглядає так: перша версія скрипта працює, потім IP‑адресу блокують, різні країни починають повертати різні версії сторінок, сесії «падають», дані стають неповними або суперечливими, і довіра до результатів зникає. У такому стані будь‑який аналіз цін втрачає сенс.
У розглянутій системі завдання сформульовано чітко: потрібно порівнювати ціни одного й того ж товару (за ASIN) на різних локалізованих доменах Amazon — від США й Канади до Франції, Іспанії, Австралії, Японії та ОАЕ. Для цього скрейпер має:
- гарантовано діставатися до потрібної сторінки в конкретній країні;
- виглядати для Amazon як реальний користувач з відповідного регіону;
- витягувати однаковий набір атрибутів товару з різних версій сайту;
- витримувати безперервну роботу й велику кількість запитів.
Саме тут у гру входить резидентна проксі‑мережа Thor Data та класичний HTML‑парсинг через Beautiful Soup, які дозволяють обійтися без Selenium чи Playwright і водночас працювати на продакшн‑масштабах.
Thor Data як основа геоспецифічного скрейпінгу Amazon
Навіщо резидентні проксі, а не «рандомний» дата‑центр
Ключова вимога до такого скрейпера — стабільний доступ до Amazon з різних країн. Якщо просто ганяти запити з одного серверного IP, платформа швидко розпізнає підозрілу активність і почне повертати капчі, редіректи або взагалі блокувати доступ. Особливо це стосується сторінок товарів, які часто захищені агресивніше, ніж публічні каталоги.
У цій системі використовується Thor Data як резидентна проксі‑мережа. Її завдання — зробити трафік максимально схожим на реальних користувачів: запити йдуть з IP‑адрес, прив’язаних до звичайних підключень у різних країнах, а не з очевидних дата‑центрів. За словами автора проєкту, без такого рівня інфраструктури реалізувати подібний скрейпер на масштабі було б просто неможливо.
Thor Data, згідно з відео, надає понад 60 мільйонів IP‑адрес у більш ніж 190 країнах. Для задачі порівняння цін це означає, що практично будь‑який локальний домен Amazon — від .com до .fr, .es, .ae чи .co.jp — можна опитувати з «правильної» геолокації, не боячись масових блокувань.
Як конфігуруються проксі Thor Data
Щоб інтегрувати Thor Data в Python‑скрейпер, кожен запит до Amazon проходить через проксі‑сервер, налаштований з конкретними параметрами. Конфігурація включає:
- ім’я користувача та пароль — для автентифікації в мережі Thor Data;
- хост проксі та порт — адресу, через яку йде трафік;
- код країни — щоб зафіксувати геолокацію запиту (наприклад, US, CA, FR, AE);
- опційний session ID — для керування сесіями й повторного використання одного й того ж IP.
Комбінація цих параметрів дозволяє не лише уникати блокувань, а й контролювати поведінку на рівні сесій. Наприклад, можна зберігати один і той самий session ID для серії запитів до Amazon у межах одного «сеансу» скрейпінгу, щоб сайт бачив послідовність дій як активність одного користувача. Або навпаки — регулярно змінювати session ID, якщо потрібна ротація IP.
У результаті кожен HTTP‑запит до Amazon стає не просто зверненням до URL, а частиною керованого потоку трафіку, де чітко визначено, з якої країни, з якої IP‑адреси і в рамках якої сесії він має виглядати.
HTTP‑запити замість Selenium: чому це важливо на масштабі
Відмова від браузерної автоматизації
Популярний підхід до скрейпінгу складних сайтів — використання Selenium або Playwright, які емулюють повноцінний браузер, виконують JavaScript і відтворюють поведінку користувача. Це зручно для невеликих задач, але погано масштабується: кожен інстанс браузера споживає багато ресурсів, а керування сотнями чи тисячами таких процесів стає окремою інженерною проблемою.
У розглянутій системі обрано інший шлях: замість браузерної автоматизації використовуються «чисті» HTTP‑запити — GET і POST — які йдуть через проксі Thor Data. Це дає кілька важливих переваг:
- значно менше навантаження на інфраструктуру, оскільки не потрібно піднімати браузери;
- простіше горизонтальне масштабування — додати ще один воркер, який шле HTTP‑запити, набагато легше, ніж керувати новим пулом браузерів;
- кращий контроль над мережею: кожен запит можна тонко налаштувати, змінюючи заголовки, тайм‑аути, параметри проксі та сесій.
Завдяки Thor Data, який бере на себе завдання «зробити трафік схожим на реальних користувачів», відсутність повноцінного браузера не стає критичною. Amazon бачить запити як нормальну активність з різних країн, а не як масовий трафік з одного серверного вузла.
Потік скрейпінгу: від HTML до структурованих даних
Логіка роботи скрейпера в такій конфігурації виглядає послідовно. Спочатку система формує HTTP‑запит до конкретного домену Amazon з урахуванням країни, яку потрібно опитати. Запит проходить через проксі Thor Data з відповідним кодом країни та, за потреби, session ID. У відповідь повертається HTML‑сторінка, вже «пофарбована» геолокацією: ціни, валюта, доступність товару — усе так, як це бачить користувач у цій країні.
Далі в гру вступає Beautiful Soup. Отриманий HTML не зберігається як «чорний ящик» — він розбирається, і з нього витягуються структуровані атрибути товару. Серед них:
- назва товару;
- ціна;
- бренд;
- категорії, до яких належить товар.
Цей підхід дозволяє будувати надійну модель даних: незалежно від того, з якого домену Amazon прийшов HTML, на виході завжди формується однакова структура полів. Саме це й потрібно для коректного порівняння цін одного й того ж ASIN у різних країнах.
Beautiful Soup як робоча конячка парсингу Amazon
Чому класичний HTML‑парсер досі актуальний
Попри поширену думку, що сучасні сайти неможливо скрейпити без повноцінного браузера, приклад з Amazon показує, що класичний HTML‑парсер на кшталт Beautiful Soup залишається ефективним інструментом, якщо правильно організувати мережевий рівень.
У цій системі Beautiful Soup використовується як основний інструмент для розбору HTML‑відповідей, отриманих через Thor Data. Після того як сторінка товару завантажена, парсер проходить по DOM‑структурі, знаходить потрібні елементи й витягує ключові атрибути. Це дозволяє:
- стандартизувати дані з різних локалізованих версій Amazon;
- відокремити мережеву логіку (Thor Data, HTTP‑запити) від логіки парсингу;
- швидко адаптуватися до змін верстки, змінюючи лише селектори в Beautiful Soup.
З технічної точки зору це також спрощує тестування: можна зберігати HTML‑зразки й перевіряти, як парсер поводиться на них, не торкаючись реальної мережі.
Витягування атрибутів товару для порівняння цін
Для задачі порівняння цін критично важливо не просто «витягнути ціну», а зібрати повний контекст товару. Beautiful Soup у цьому проєкті використовується для отримання кількох ключових полів.
По‑перше, це назва товару. Вона дозволяє переконатися, що під одним і тим самим ASIN у різних країнах дійсно йдеться про той самий продукт, а не про локальну варіацію чи бандл.
По‑друге, ціна. Саме вона є основою для побудови аналітики: система показує, як вартість одного й того ж товару відрізняється між, скажімо, Францією, Іспанією, Австралією та Японією, навіть якщо валюта однакова (наприклад, євро), але цифри різні.
По‑третє, бренд. Це важливо для бізнес‑користувачів, які аналізують конкурентне середовище: хто продає той самий товар, як позиціонуються бренди в різних країнах, чи є локальні аналоги.
По‑четверте, категорії. Вони дають змогу будувати зрізи по нішах: наприклад, порівнювати цінову політику в категоріях «побутова хімія», «електроніка» чи «косметика» в різних регіонах.
Усе це разом перетворює «сирий» HTML у придатний для аналітики набір структурованих даних, який можна зберігати, порівнювати й використовувати в подальших AI‑запитах.
Геоспецифічний скрейпінг Amazon: як це виглядає для користувача
Один ASIN — багато країн
З погляду кінцевого користувача система працює як «агент порівняння цін» для Amazon. У демо‑додатку можна ввести ASIN — унікальний ідентифікатор товару на Amazon — і вибрати цільові країни, з яких потрібно зібрати дані. Серед доступних варіантів — США, Канада, Велика Британія, Франція, Іспанія, Австралія, Японія, ОАЕ та інші локалізовані домени.
Далі запускається процес скрейпінгу: для кожної обраної країни система формує HTTP‑запит до відповідного домену Amazon, пропускає його через Thor Data з потрібним кодом країни, отримує HTML‑сторінку й розбирає її через Beautiful Soup. Якщо товар з таким ASIN існує на кількох сайтах, користувач отримує таблицю з цінами, назвами, брендами й іншими атрибутами для кожного регіону.
У демонстрації згадуються приклади з побутовими товарами на кшталт Scrub Daddy чи Kleenex, а також з електронікою, наприклад, iPad. Для таких позицій добре видно, як ціни відрізняються між країнами, навіть якщо товар формально той самий.
Масштабування без зміни підходу
Важливо, що цей механізм не обмежується кількома тестовими товарами. Архітектура розрахована на те, щоб працювати з практично необмеженою кількістю ASIN‑ів, запускати скрейпінг асинхронно й паралельно по різних регіонах. Завдяки тому, що основою є HTTP‑запити через Thor Data, а не браузерна автоматизація, додавання нових воркерів або розширення списку країн не вимагає кардинальної зміни підходу.
Система також враховує реальні умови: не всі товари існують на всіх локалізованих сайтах Amazon. Якщо для певного ASIN сторінка в конкретній країні відсутня або повертається помилка, це коректно обробляється — скрейпер фіксує, що дані недоступні, і рухається далі, не «зависаючи» на проблемному випадку.
Чому без Thor Data цей проєкт не працював би на продакшн‑масштабі
У розглянутій архітектурі Thor Data — не просто «зручний додаток», а фундаментальний компонент. Сам автор прямо підкреслює, що без резидентної проксі‑мережі такого рівня проєкт не був би життєздатним на масштабі.
Причин кілька.
По‑перше, Amazon активно бореться з масовим скрейпінгом. Якщо запускати тисячі запитів з обмеженої кількості IP‑адрес, особливо з дата‑центрів, блокування — лише питання часу. Thor Data, пропонуючи десятки мільйонів IP у сотнях країн, розподіляє навантаження й робить трафік схожим на звичайну користувацьку активність.
По‑друге, для задачі порівняння цін критична саме геоспецифіка. Потрібно не просто «дістатися до Amazon», а побачити сторінку так, як її бачить користувач у конкретній країні. Контроль геолокації через код країни в конфігурації проксі — обов’язкова умова для коректності даних.
По‑третє, керування сесіями. Можливість задавати session ID дозволяє будувати більш стійкі сценарії: повторно використовувати IP для серії запитів, уникати зайвих редіректів і капч, а також гнучко реагувати на збої, змінюючи сесію в разі проблем.
У сукупності це робить Thor Data не просто «постачальником IP», а інфраструктурним шаром, без якого навіть найкращий парсер на Beautiful Soup і найакуратніший HTTP‑клієнт не змогли б стабільно працювати з Amazon у десятках країн.
Висновок: класичний стек, продакшн‑масштаб
Розглянута система показує, що для побудови продакшн‑рівня скрейпера Amazon не обов’язково йти шляхом важкої браузерної автоматизації. Комбінація «чистих» HTTP‑запитів, резидентної проксі‑мережі Thor Data та перевіреного HTML‑парсера Beautiful Soup дозволяє:
- надійно збирати геоспецифічні дані з різних локалізованих доменів Amazon;
- уникати масових блокувань завдяки великому пулу резидентних IP і контролю геолокації;
- стандартизувати атрибути товарів (назва, ціна, бренд, категорії) для подальшого порівняння;
- масштабуватися до практично необмеженої кількості товарів і регіонів.
На цьому фундаменті вже можна будувати складніші речі — від історичної аналітики цін до AI‑агентів, які відповідають на запитання природною мовою. Але саме мережевий шар на Thor Data й парсинг через Beautiful Soup роблять можливим головне: стабільний, відтворюваний і геоспецифічний доступ до даних Amazon у продакшн‑умовах.
Джерело
How to Design a Production-Grade System in Python — Tech With Tim