Как парсить данные из мобильных приложенийшаги и стек инструментов

Всё большая часть интернета теперь находится внутри мобильных приложений. Некоторые компании практически полностью отказались от браузерного опыта и предоставляют тот же каталог, листинги или контент через нативное приложение. Этот сдвиг следует за смартфонами, которые есть у каждого: число подписчиков на смартфоны продолжает расти год от года, а приложения, работающие на них, содержат цены, отзывы, листинги и сигналы, которые команды действительно хотят анализировать.

Проблема в том, что приложение не является веб-страницей, и методы, которые применяются при парсинге сайта, не переносятся напрямую. Этот обзор разбирает, чем данные мобильных приложений отличаются от веб-данных, реалистичный подход к их сбору (публичные листинги магазинов приложений и публичные API-эндпоинты, а не сам бинарный файл), необходимые инструменты и прокси, с какими сложностями вы столкнётесь и как делать всё это ответственно, работая только с публичными данными. К концу вы будете знать, какие части "данных мобильных приложений" практически реализуемы, а какие не стоят затраченных усилий.

Чем данные мобильных приложений отличаются от веб-данных

Веб-сайт не зависит от платформы. Любой браузер на любом устройстве с доступом к интернету может запросить URL и отрендерить тот же HTML, поэтому парсер может имитировать браузер, запросить страницу и прочитать то, что вернётся. Поскольку контракт открытый и предсказуемый, исходный код страницы доступен для парсинга. Именно поэтому большинство руководств по парсингу, включая наше по парсингу сайта на Python, предполагает работу с HTML, который можно получить напрямую.

Мобильное приложение нарушает это предположение двумя способами. Во-первых, приложение создано для конкретной платформы (Android или iOS) и работает в этой среде выполнения, а не в браузере, которым можно управлять. Нет публичного исходного кода страницы для запроса: экран, который вы видите, рендерится нативным кодом из данных, которые приложение получило в фоновом режиме. Во-вторых, эти фоновые данные обычно передаются через API, с которым общается приложение, и всё чаще этот трафик зашифрован, а иногда привязан к приложению, поэтому даже его перехват с устройства затруднён. Нужные вам данные существуют, но они находятся на один уровень глубже, чем может достать обычный HTTP-запрос.

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

Реалистичный подход: публичные листинги и публичные API

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

Публичные листинги в магазинах приложений

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

Публичные API-эндпоинты

Большинство приложений, которые изначально были сайтами, всё ещё имеют веб-аналог, и эта веб-версия поддерживается публичным или полупубличным API. Quora, Reddit, LinkedIn, Amazon, Instagram и многие другие имеют веб-версии, которые предоставляют тот же контент, что и приложение. Сбор данных из веб-свойства или из задокументированного публичного API, который предоставляет компания, даёт вам те же данные, которые показало бы приложение, без какого-либо взаимодействия с самим приложением. Когда существует санкционированный API, он почти всегда является лучшим путём: он создан для запросов, стабилен и позволяет оставаться в рамках правил провайдера. Прибегайте к неофициальному сбору данных только тогда, когда ни один API не охватывает то, что вам нужно, и только из публичных источников.

Что насчёт перехвата трафика с устройства?

Стоит понять, почему метод перехвата с устройства, который пропагандировали старые руководства, в большинстве случаев не стоит усилий. Классический подход состоял в запуске приложения Android на компьютере через эмулятор или инструмент вроде ARC Welder, а затем в мониторинге сети с помощью прокси, такого как Fiddler или Wireshark, для наблюдения за HTTP и HTTPS-вызовами приложения. В теории вы реконструируете API приложения из этого трафика и вызываете его самостоятельно.

На практике два недостатка делают это болезненным. Инструменты перехвата записывают весь трафик, входящий и исходящий с машины, поэтому вы получаете шумный смешанный трафик, который затем нужно просеивать для поиска вызовов приложения. Что важнее, современные приложения шифруют свой трафик и часто привязывают сертификаты, поэтому перехваченные полезные нагрузки нечитаемы без ключей, уникальных для приложения. Между шумом и шифрованием вы обычно тратите больше усилий на борьбу с перехватом, чем потратили бы на сбор тех же данных из публичного листинга или API. Для большинства проектов честный вывод таков: трудности и затраты не оправданы, когда существует публичный источник.

