Парсер Гугл Карт: обзор, инструкция и сценарии для многопоточного парсера — готовое решение для парсинга отзывов

Google Maps - крупнейших источник данных о различных местах, начиная от точек общепита и заканчивая офисами корпораций. В карточках организаций и мест собраны названия, адреса, контакты, рейтинги и конечно же отзывы. Для кого-то (маркетологи, SEO-специалисты, аналитики) эти данные - кладезь полезной информации: с их помощью собираются базы потенциальных клиентов, анализируются конкуренты, кто-то даже проводит исследования рынка. А вот для кого-то (разработчики парсеров) - это настоящая боль. Или дорого, или сложно или и дорого и сложно одновременно.

Google, конечно понимает повышенный интерес к своей базе и предоставляет официальный API для парсинга (Google Places API), но у него есть существенные ограничения - во-первых, он платный, что на больших объемах существенно бъет по бюджету, а во-вторых, тут есть лимиты по частоте запросов. Эти ограничения и побуждают компании прибегать к альтернативному подходу - парсингу отзывов (как в моем случае) или парсингу данных (в широком смысле) непосредственно с веб-версии Google Maps, минуя официальный API.

Собственно я прошел этот путь ровно также, как его проходит большинство специалистов, кому нужны данные из Гугл Карт. Сперва АПИ, считаем экономику - понимаем что она не сходится - перестраиваем экономику и вместо оплаты лимитов Гугла, сокращаем траты за счет использования прокси и многопоточного парсера. Собственно из затрат у меня реально были только прокси от Proxyma, я использовал самый простой тариф 5$ за 1 Гб трафика, но в целом, если взять сразу 30Гб то цена снижается уже до 3$ за Гб трафика, что уже интереснее. 

У Проксима еще 500 мб бесплатно дают, так что мой объем мог бы быть дешевле на 2,5 доллара, но я просто потратил бесплатный лимит на тесты, поэтому 15 долларов.

В качестве прикидки, я собрал 53 тысячи строк и ушло на это 3 Гб трафика, или 15 долларов. Собственно получается что одна точка в среднем потребляет 58 КБ трафика. Получается,что 30 Гб позволят обработать 530к строк. Дальше сами, но мне кажется это сильно дешевле, чем официальное АПИ.

Парсинг отзывов через официальный API Гугла vs прямой парсинг Гугл карт (Google Maps)

Не могу не сравнить способы получения информации. Для понимания масштаба:

Парсинг отзывов через Google Places API - официальный способ получить структурированные данные о местах из экосистемы Google. Он предоставляет удобные методы: можно искать места по ключевым словам или координатам и получать подробные сведения (название, адрес, телефон, сайт, рейтинг, отзывы и т.д.) в формате JSON. Что по деньгам: Google Cloud даёт бесплатный кредит $200 в месяц на использование API, но при активном использовании этого хватит ненадолго. Дальше включается тарификация - не буду углубляться, в среднем это $32 за каждые 1000 запросов на Places API (точная стоимость зависит от типа запроса и объема, первые 100 тысяч запросов обходятся примерно в $32 за 1000, далее цена несколько снижается). И вот мы в точке принятия решения  - выгрузка информации по 50 тысячам мест это $1600 при отсутствии бесплатной квоты. 

Предположим - бабки не проблема (как говорят некоторые владельцы сервисов), вспоминаем о следующей проблеме при использовании API нужно соблюдать лимиты запросов.

Прямой парсинг отзывов с Google Maps - альтернативный подход, при котором скрипт имитирует действия пользователя: открывает веб-страницы Google Maps и извлекает из них нужные данные. Такой метод не требует API-ключа и не имеет прямой платы за каждый запрос, что привлекательно для разовых проектов или стартапов с ограниченным бюджетом. Кроме того, с помощью парсинга можно получить некоторые данные, которые недоступны через Places API - например, дополнительные фотографии, ссылки на профили, или большие объемы отзывов. Но есть и минусы: для справки - подобный парсинг нарушает правила использования Google Maps (хоть сбор общедоступной информации и не запрещён законом напрямую, это противоречит пользовательскому соглашению Google), ну и главное - Google активно противодействует таким попыткам. Большие объемы запросов с одного IP-адреса быстро приводят к появлению капчи или временному бану. HTML-разметка результатов поиска может внезапно измениться, "ломая" парсер. Но по финансовой части тут все намного интереснее - по факту вы платите только за использование прокси. Парсер, который я описываю в статье, например, в 10 потоков собирает 50 тысяч отзывов за несколько часов, по затратам - 3 ГБ трафика на прокси (15 долларов).

