Одна страница результатов Google Shopping может одновременно прятать рекламные блоки среди обычных карточек, убирать цену у товаров, которых нет в наличии, и дублировать один и тот же продукт у пяти разных продавцов. Последние несколько недель я разбирал девять инструментов, которые обещают превратить этот хаос в чистые, удобные данные — и честный вывод такой: «лучший» вариант полностью зависит от того, кто вы — разработчик, строящий конвейер данных, или маркетолог, которому просто нужны цифры в таблице к пятнице.
Это разделение видно и в исследованиях. На r/learnpython и r/node люди спорят про Puppeteer, Playwright и ротацию прокси. А на r/PPC чаще ищут решение в духе «просто дайте данные, код трогать не хочу». Поэтому вместо того чтобы расставлять эти девять инструментов по алфавиту или вешать ярлык «лучший в целом» на продукт с самым эффектным лендингом, я оценил каждый по шести конкретным критериям и выстроил их по типу рабочего процесса: сначала управляемые SERP API, затем инфраструктура на прокси и скрейперах, потом платформа actor для разработчиков и в конце no-code браузерный инструмент.
Что делает Google Shopping Scraper «лучшим»? Критерии оценки
Слово «лучший» в подборках часто тянет одеяло на себя, поэтому вот что оно означает здесь. Я оценивал все девять инструментов по одним и тем же шести параметрам, а не пересказывал маркетинговые обещания каждого вендора:
- Покрытие данных — возвращает ли заявленная схема стабильно цену, продавца, рейтинг, количество отзывов, доставку и реальное разделение между рекламными и органическими результатами?
- Поддержка локали и гео — можно ли действительно выбрать страну, язык и устройство, или вы зависите от того, как разрешится IP прокси?
- Сложность настройки — это API-ключ и GET-запрос, очередь с callback, workflow из двух шагов с токенами или просто страница, на которую нужно нажать?
- Нагрузка на поддержку — кто отвечает, если Google поменяет HTML или покажет CAPTCHA: вы или вендор?
- Путь экспорта и интеграции — JSON-выгрузка или прямая интеграция с Sheets, Airtable или хранилищем данных?
- Прозрачность цен — публикует ли вендор реальную стоимость за единицу, которую можно посчитать, или нужно «связаться с отделом продаж», чтобы узнать, сколько вообще стоит продукт?
Что я не буду делать в этом обзоре — так это придумывать процент успеха, бенчмарки скорости или точности. Никто из этого списка не проводил независимое сравнение с остальными, а заявления в духе «99,9% успеха» или «сверхбыстро» — это рекламный текст, а не измерения. Вместо этого вы получите то, что действительно подтверждается документацией каждого вендора. И, как оказалось, этого достаточно.
Разработчикам нужен код, маркетологам — полное отсутствие кода
Если вы хоть немного бывали на форумах про scraping, то уже знаете, что такое разделение существует, но его стоит проговорить отдельно — именно оно объясняет порядок в этом списке. Разработчикам, строящим пайплайн данных, нужен API-ключ, предсказуемый JSON, явные параметры локали и схема, которую можно валидировать и нормализовать дальше по цепочке. Именно они спрашивают про ротацию прокси и рендеринг headless-браузера.
Маркетологам и PPC-специалистам нужно что-то ближе к «укажи на страницу — получи таблицу». Им не хочется поддерживать Puppeteer-скрипт каждый раз, когда Google в третий раз за квартал меняет layout Shopping (а это случается — разметка Shopping меняется настолько часто, что даже API-вендоры публикуют changelog’и).
Поэтому список идёт от провайдеров managed SERP API (SerpApi, Serper, SearchAPI, DataForSEO) — структурированный JSON, без возни с прокси, но всё ещё с кодом — через инфраструктуру на прокси и скрейперах (Bright Data, Oxylabs), которая даёт больше контроля ценой более сложной настройки, затем к полностью настраиваемой developer actor-платформе (Apify) и заканчивается Thunderbit — no-code агентным браузерным инструментом для тех, кто действительно не хочет писать или сопровождать код для scraping.
9 лучших Google Shopping Scraper — кратко
| Инструмент | Модель сбора | Сложность настройки | Поддержка локали | Для кого лучше всего | Нагрузка на поддержку |
|---|---|---|---|---|---|
| SerpApi | Managed Shopping API | Низкая (API-ключ) | Сильная (location, gl, hl, device) | Data engineers, SEO-инструменты | На стороне вендора |
| Serper | Универсальный SERP API, Shopping как один из типов результата | Низкая | Средняя (страна/язык задокументированы) | Разработчики, чувствительные к цене | На стороне вендора |
| SearchAPI | Managed Shopping + Product Offers API | Низкая–средняя (для offers нужен второй шаг) | Средняя | Команды сравнения предложений/мерчантов | На стороне вендора |
| DataForSEO | Task-based Merchant API | Средняя (очередь/callback) | Сильная | Массовые и плановые пайплайны | На стороне вендора |
| Bright Data | Dataset + Scraper API + SERP API | Средняя (зависит от поверхности) | Очень сильная | Enterprise-команды по данным | Общая |
| Oxylabs | Двухшаговый search + product-detail API | Средняя (связка токенов) | Очень сильная | Enterprise-команды по данным | Общая |
| Scrapingdog | Отдельный Shopping endpoint | Низкая–средняя | Средняя | Разработчики, чувствительные к бюджету | На стороне вендора |
| Apify | Actor / developer platform | Средняя–высокая | Зависит от actor | Создатели кастомных пайплайнов | На стороне пользователя |
| Thunderbit | Агентное no-code браузерное извлечение | Очень низкая (One Click Extract) | Зависит от целевой страницы | Маркетологи/PPC, не программисты | Низкая, зависит от страницы |
(Перед тем как выбирать, обязательно проверьте актуальные цены, лимиты по кредитам и покрытие локалей в живой документации каждого вендора — всё это быстро меняется, и несколько из этих продуктов уже выпускали breaking changes в 2026 году.)
1. SerpApi — управляемый, богатый по функциям и явно учитывающий cache
SerpApi использует отдельный Google Shopping engine (engine=google_shopping), который принимает ваш запрос и возвращает структурированные shopping_results — позицию, заголовок, product ID, цену и извлечённую числовую цену, старую цену/рассрочку, доставку, состояние товара, рейтинг, отзывы и изображения. Это действительно сильная схема, а отдельно SerpApi документирует и спонсируемые Shopping-результаты через схему Google Ads Shopping, так что рекламные размещения можно найти — правда не как один надёжный флаг sponsored: true/false прямо внутри ответа Shopping.
Сильная сторона SerpApi — в том, насколько открыто он говорит о вещах, которые обычно позже создают проблемы. Геотаргетинг поддерживает либо канонический параметр location на уровне города, либо точный uule, а также отдельные параметры gl (страна), hl (язык) и device (desktop, tablet, mobile). И в документации прямо сказано, что одинаковые запросы по умолчанию могут попадать в кэш до одного часа — кэшированные ответы бесплатны, а no_cache=true заставляет получить свежий результат. Это тот уровень прозрачности, который большинство вендоров либо прячут, либо вообще не упоминают.
Цены (проверено 2026-08-13) публичные и помесячные: Free tier — 250 поисков, Starter — $25 за 1,000, далее Big Data — $275 за 30,000. В квоту идут только успешные запросы — кэшированные и неудачные не списываются. Важно знать: в начале 2026 года Google подал в суд на SerpApi из-за методов доступа к данным; SerpApi оспаривает эту трактовку и утверждает, что получает доступ к публичным, неавторизованным результатам. Это текущий юридический процесс, а не решение суда, поэтому воспринимайте его как фактор риска, а не как автоматический повод отказаться от инструмента.
Лучше всего подходит для: разработчиков, которым нужна максимально богатая документированная Shopping-схема и явный контроль над кэшем и локалью.
2. Serper — быстрый, доступный и с самым понятным обещанием свежести
Serper позиционирует себя как универсальный Google SERP API, где Shopping — лишь один из типов результатов наряду с Search, Images, News, Maps и ещё несколькими. Если вы уже забираете обычные результаты поиска и хотите просто добавить данные Shopping, это менее болезненное дополнение, чем запуск второго специализированного сервиса.
Публичный пример Shopping возвращает title, source, прямую merchant-ссылку, отформатированную цену, доставку, рейтинг, число оценок, число предложений, product ID и позицию — вполне достаточно для базового мониторинга карточек товара. Но в открытой документации нет той глубины по merchant offers и полям промо-ценообразования, которую описывают SearchAPI или Oxylabs. Самое сильное преимущество Serper — обещание свежести: он говорит, что каждый запрос идёт в Google в реальном времени и ничего не кэшируется. Это убирает решение про cache management, с которым сталкиваются пользователи SerpApi, но заставляет платить за каждый повторный запрос, даже если результат уже есть.
Ценообразование построено на предоплаченных кредитных пакетах, а не на подписке — 2,500 бесплатных запросов для старта, затем $50 за 50,000 кредитов, с уменьшением цены до $0.30 за 1,000 на верхнем тарифе; кредиты действуют шесть месяцев. На странице цен есть ещё одна приятно честная деталь: отдельные запросы могут занимать 2–4 секунды «когда требуется повторить запрос к Google», то есть это реальный хвост задержек, который нужно учитывать, а не абстрактный бенчмарк.
Лучше всего подходит для: команд, которые уже используют более широкий SERP API и хотят Shopping как дополнительную возможность, а не отдельный продукт.
3. SearchAPI — сильная детализация на уровне offers, но с нюансом в документации
SearchAPI использует двухшаговой процесс, который действительно полезен, если вам нужны сравнения цен на уровне продавцов. Shopping endpoint возвращает обычные поля карточки плюс product_token — а этот токен открывает доступ к отдельному Product Offers API, который возвращает массив offers с ссылкой на merchant, ценой, стоимостью доставки, общей стоимостью, статусом наличия и способами оплаты по каждому продавцу. Если ваш сценарий — «покажи все цены, по которым этот точный продукт продаётся у разных продавцов», это самый прямой путь в этом списке.
Здесь есть важная ловушка: по состоянию на 15 мая 2026 года изменения в Google заставили SearchAPI требовать свежий product_token для каждого запроса — старые параметры product_id/prds теперь дают обычную ошибку 400. Если вы интегрируете сервис по старым примерам кода или туториалам, это сломается без особых предупреждений, пока вы не заметите проблему.
SearchAPI также прямо предупреждает, что фильтры на естественном языке внутри запроса — например, «under $30» или «used» — это скорее подсказки, чем жёсткие фильтры: Google всё равно может вернуть результаты вне их рамок, если совпадений мало. Для строгой фильтрации нужны закодированные shoprs-фильтры. Есть и ещё одно важное несоответствие в документации: SearchAPI продаёт endpoint как «real-time», но в собственном соглашении об обработке данных сказано, что для производительности результаты кэшируются. Публичный TTL нигде не указан, так что если для вас важна динамика цен, протестируйте несколько повторных запросов, прежде чем строить пайплайн на предположении о свежести.
Цены (проверено 2026-08-13) начинаются с $40/месяц за Developer tier при $4 за 1,000 поисков и снижаются при больших объёмах; документированный предел по часу составляет 20% от месячной квоты.
Лучше всего подходит для: команд, которым важны сравнения на уровне seller/offer и которые готовы жить с двухзапросным workflow и самостоятельно проверять свежесть данных.
4. DataForSEO — данные Merchant и Shopping в масштабе, через очередь
DataForSEO выбивается из этого списка, потому что это не live API в стиле request/response, а task-based очередь. Вы отправляете задачу с ключевым словом, локацией и языком, получаете task ID и либо опрашиваете результаты, либо настраиваете callback URL. Обычное получение результатов; для основных Shopping endpoint нет live-режима, как бы это ни звучало в общем маркетинговом описании.
Это важно, потому что меняется само понимание сложности настройки. Это не сложно в абсолютном смысле, но это другой mental model, чем «вызвал API — получил JSON»: вы управляете состоянием задач, а в документации DataForSEO прямо сказано, что callback-сервер, который не отвечает за 10 секунд, отправляет задачу в очередь «Tasks Ready», после чего её нужно опрашивать вручную.
Заслуженное место в списке он получил за bulk research: endpoint Products возвращает rank, domain, title, price, old price, rating и количество голосов, а также явные идентификаторы типа результата, которые различают google_shopping_sponsored_carousel, google_shopping_paid и органические результаты — это действительно одно из самых понятных разделений рекламных и органических данных во всём обзоре. Также сервис прямо предупреждает, что product_id динамический и иногда может быть null, а персонализирующие факторы ранжирования (история пользователя, предпочтения по местоположению) намеренно исключены из результата — полезный уровень честности, который многие вендоры пропускают.
Оплата идёт за блоки результатов (40 для Products, 10 для Sellers/Reviews) при обычной скорости очереди до 45 минут или приоритетной очереди до одной минуты — вдвое дороже. Новым аккаунтам дают $1 trial credit без срока действия.
Лучше всего подходит для: команд, которым комфортен queued, task-based workflow и нужен массовый merchant/product data по расписанию.
5. Bright Data — три продукта под одной вывеской
Здесь нужно притормозить, потому что Bright Data на самом деле предлагает три разных способа получить данные Google Shopping, и они работают совсем по-разному. Есть готовый dataset (в маркетинге — более 7,4 млрд записей, доставка в ваш cloud warehouse в JSON/CSV/Parquet по расписанию), есть Google Scraper API с отдельными Shopping scraper ID, который запускает синхронные или асинхронные задачи, и есть SERP API, который ходит по live Shopping URL и парсит результаты в реальном времени. Считать это одним продуктом — типичная ошибка многих сравнительных статей; я так делать не буду.
В примере данных из dataset видно значение null у product ID, description, rating и reviews count в некоторых строках — хорошее подтверждение от самого вендора, что «структурированный dataset» не означает «каждое поле всегда заполнено». SERP API отдельно документирует Product Listing Ads как собственный тип результата (top_pla, bottom_pla, jackpot_pla) с title, price, shop и rank — действительно полезное разделение sponsored/vs organic, если вы работаете именно с SERP API, а не с dataset.
Асинхронные задачи через Scraper API могут возвращать общий статус «success», даже если отдельные входы внутри партии не прошли — документация прямо советует проверять поле errors и повторять такие элементы отдельно. Это важная деталь поддержки, если вы запускаете крупные батчи.
Цены (проверено 2026-08-13) сильно зависят от поверхности: dataset показывал $250 за 100,000 одноразовых записей, SERP API — 5,000 бесплатных запросов в месяц и pay-as-you-go по $1.50 за 1,000, а отдельный Shopping Scraper API имел уже свой free tier и свою ставку. Не считайте эти цифры взаимозаменяемыми — проверяйте конкретную страницу того продукта, который собираетесь использовать.
Лучше всего подходит для: enterprise-команд, которым нужна одна платформа и для готовых датасетов, и для live API-доступа, и которые готовы отдельно считать цену каждой поверхности.
6. Oxylabs — самый понятный двухшаговый сценарий для search + product detail
Oxylabs делит Shopping на две отдельные цели: google_shopping_search для результатов на уровне выдачи и google_shopping_product для детальных данных по каждому товару, связанные через product token. Search-ответ аккуратно отделяет pla (платные товарные объявления) от organic products — пожалуй, это самое ясное документированное разделение sponsored/organic во всём обзоре — а product endpoint добавляет предложения по каждому продавцу с числовой ценой, состоянием, налогом, полной стоимостью и доставкой.
Но есть условие, и вполне серьёзное: этот token workflow работает только если в search-запросе вы укажете и render: "html", и parse: true. Пропустите любой из них — и product token не придёт, а весь второй шаг с деталями товара развалится. Oxylabs также явно предупреждает, что search и product-запросы должны использовать идентичные значения локализации — если geo_location не совпадает между двумя вызовами, результаты product могут вернуться неполными или неверными. А если вам нужен раскрытый блок «More stores» с дополнительными предложениями продавцов, для этого тоже нужно включить rendering, что повышает стоимость.
Ещё одна деталь, которую легко пропустить: в FAQ по цене Oxylabs определяет «успешные» запросы, за которые списываются деньги, как включающие и ответы 2xx, и ответы 4xx. То есть если ваш запрос сам по себе составлен неверно, за него всё равно могут списать деньги.
Отзывы по продукту задокументированы только для US-локали, а locale/language и locale/results-language — это действительно разные настройки: изменение одной не включает автоматически другую.
Лучше всего подходит для: технических команд, которым нужны и данные уровня ранжирования, и детальные предложения по каждому продавцу, и которые могут выстроить связку токенов и следить за консистентностью локали.
7. Scrapingdog — простой endpoint, но мало публичных деталей
Scrapingdog предлагает один отдельный endpoint Google Shopping, который принимает API-ключ и запрос, а в ответ возвращает JSON с title, ценой и извлечённой числовой ценой, старой ценой, рейтингом, отзывами, источником/продавцом, доставкой и позицией. На странице также упоминаются фильтры по цене, бренду, стране и языку, а ещё отдельная категория ответа ads для отслеживания спонсируемых размещений. Но точная схема ads и точные имена параметров локали в публичной документации раскрыты не полностью, так что стоит заложить время на тестирование под свой кейс, прежде чем строить автоматизацию вокруг этого инструмента.
Это единственный инструмент в списке, где математика кредитов не сходится только на основе публичной документации: на странице цен есть месячные пакеты (LITE — $40/месяц за 200,000 кредитов, STANDARD — $90/месяц за 1,000,000), но не сказано чётко, сколько кредитов стоит один запрос Google Shopping. Не стоит думать, что это 1:1 как в их примерах общего search API — лучше уточнить у вендора напрямую, прежде чем считать реальную стоимость одного запроса.
Как и большинство других в этом обзоре, Scrapingdog рекламирует встроенные rotating residential proxies и автоматическую обработку CAPTCHA как часть поддержки со стороны вендора. Воспринимайте это как границу ответственности за поддержку, а не как обещание гарантированного доступа.
Лучше всего подходит для: разработчиков с ограниченным бюджетом, которым нужен узкий специализированный endpoint и которые готовы заранее уточнить стоимость кредитов.
8. Apify — оценивайте actor, а не marketplace в целом
Сразу уточню важный момент: Apify — это не один Google Shopping scraper, а marketplace из независимо поддерживаемых «Actors», и тот, который я изучал внимательнее (Google Shopping Insights, автор epctex, помечен как «Maintained by Community»), ведёт себя заметно иначе, чем инструменты под управлением самих вендоров выше. Apify предоставляет runtime, прокси-инфраструктуру и инструменты экспорта dataset. Но сама логика извлечения Shopping — и её поддержка — принадлежит epctex, а не Apify как платформе.
Это различие критично, потому что в официальном примере результата у этого actor поле price равно null. Не иногда, не только для out-of-stock товаров — в документированном примере записи price: null и withoutDiscountPrice: null стоят рядом с заполненными полями product name, merchant и rating. Это, пожалуй, самое сильное подтверждение из всего обзора, что нельзя автоматически считать price-поле полным, и оно идёт прямо из документации самого инструмента.
У вас есть настраиваемые входные параметры — includeSponsoredResults, includeComparisonPrices для кросс-мерчант сравнения, country code targeting, maxItemsPerQuery — и обязательная настройка proxy (ваша или Apify). Результаты можно экспортировать в JSON, XML, CSV или Excel через систему Dataset от Apify. На странице Store, которую я проверял, было примерно 2,300 пользователей всего, но только 2 monthly active users на тот момент — показатель, который стоит учитывать, потому что «community maintained» работает в обе стороны: гибко, но надёжность зависит от того, кто реально использует инструмент и сообщает о проблемах.
Лучше всего подходит для: разработчиков, которым комфортно оценивать активность поддержки конкретного actor и проверять его фактическую схему вывода перед тем, как внедрять его в работу — но не для тех, кто ожидает, что бренд Apify сам по себе гарантирует стабильное поведение.
9. Thunderbit — no-code сбор данных для маркетологов
Thunderbit представляет другой полюс этого списка: браузерный no-code workflow для тех, кто хочет посмотреть на страницу, которую видит сам, и превратить её в структурированную таблицу, а не интегрировать Google Shopping API. Это естественный выбор для маркетологов, PPC-специалистов и небольших ecommerce-команд, которым нужны разовые проверки, а не высоконагруженный backend-пайплайн.
Что вы получаете: browser-side извлечение данных. Откройте страницу Shopping-результатов, которая вам нужна, дайте Thunderbit прочитать отрендеренную страницу в один клик и выгрузите поля прямо в Excel, Google Sheets, Airtable или Notion. Есть и реальное ограничение, но оно относится к Shopping в целом, а не к одному инструменту: поскольку извлечение идёт со страницы перед вами, результат наследует гео, язык и сессию этого браузера. Зафиксируйте эти настройки, прежде чем считать выгрузку этой недели сопоставимой с прошлой. Это та же проблема надёжности полей, которую обсуждает следующий раздел, и она касается каждого варианта в этом списке.
Лучше всего подходит для: нетехнических команд, которые ценят видимое, проверяемое браузерное извлечение вместо управляемого разработчиком JSON-пайплайна, и которые собирают конкретные Shopping-страницы по запросу, а не запускают массовый multi-geo crawl.
Каким данным можно доверять? Проблема надёжности полей
Это та часть, которую большинство сравнительных статей о Google Shopping пропускают полностью, хотя именно она важнее всего перед автоматизацией: не каждое поле есть в каждой карточке, и если трактовать «отсутствует» как «ноль», данные будут тихо портиться.
| Поле | Надёжность | В чём подвох |
|---|---|---|
| Заголовок | Высокая | Нормализуйте варианты и наборы перед сопоставлением товаров из разных источников |
| Product ID | Условная | DataForSEO прямо указывает, что он динамический и иногда равен null |
| Цена | Условная | В официальном примере Apify поле цены в заполненной записи равно null |
| Продавец/merchant | Обычно есть | У одного товара может быть несколько отдельных предложений от разных продавцов |
| Рейтинг/число отзывов | Условная | У новых или безоценочных товаров этого поля может просто не быть — не превращайте отсутствие в ноль |
| Доставка | Нестабильная | Может зависеть от страны доставки, наличия у продавца и сессии |
| Флаг спонсируемого результата | Зависит от инструмента | Oxylabs чётко разделяет pla и organic; у нескольких других можно лишь включать/исключать sponsored results без надёжной построчной метки |
Практическое правило: прежде чем автоматизировать что-либо, возьмите реальную выборку по своим ключевым запросам и проверьте, что именно оказывается null, дублируется или отсутствует — а не то, что, по мнению документации, «должно быть».
Официальный Google Merchant Center или Google Shopping Scraper: что вам нужно?
Это вопрос, который ecommerce-команды задают ещё до сравнения вендоров, и на него стоит ответить прямо: если вы управляете собственными товарными карточками, ценами или Shopping-рекламой, вам нужны официальные инструменты Google Merchant Center, а не сторонний scraper. Инструменты из этого списка предназначены для наблюдения за чужими карточками: конкурентными ценами, видимостью на рынке, исследованием категорий и мониторингом спонсируемых размещений. Не путайте это. Актуальное название и охват first-party API лучше проверить в официальной документации Google напрямую, потому что эти продукты периодически переименовывают и перестраивают.
Как эти инструменты обходят антибот-защиту Google
Я подаю это как вопрос управления рисками, а не как урок «как обойти Google», потому что это честный способ смотреть на ситуацию. Несколько вендоров из списка — SerpApi, SearchAPI, Bright Data, Oxylabs, Scrapingdog — публично заявляют, что сами управляют ротацией прокси, browser rendering и CAPTCHA handling. Это реальная граница ответственности, которую стоит ценить: вам не нужно в 2 часа ночи дебажить заблокированный IP. Но это не гарантия постоянного или универсального доступа — и так это читать не следует.
Даже при полностью управляемом сервисе никуда не деваются контроль скорости и расходов, классификация ошибок, retries и мониторинг изменений на стороне Google (а судя по changelog’ам, которые я нашёл у SearchAPI и Oxylabs, это происходит довольно регулярно). Bright Data прямо документирует сбои в частях батча; DataForSEO описывает поведение при таймауте callback; Oxylabs документирует ошибки при невалидных токенах. Всё это — не инструкция по обходу ограничений, а честное описание того, кто за какой тип сбоя отвечает.
Как выбрать лучший Google Shopping Scraper для вашей команды
Идите по этому порядку:
- Определите свой профиль. Вы разработчик, строящий пайплайн, или маркетолог/ops-специалист, которому нужен результат без работы с кодом?
- Чётко опишите, какие поля вам действительно нужны. Данные уровня выдачи — это не то же самое, что детализация цен на уровне merchant/offer. SearchAPI и Oxylabs особенно хороши именно для второго сценария.
- Будьте честны насчёт возможностей поддержки. Маппинг API и обработка ошибок, настройка actor и прокси, или browser-based извлечение с ручной проверкой — выбирайте то, что ваша команда сможет реально сопровождать долго.
- Проверьте поведение локали и устройства на реальных запросах до выбора поставщика, потому что публичная документация не всегда идеально совпадает с поведением вживую.
- Убедитесь, что путь экспорта подходит вашему стеку — JSON в data warehouse и таблица, которую маркетолог может открыть напрямую, требуют совершенно разного объёма усилий.
Итог: какой Google Shopping Scraper вам выбрать?
Одного «лучшего» решения здесь нет, и если подборка уверяет в обратном — относитесь к этому скептически. Если вы разработчик и строите пайплайн данных, а вам нужна самая богатая документированная схема с явными настройками cache и locale, начните с SerpApi. Если ваша реальная цель — сравнение предложений на уровне seller/offer, то SearchAPI или token-based workflow Oxylabs приведут вас туда напрямую. Если вы ведёте массовые, регулярные исследования и можете жить с очередью задач, DataForSEO масштабируется хорошо. Если вам нужна одна enterprise-платформа и для готовых датасетов, и для live-запросов, Bright Data покрывает больше всего сценариев — просто считайте цену каждой поверхности отдельно.
А если вы работаете в PPC или маркетинге и не хотите трогать API-ключ, браузерная категория, которую представляет Thunderbit, — это прямой ответ на запрос «мне нужны данные, а не кодовый проект». Только важно понимать, какую именно поверхность вы выбираете: browser workflow создан для страниц, которые вы открываете и проверяете сами, а API-документация Thunderbit и CLI — это отдельные developer-oriented пути. Выбирайте тот, который соответствует тому, как ваша команда действительно работает.
Что бы вы ни выбрали, сначала возьмите реальную выборку. У каждого вендора в этом списке есть хотя бы одно поле, которое присутствует не всегда — проверьте это до того, как строить на основе данных что-то серьёзное.
FAQ
Законно ли собирать данные Google Shopping? Я не могу дать на этот вопрос категоричный ответ, и ни одна подборка не должна этого делать вместо вас. Публично доступные данные и заявления вендора о compliance не означают автоматически, что любой сценарий использования законен. Прежде чем строить что-то на этой основе, проверьте текущие условия Google, изучите применимое право в вашей юрисдикции и убедитесь, что метод сбора данных разрешён. Рассматривайте это как случай «идите и проверьте с вашим юристом», а не как вопрос, который может закрыть блог-пост.
В чём разница между SERP API и Google Shopping scraper? SERP или Shopping API принимает структурированные параметры запроса и возвращает вам распарсенный JSON — большая часть инфраструктуры извлечения данных лежит на вендоре. Браузерный scraper (например, Thunderbit) извлекает данные со страницы, которую вы или пользователь действительно открыли. Продукты на основе dataset (например, часть предложения Bright Data) поставляют заранее собранные записи по расписанию, а не по live-запросу. По назначению они похожи, но сильно отличаются по свежести данных, управлению локалью и объёму сопровождения с вашей стороны.
Нужны ли навыки программирования, чтобы собирать данные Google Shopping? Не всегда. Весь смысл Thunderbit — в no-code, click-based workflow именно для таких случаев. Apify технически можно запускать через веб-интерфейс без написания кода, хотя для серьёзной кастомизации технический опыт всё же помогает. Все API-инструменты в этом списке — SerpApi, Serper, SearchAPI, DataForSEO, Bright Data, Oxylabs, Scrapingdog — требуют хотя бы базовых навыков разработчика: авторизации, работы с параметрами и проверки ошибок.
Как часто меняются данные Google Shopping? Чаще, чем многие думают, но универсального правила в духе «обновляется каждые X часов» не существует. Цены, наличие, спонсируемые размещения и позиции могут меняться в зависимости от сессии, локали и времени суток. Несколько вендоров здесь предлагают live/real-time режим именно потому, что кэшированные данные быстро устаревают в этой категории. Если вам нужны актуальные цены, запускайте запрос заново, а не доверяйте результату со вчерашнего дня.
Узнать больше