Инструменты и языки для этой работы

Как только вы работаете со сбором из веб-листингов и публичных API, инструментарий становится знакомым инструментарием веб-парсинга, и большинство популярных языков подходят хорошо. Выбирайте на основе того, что уже знает ваша команда.

• Python. Наиболее распространённый выбор для такой работы: Requests для HTTP, BeautifulSoup и Scrapy для парсинга, Selenium для страниц, требующих браузера. Наше руководство по BeautifulSoup охватывает сторону парсинга.
• Node.js и JavaScript. Серверный сбор данных с Axios, node-fetch или встроенным Fetch API, а также Superagent на стороне клиента. Естественный выбор, когда источником является JSON API.
• Ruby. Хорошо подходит для скриптового сбора данных с помощью RestClient или HTTParty для HTTP-запросов.
• PHP. Guzzle, cURL и Requests обрабатывают получение данных, и многие веб-команды уже свободно владеют им.
• Java. Надёжен для более крупных систем с HTTP-клиентами, такими как OkHttp, и более широкими фреймворками при необходимости.
• cURL. Универсальный инструмент командной строки для прямого обращения к эндпоинту и проверки необработанного ответа до написания какого-либо кода.
• Postman. Не язык, но незаменим для ручного изучения и тестирования API, формирования запросов и чтения ответов перед автоматизацией.

В случае с публичным API работа часто сводится к одному хорошо сформированному запросу. Приведённая ниже форма, это всё, что нужно для получения JSON листинга магазина перед любым парсингом:

# Apple's public app lookup returns listing metadata as JSON
curl "https://itunes.apple.com/lookup?id=APP_ID"

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

Почему прокси здесь важны

Сбор листингов магазинов и публичных эндпоинтов в реальных объёмах сталкивается с теми же защитными механизмами, что и веб-парсинг. Отправляйте слишком много запросов с одного адреса, и вы получите ограничение скорости или блокировку, а некоторые источники варьируют то, что возвращают, в зависимости от региона. Прокси решают обе проблемы. Ротирующиеся резидентные или мобильные IP распределяют ваши запросы по множеству адресов, чтобы ни один не превысил лимит, а геотаргетированные IP позволяют видеть региональные листинги и цены так, как их видит местный пользователь. Поскольку много контента приложений обслуживается мобильным клиентам, мобильные IP в частности могут лучше соответствовать ожидаемому профилю трафика по сравнению с диапазонами дата-центров. Наше руководство о парсинге без блокировок подробнее рассматривает ротацию и дисциплину запросов.

Зачем команды парсят данные мобильных приложений

Мотивация та же, что и при веб-парсинге: данные внутри и вокруг приложений являются окном в рынок. Несколько наиболее распространённых причин, по которым команды их собирают:

• Конкурентный анализ. Электронная коммерция и другие бренды отслеживают листинги приложений конкурентов, чтобы следить за ценами, позиционированием и эволюцией интерфейса, что информирует их собственные продуктовые и рыночные решения.
• Ценовая разведка. Ценообразование является основным рычагом дохода, и наблюдение за ценами, которые устанавливает отрасль в приложениях и листингах, помогает команде устанавливать свои собственные. Наша заметка о веб-парсинге для ценовой разведки охватывает эту дисциплину.
• Транспорт и навигация. Данные общественного транспорта, трафика и сервисов совместных поездок питают навигационные инструменты, оптимизацию маршрутов и другие услуги на основе местоположения.
• Финансовые сигналы. Новости рынка в реальном времени и публичные финансовые данные поддерживают более качественные и быстрые инвестиционные и стратегические решения.
• Недвижимость. Публичные листинги недвижимости, ставки и данные о жилье, собранные в масштабе, экономят часы ручного просмотра в ходе исследования.
• Анализ цифрового присутствия. Агрегирование публичного присутствия конкурента в веб и социальных сетях создаёт картину того, что они делают и где вы можете сделать лучше.

Сложности сбора данных мобильных приложений

Даже когда вы ограничиваетесь публичными источниками, эта работа сопряжена с реальными препятствиями. Знание их заранее убережёт проект от проблем.