Обзор парсера Google Карт (Google Map Scraper)

На этих вводных и родился парсер отзывов с Гугл Карт. Нестыковка бюджета и потребность в информации быстро. Вот как работает мой парсер. Сразу оговорюсь, на сегодняшний момент парсер работает, и мою задачу закрывает. Когда Гугл внесет правки, парсер может отвалиться, пока не поправить логику. Но с минимальными временными вложениями его можно будет допилить (я не припомню на этом веку, чтобы гугл как то сильно кардинально менял верстку в последнее время).

Парсер доступен для скачивания на моем Гитхаб - Google-Map-Scraper. Теперь более подробно о самом парсере Гугл Карт. 

Как Работает Парсер Гугл Карт - или парсинг отзывов с Гугла на многопотоке

Парсер состоит из трех основных файлов и одного входного csv файла, где собраны исходные данные:

Исходный файл: places.csv  - в файле следующие столбцы: place_id, name (+ опционально category, categories, polygon_name, place_url) - это артефакты моей задачи и вы можете почистить исходный файл под свои нужды, но тогда придется править и основные файлы.

Самое главное тут - place_id - уникальный ID объекта в Google. URL формируем через ?q=place_id:<ID>. Все остальные данные - это внутренние данные, для удобства дальнейшей работы.

Главное, что вам требуется - получить place_id мест, которые вы будете парсить. (Спойлер - на Apify это можно практически даром, ну или можете использовать тот же Гугл АПИ, тоже будет платно, но не 1600 долларов за 1000 мест, дешевле, я бы все таки рекомендовал присмотреться к Apify, там есть варианты).  

Файл, который распределяет потоки и в целом регулирует работу парсера и отвечает за многопоток - main_reviews.py, он:

загружает места (load_places) и прокси (load_proxies),

рассчитывает реальное число воркеров (потоков) = min(threads, len(proxies)),

каждому воркеру (потоку) закрепляет свой прокси (worker-per-proxy),

делит список мест по воркерам "шагами",

запускает потоки в ThreadPoolExecutor.

При парсинге каждый поток вызывает process_one → scrape_place_reviews(place, proxy) из основного файла scrape_reviews.py до MAX_RETRIES_PER_PLACE попыток.

Вот мы и подошли к самому основному файлу, который и отвечает за парсинг Гугл карт, файл - scrape_reviews.py. На нем и держится вся экономика весь парсинг, вот что он делает:

запускает Playwright-браузер с прокси,

проходит баннер согласия, открывает вкладку "Отзывы",

сортирует отзывы по кнопке "Новые", опционально включает "Перевести отзывы",

находит реальный скролл-контейнер ленты,

скроллит с паузами, расширяет текст "Read more",

парсит карточки (автор, рейтинг, дата, текст, фото, Local Guide, сырой JSON),

возвращает список строк.

После того, как данные собраны, в дело снова вступает main_reviews.py, он записывает строки под глобальным lock дописывает строки в файл output_reviews.csv.

По окончании парсинга корректно закрывает page/context/browser, и печатает статистику, - вкусовщина в виде - "✅ Готово."

Что особенного в Парсере Гугл Карт - где были сложности во время парсинга отзывов, и как я их пофиксил

Как это периодически и бывает, метод проб и ошибок в результате создает ту самую версию парсера, которая не ломается при малейшем чихе, учитывает те или иные косяки. Как правило ты в эти моменты такой: “А, вон че произошло… Ну давай теперь так попробуем…”

Итак, какие ключевые фишки я выделил и чем дополнял парсер (в самом первоначальном исполнении это вообще был продукт на максимум 300 строк кода:

Прокси для Playwright: поддержка http/https/socks5/socks5h + логин/пароль (функция parse_proxy_for_playwright() разбирает URL и передает в browser_type.launch(headless=..., proxy=...)). Проблема не восприятия прокси вида Socks вылезла почти сразу, так что пофиксил я ее практически сразу.

Экономия трафика без поломки UI: роутинг ресурсов и отработка request.resource_type
- режем media/font/manifest/ads/analytics, но не блокируем stylesheet и image, чтобы не "ломать" верстку карты. Тут пришлось повозится, так как в различных итерациях сама карта то прыгала, то не скроллилась, как говорится, “сейчас я дома уже”.

Анти-попап и consent:

handlegoogle_consent() нажимает Reject all/Accept all на разных языках;

принудительно отключено window.open, а открывшиеся "левые" вкладки закрываются, если домен не google.*.

Это решение появилось после того, как я прикрутил прокси и запустил парсер на многопотоке - карты начали одна за одной запрашивать подтверждение кук, вот и пришлось дописывать это. А случайные клики по ссылкам генерили десятки левых страниц (как правильно это были страницы Трипадвайзера, так как они с определенного времени выводятся на Гугл картах и парсер, так получалось, именно их прокликивал). 

Допом прикручен парсинг фотографий из самих отзывов, в качестве факультатива. Урлы фото собираются в одну строку, через запятую.

Собственно все остальное скучный поиск карточек, скроллинг и сбор информации, думаю это не столь важно, если интересно - можете поковырять.

Многопоточность: как не "убить" карту и свой сервер парсингом отзывов с Гугл Карт

Почему нужен мультипоток? Вероятно не нужно подробно объяснять чем полезен многопоточный парсер Гугл карт, разве что кратко. Одна точка, с которой собираются отзывы может скроллиться десятки секунд (у меня были точки которые скроллились несколько минут); параллель - главный ускоритель.

В парсере реализована стандартная, на мой вкус, методика - один поток один уникальный прокси. Запускаем 10 потоков, должно быть подготовлено 10 проксей, 20 потоков - 20 прокси, систему вы поняли. Если прокси меньше, чем запрошено потоков, число воркеров автоматически урезается до числа прокси. Теперь личные рекомендации:

Начните с --threads 3..5 и используйте ровно столько же прокси; следите за стабильностью.

Если решили парсить без прокси - не превышайте 2-3 потоков, иначе быстро упрётесь в капчи/пустые выдачи (я по глупости пустил 5 потоков без проксей, но через 100 точек у каждого потока санкций еще не было, что удивительно).

Мониторьте память: Playwright-браузеры прожорливы. Закладывайте ~300-600 МБ на поток (с запасом). 

Я пробовал запустить парсинг отзывов с Гугла в больше чем 10 потоков и стал ловить ошибки недостатка памяти в самом браузере, так что учитывайте это.

Какие прокси для парсинга Гугл Карт брать: резидентные vs датацентр и их формат

Парсер Гугл карт поддерживает следующие форматы: http://, https://, socks5://, socks5h:// (+ user:pass@host:port). А socks5h еще резолвит DNS на стороне прокси (это полезно при geo-локе и утечках DNS).

Почему прокси вообще необходимы? При парсинге публичных данных (любых, отзывы, карточки товара и тп)) главный враг - это блокировки по IP-адресу. Google, обнаружив большой объем запросов от одного клиента, может временно перестать отдавать результаты и показать страницу с проверкой (CAPTCHA или сообщение “Our systems have detected unusual traffic…”). Для Google Maps характерно, что при перегрузке запросами начинает возвращаться пустая страница результатов или редирект на CAPTCHA. Один из способов избежать этого - ротация IP-адресов, то есть отправка запросов через разные узлы сети. Сегодня существует множество прокси сервисов, которые предоставляют вам в пользование пул IP-адресов. Вы можете настроить парсер так, чтобы каждый поток (или каждый N-й запрос) проходил через новый прокси - тогда нагрузка распределяется, и для Google это выглядит как обращение множества разных пользователей, а не одного бота.

В заголовке я указал - резидентные или серверные (датацентр) - но это риторический вопрос, при парсинге, а тем более при парсинге Гугл карт - не может быть никаких - “а что если сэкономить и купить серверные прокси?”. Остановитесь - вы рискуете с такими мыслями. Серверные прокси находятся в сильно зоне риска по сравнению с резидентными. 

Почему резидентные?

• Меньше капч и "аномального трафика", естественнее для Google.

• Да, дороже (обычно тарификация по трафику), но при блоке датацентр-IP вы теряете время целой сессии.

Перед тем как пустить прокси в работу:

Подготовьте несколько проксей заранее и протестируйте их. Убедитесь, что они рабочие и не слишком "медленные".

Распределите прокси по потокам. Если у вас 10 прокси и 5 потоков, можно настроить попеременное использование - так на каждый поток всегда будет как минимум 2 адреса, чередующихся между запросами.