• Условия использования. Большинство приложений и стоящие за ними сайты публикуют условия, регулирующие то, что пользователи могут делать с их данными. Изучайте их перед сбором, поскольку их игнорирование может создать юридические риски.
• Законодательство о конфиденциальности. Правила защиты данных, такие как GDPR и CCPA, применяются всякий раз, когда задействованы персональные данные. Знайте, какие законы охватывают ваши данные и юрисдикцию, и соблюдайте политики использования данных каждого источника.
• Интеллектуальная собственность и авторское право. Контент листинга, изображения и собственные материалы могут быть защищены. Не распространяйте материалы, защищённые авторским правом, и относитесь к данным другой стороны как к её собственности.
• Защита от парсинга. Ограничение скорости, CAPTCHA и обнаружение ботов защищают многие источники. Уважайте их, а не стремитесь обойти, и поддерживайте разумную скорость запросов.
• Шифрование и защита приложений. Как описано выше, зашифрованный и привязанный к сертификатам трафик делает чтение внутри приложения непрактичным, что является основной причиной, по которой публичные листинги и API являются лучшей целью.
• Отраслевое регулирование. Чувствительные отрасли, такие как финансы и азартные игры, более жёстко ограничивают сбор данных. Проверяйте правила для отрасли, с которой вы работаете, прежде чем начать.

Ответственный парсинг

Данные мобильных приложений требуют особой осторожности, поскольку многое из того, с чем работают приложения, является персональным. Ограничивайтесь только публичными данными: публичные метаданные магазина, такие как название, рейтинг, категория, цена и агрегированное количество отзывов, допустимы, но содержимое отдельных рецензентов и всё, что идентифицирует человека, следует рассматривать как персональные данные, агрегировать, а не профилировать, и обрабатывать в соответствии с применимыми законами о конфиденциальности. Всегда предпочитайте официальный API при его наличии, поскольку он создан для этой цели и позволяет оставаться в рамках правил провайдера. Соблюдайте условия использования и robots.txt каждого источника, поддерживайте разумную скорость запросов, чтобы не нагружать сервис, и никогда не распространяйте контент, защищённый авторским правом. Собранные с такой дисциплиной публичные данные приложений являются законным и ценным ресурсом; собранные небрежно, они становятся источником ответственности.

Часто задаваемые вопросы

Можно ли парсить данные непосредственно из мобильного приложения?

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

Каков лучший способ получить данные мобильных приложений?

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

Почему не просто перехватить сетевой трафик приложения?

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

Нужны ли прокси для сбора данных приложений?

Для чего угодно, кроме нескольких запросов, да. Сбор листингов магазинов и публичных эндпоинтов в объёме вызывает ограничение скорости и блокировки с одного IP, а некоторые источники варьируют результаты в зависимости от региона. Ротирующиеся резидентные или мобильные IP распределяют запросы по множеству адресов, предотвращая блокировки, а геотаргетированные IP позволяют видеть региональные листинги и цены, которые видит местный пользователь.

Какой язык программирования лучше всего подходит для парсинга данных приложений?

Любой популярный подойдёт, поэтому выбирайте то, что знает ваша команда. Python наиболее распространён: Requests, BeautifulSoup, Scrapy и Selenium. Node.js подходит для JSON API с Axios или Fetch API, а Ruby, PHP, Java и простой cURL справляются с HTTP-работой. Логика сбора данных та же веб-парсинговая логика независимо от языка.

Законно ли парсить данные мобильных приложений?

Зависит от того, что вы собираете и как. Публичные, неперсональные метаданные, такие как названия приложений, рейтинги, категории и цены, как правило, несут меньший риск, но вы должны соблюдать условия использования каждого источника, соблюдать авторское право и интеллектуальную собственность, а также следовать законам о конфиденциальности, таким как GDPR и CCPA, при наличии персональных данных. Предпочитайте официальные API, агрегируйте любые персональные данные и ограничивайте сбор публичными источниками. В случае сомнений обратитесь за юридической консультацией для вашего конкретного случая использования.

FQ

Farah Qadeer

Специалист по визуализации контента · Crawlbase

Специалист по визуализации контента в Crawlbase, превращает сложные темы прокси и веб-скрейпинга в понятные визуализации и пошаговые руководства.