Как я уже упоминал, я использовал резидентные прокси от Proxyma и не пожалел, аккаунты не отлетали в бан, что иногда бывает даже с резидентными проксями. Я об этом писал уже в статье Прокси для парсинга, если интересно глубже погрузится в вопрос - велком.

Для работы парсера потребуется файл proxies.txt, он воспринимает такие строки с прокси:

socks5h://user:[e-mail]:1080
http://user:[e-mail]:8080
socks5://user:[e-mail]:1080

В целом, использование прокси - обязательный пункт для стабильного парсинга Google Maps. Без них парсер годится разве что для очень мелких задач (выгрузить пару сотен мест и остановиться). Если же планируется регулярный сбор больших массивов - прокси маст хев решение..

Что нужно для старта парсера Гугл карт: установка и запуск

Запускается парсер Гугл карт такой командой:

python -m reviews.main_reviews --in reviews/places.csv --out reviews/reviews.csv --threads N --proxies proxies.txt

Но перед этим нужно установить зависимости, на гитхаб они все собраны в файле requirements.txt, поэтому просто запустите распаковку, командой:

pip install -r requirements.txt

Инициализируйте браузеры Playwright:

python -m playwright install chromium

По желанию можете использовать firefox/webkit - скрипт позволяет выбрать браузер env-переменной

Про исходные данные писал выше, уточню только, что categoriesможно передавать JSON-массивом строк.

Что можно задать вместе с командой на начало работы парсера Гугл Карт

• HEADLESS (true/false) - тут все понятно.

• REVIEW_LANGUAGE (en|ru|...) - &hl=... и locale контекста - выставляем нужный язык.

• BROWSER (chromium|firefox|webkit) - писал выше, что можно выбрать браузер.

• SCROLL_IDLE_ROUNDS / SCROLL_PAUSE_MS / MAX_SCROLL_ROUNDS - поведение скролла.

• MAX_RETRIES_PER_PLACE - повторы открытия.

• MAX_REVIEWS_PER_PLACE=0 - без лимита (поставьте нужное количество, чтобы ограничить, по дефолту будет идти до конца, как морпех).

• DEBUG_SELECTORS=1 - подробный лог скролла/карточек.

• TRANSLATE_SWITCH=1 - нажать "перевести отзывы".

• LANG_FILTER_EN=1 - если захотите фильтровать по EN (заложено для тех, кто будет копаться в коде).

Вот как выглядит пример команды на запуск с дополнительными параметрами:

$env:HEADLESS = 'false'
$env:DEBUG_SELECTORS = '1'
$env:SCROLL_IDLE_ROUNDS = '3'
$env:SCROLL_PAUSE_MS = '900'
$env:MAX_SCROLL_ROUNDS = '200'
$env:REVIEW_LANGUAGE = 'en'
python -m reviews.main_reviews --in reviews\places.csv --out reviews\reviews.csv --threads 5 --proxies proxies.txt

Бюджет: сколько стоит в реальности парсинг отзывов с Гугл Карт?

• Свои прокси (резидентные): как уже говорил - обычно счёт по трафику. На один большой прогон отзывов 1-5 ГБ хватает с запасом → $3-$25 от 50к до 500к, плюс минус..

• Сервис распознавания капчи (опционально): если внедрять - $1-$10 на прогон в зависимости от "погодных условий". Но, как правило с нормальными прокси выдача не капчует, но если сильно хочется, можно прикрутить, решений полно. 

• Итого: несколько десятков долларов при больших выгрузках (против сотен/тысяч при API). Плюс ваше время - единственная "скрытая" статья.

Практические советы как не словить бан при парсинге Гугл карт

1. 1 поток = 1 уникальный прокси. Строго один-к-одному.

2. Паузы и "человечность". Не ставьте SCROLL_PAUSE_MS слишком низким; лучше длиннее, но зато стабильнее.

3. Гео прокси ≈ гео данных. Российские данные - RU-прокси; ЕС - лучше EU, рассинхрон может и с вероятностью в 99% вызовет подозрения.

4. Не отключайте images/styles. Карта "сыпется" и селекторы ведут себя нестабильно - визуально это выражается в дергании экрана и как результат ничего не собирается (знаем, плавали).

5. Мониторьте логи. DEBUG_SELECTORS даёт быстрый сигнал, что лента "встала".

6. Лимиты и чекпоинты. Будьте последовательны и аккуратны, не пытайтесь охватить "весь мир за раз".

Сравнение решений и бюджетные соображения - как парсить отзывы с Гугла другим способом

Как говорится, ну это понятно, а что по альтернативе то? Насколько выгодно и рационально использовать свой парсер? Может есть решения еще дешевле? Как еще можно добывать данные с Google Maps?

1. Официальный путь - Google Maps Platform (Places API). Преимущества: полностью легально и стабильно, вы получаете гарантированно актуальные и структурированные данные напрямую от Google. Интеграция через API может быть проще, чем возня со своим парсером (но если вы новичок, будет одинаково сложно). Минусы: стоимость. При серьезных объемах это десятки и сотни долларов. Кроме того, API накладывает ограничение на количество результатов в одном запросе.

2. Готовые коммерческие парсеры и SaaS-сервисы. Сюда относятся такие решения, как Outscraper, Apify Google Maps Scraper, SerpAPI, и другие. Например, Outscraper позиционируется как лидирующее решение для парсинга Google Maps с удобным веб-интерфейсом и API. Прелесть этих сервисов в том, что вам не нужно думать о прокси, капчах и обновлениях скриптов: провайдер берет эти заботы на себя и просто продает вам результат. Обычно оплата у них - либо помесячная подписка, либо по количеству результатов (например, несколько центов за одну компанию). В случае Outscraper есть даже бесплатный лимит на пробу и платёж около $0.004 за результат сверх лимита, ($4 за 1000 элементов) - в разы дешевле Google API, но всё же расходы растут линейно с масштабом. Если нужно спарсить сотни тысяч объектов, счёт тоже пойдёт на сотни долларов. Преимущество - экономия вашего времени: не надо быть инженером, запустил через веб - и получил Excel на выходе. Недостаток - долгосрочная зависимость от сервиса и риск, что вдруг политика цен или доступ может измениться.

3. Десктопные программы и скрипты. Помимо моего парсера, существуют и платные десктопные парсеры. Пример - A-Parser - мощный комбайн для SEO-задач, который умеет в том числе парсить данные с карт Google и Яндекса. A-Parser стоит порядка $119 за лицензию, зато очень оптимизирован и поддерживает десятки источников. Подобные программы выгодны, если вы регулярно занимаетесь парсингом разных данных - они дают единый интерфейс и техподдержку. Однако, для узкой задачи (собрать отзывы с Google Maps) покупать дорогой софт имеет смысл не всегда, к тому же им тоже надо уметь пользоваться (порог вхождения не ниже, чем у open-source скрипта).

4. Самописный парсер на базе библиотек. Те, кто владеет Python/JS, могут написать скрипт с нуля, используя библиотеки вроде Selenium, Scrapy, BeautifulSoup. Но в особых случаях, когда нужны кастомные данные или логика, свой код может быть оправдан. Разумеется, тогда все вопросы (многопоточность, прокси, обработка ошибок) вам придется решать самостоятельно.

Теперь оценим бюджет. Предположим, вам нужно получить отзывы о ~50 000 местах:

• Через парсер: бесплатный софт + прокси. Допустим, вы взяли резидентные прокси и потратили 5 ГБ трафика на сбор этого объема. По $3/ГБ это $15. Итого ~$15. Зато свои временные затраты: нужно было настроить, запустить, проследить за работой, при необходимости перезапустить упавшие задачи. Цену своего времени тоже учитываем.

• Через Outscraper: по $0.004 за штуку, за 50k - $200. Никакой возни, все готово, но заплатили существенно больше.

• Через Google API: 50k запросов - примерно $32 * 50 = $1600 (минус бесплатный $200 кредит = $1400). Очевидно, самый дорогой путь.

• Покупка A-Parser: $119 единовременно, плюс всё равно нужны прокси и время на освоение программы. Возможно оправдано, если парсить будете не разово, а регулярно и разные данные.

Получается что парсер Гугл карт + прокси - самый бюджетный вариант по деньгам, примерно на порядок дешевле облачных сервисов и тем более официального API. Несмотря на то что это мой парсер, я не пытаюсь показать какой он замечательный, просто сухие факты.

Парсинг Google Карт - задача не тривиальная, но решаемая. Для новичков она отлично иллюстрирует сразу несколько аспектов веб-автоматизации: работу с динамическими сайтами, обход антибот-мер, организацию многопоточных скриптов. Использовать парсер или нет - решать вам, для меня он свою задачу выполнил и продолжает выполнять на отлично!