Комментарии 42
Есть ли возможность получать несколько изображений товара через API?
Очень хотелось бы список рекомендаций к переданному товару. Но, я так понимаю, это уже другая история, не к вам.
Эх, если бы мы умели сейчас делать рекомендации! Вот интересно, а что для Вас качественная рекомендация?
- Похожий по названию товар;
- Товар, который смотрели вместе данным товаром;
- Похожий по фото товар;
- Схожий по параметрам (категория, цвет, цена, какие-то meta-теги);
- Товар, который покупают вместе в данным товаром.
Попробуйте REES46 (ни какого отношения лично к данному сервису не имею). Имхо, лучше использовать под каждую задачу специализированное ПО. Парсинг должен оставаться парсингом.
Парсинг продукта заключается в парсинге микроразметки?
Микроразметка — только один множества используемых сигналов.
Если быть точным, то у нас сейчас 8 слоёв, которые анализируются на наличие и качество eCommerce данных. Строим планы на 9-й — визуальный, основанный на машинном зрении.
Машинное зрение для парсинга? У меня тут 4 десятка парсеров магазинов на простых регулярках с куда большим количеством информации. Иногда что-то ломается вместе с версткой, конечно, но чинить раз в полгода, ИМХО, явно проще, чем машинное зрение использовать для этого)
Ваш подход имеет право на жизнь, но для реализации нужных нам функций пришлось отказаться от заданных вручную паттернов, хотя именно с них мы и начинали.
Что касается объема извлекаемой информации, нам были нужны только название, цена и изображение товара. По мере надобности добавляем новые параметры: бренд и категорию, например. Будем развивать API и дальше по мере появления новых потребностей пользователей.
Напомню, Вы решаете задачу парсинга конкретного сайта, а мы — автоматического парсинга любого сайта. Интернет пестрит предложениями «купить парсер avito.ru или ikea.com», написать парсер для сайта и т.д. Мы даём API, которое сразу работает с любым магазином.
Что касается объема извлекаемой информации, нам были нужны только название, цена и изображение товара. По мере надобности добавляем новые параметры: бренд и категорию, например. Будем развивать API и дальше по мере появления новых потребностей пользователей.
Напомню, Вы решаете задачу парсинга конкретного сайта, а мы — автоматического парсинга любого сайта. Интернет пестрит предложениями «купить парсер avito.ru или ikea.com», написать парсер для сайта и т.д. Мы даём API, которое сразу работает с любым магазином.
Вы решаете задачу парсинга конкретного сайта, а мы — автоматического парсинга любого сайтаНе конкретного, а очень многих конкретных (да и решил уже давно, а не решаю) :)
Как делать — решать вам, конечно же. Я просто выразил мысль, что в итоге затраченные усилия получатся куда выше, нежели у ручных паттернов (которые можно не трогать годами), а конечный пользователь разницы все равно не заметит
За мнение — спасибо. Но у нас кончилось терпение на 200-м сайте магазина заниматься этим рукоблудием. Сейчас парсим 5822 магазина. Мы бы повесились вручную паттерны делать.
Да и когда повалил народ и стал добавлять такие магазины со скоростью 20 новых в минуту, да ещё такие о которых мы не знали, поняли, что либо юзеры утекут, т.к. подумают, что приложение не работает, либо нужно делать механизм, который с высокой вероятностью будет парсить нужные нам данные в любом интернет-магазине.
Да и когда повалил народ и стал добавлять такие магазины со скоростью 20 новых в минуту, да ещё такие о которых мы не знали, поняли, что либо юзеры утекут, т.к. подумают, что приложение не работает, либо нужно делать механизм, который с высокой вероятностью будет парсить нужные нам данные в любом интернет-магазине.
А никто не говорит вручную писать ;)
Лично я делал довольно просто — автоматическое выделение значимых подстрок слева и справа от каждого парсящегося параметра таким образом, чтобы остальные ссылки с того же магазина подходили под паттерн (в итоге получилась всего сотня-другая строк на все случаи жизни)
Единственный минус такого подхода — для каждого парсера нужен тот самый пример (а иногда и несколько), на основе которого паттерн выделяется. К счастью, многие магазины предоставляют их метой для поисковых систем, они выделяются у всех абсолютно одинаково, то есть нужен просто еще один скрипт
Правда, у меня не было нужды парсить прямо тысячи сайтов, товары там искались очень нишевые, так что на большой выборке метод не проверял
Лично я делал довольно просто — автоматическое выделение значимых подстрок слева и справа от каждого парсящегося параметра таким образом, чтобы остальные ссылки с того же магазина подходили под паттерн (в итоге получилась всего сотня-другая строк на все случаи жизни)
Единственный минус такого подхода — для каждого парсера нужен тот самый пример (а иногда и несколько), на основе которого паттерн выделяется. К счастью, многие магазины предоставляют их метой для поисковых систем, они выделяются у всех абсолютно одинаково, то есть нужен просто еще один скрипт
Правда, у меня не было нужды парсить прямо тысячи сайтов, товары там искались очень нишевые, так что на большой выборке метод не проверял
Честно говоря, так и не понял смысла…
Заранее прошу прощения за мой Python, уже подзабыл.
Немного питона
#!/usr/bin/env python3
import urllib.request
from lxml import etree
def main():
u = urllib.request.urlopen("http://www.lamoda.ru/p/ug174awohj47/shoes-uggaustralia-uggi/")
data = u.read()
u.close()
tree = etree.HTML(data)
name = tree.xpath('//h1[@class="heading_m ii-product__title"]/text()')
price = tree.xpath('//div[@class="ii-product__price-current"]/text()')
manufacturer = tree.xpath('//a[@class="ii-product__brand-text ii-link_primary"]/text()')
print(name[0])
print(price[0])
print(manufacturer[0])
if __name__ == '__main__':
main()
Заранее прошу прощения за мой Python, уже подзабыл.
Когда нужно парсить данные только нескольких магазинов, то Вы правы, можно делать самому. Ну и не будем лукавить, Вы понимаете суть задачи, а кто-то из разработчиков может не понимать, не хотеть разбираться или просто жалеть времени (не почасовая оплата у него).
Кстати, у Вас паттенр вручную задан, а Product API сам находит паттерн, поэтому и работает с любым магазином без настройки. Это главное отличие. На рынке полно парсеров, которые нужно настраивать — разумеется это скучно.
Кстати, у Вас паттенр вручную задан, а Product API сам находит паттерн, поэтому и работает с любым магазином без настройки. Это главное отличие. На рынке полно парсеров, которые нужно настраивать — разумеется это скучно.
Еще, смысл все-таки в постановке задачи. Если требуется парсить пару конкретных магазинов, то вариант сесть и написать скрипт с жёстко заданными шаблонами годится. Выше я уже написал что мы работаем с несколькими слоями данных а шаблоны и микроформаты всего лишь только 2 из 8.
Удобство Product API именно в автоматическом получении данных из магазинов, о которых ни вы, ни система ничего раньше не знали и которые еще норовят дизайн менять периодически. Как только количество магазинов, которые нужно обрабатывать, увеличится со 100 до хотя бы 500, ручной вариант, предложенный Вами, уже не будет работать — мы это проходили.
У нас сейчас добавлены товары из 5807 магазинов о большинстве которых я никогда не слышал, а пользователи, оказывается, там покупают.
Удобство Product API именно в автоматическом получении данных из магазинов, о которых ни вы, ни система ничего раньше не знали и которые еще норовят дизайн менять периодически. Как только количество магазинов, которые нужно обрабатывать, увеличится со 100 до хотя бы 500, ручной вариант, предложенный Вами, уже не будет работать — мы это проходили.
У нас сейчас добавлены товары из 5807 магазинов о большинстве которых я никогда не слышал, а пользователи, оказывается, там покупают.
НЛО прилетело и опубликовало эту надпись здесь
Интересует порядок цен.
пока не увидел практической пользы, кроме создания сайтов арбитражников с товаром и партнерcкими ссылками на wildberries и lamoda.
Через ваш api, увы, нельзя сравнить стоимость одного и того же товара на lamoda, wildberries и фирменного магазина
Для сайтов-витрин есть способ проще — XML выгрузки из партнёрских сетей. Быстрее и лучше работает. Вот только партнёрская программа есть у 1%-2% магазинов.
Вы правы, сравнивать цены нельзя, но мы и не ставили себе такую задачу.
Если Вы настроены серьезно, я могу написать в личку как минимум 9 кейсов, где Product API будет полезен и на которых Вы, как разработчик, сможете зарабатывать. Но только если Вы реально интересуетесь.
Вы правы, сравнивать цены нельзя, но мы и не ставили себе такую задачу.
Если Вы настроены серьезно, я могу написать в личку как минимум 9 кейсов, где Product API будет полезен и на которых Вы, как разработчик, сможете зарабатывать. Но только если Вы реально интересуетесь.
Почему нет описаний и т.п.? Почему только один товар?
Он неплохо берет мои магазины. Но это логично, ведь у меня и микроразметка, и нормальная семантическая HTML5. Но вот на разделе категории он засыпался. Почему? Взять кучу цен прямо из категории это самое разумное, чем дергать 100500 страниц товара. Тем более что инфы вы даете мизер, она есть и в категории. Конечно хорошо было бы чтобы еще и по пагинации ходили (опционально конечно), но в целом не ясная ситуация…
ПС: и да, где цены? Одно дело если цена будет символическая, другое дело если соизмеримо с Яндекс.Маркетом (или другими АПИ которые можно и тыренные покупать у парсящих).
Он неплохо берет мои магазины. Но это логично, ведь у меня и микроразметка, и нормальная семантическая HTML5. Но вот на разделе категории он засыпался. Почему? Взять кучу цен прямо из категории это самое разумное, чем дергать 100500 страниц товара. Тем более что инфы вы даете мизер, она есть и в категории. Конечно хорошо было бы чтобы еще и по пагинации ходили (опционально конечно), но в целом не ясная ситуация…
ПС: и да, где цены? Одно дело если цена будет символическая, другое дело если соизмеримо с Яндекс.Маркетом (или другими АПИ которые можно и тыренные покупать у парсящих).
Вы описали краулер (ходит по URL), а у нас парсер (извлекает данные по URL). В интернете полно краулеров, которые могу начиная с главной пройти по всему дереву сайта, но вот URL для обработки они будут отправлять на Product API.
Что касается описаний товара, то нам эти данные были не нужны. Если окажется, что они будут полезны пользователям API, то будем и их извлекать.
Что касается описаний товара, то нам эти данные были не нужны. Если окажется, что они будут полезны пользователям API, то будем и их извлекать.
Т.е. это нормальный вариант использования вашего API?: свой краулинг 100500 страниц с товарами какого-то одного магазина с 100500 запросами в Ваш API, сохранение данных в свою базу, и повторить для других магазинов?
Или это прямой путь в Ваш черный список?
Или это прямой путь в Ваш черный список?
Вы описали вполне жизненный кейс использования API. Наша забота — взять данные о товаре по URL, сколько таких запросов и из каких магазинов будут эти URL дело Ваше. Мы парсим данные и следим, чтоб магазины не банили.
Если будет спрос, то сделаем модификатор запроса не только на получение данных о товаре, но и отправку уведомления об изменении его цены в будущем на указанный callback_url.
Если будет спрос, то сделаем модификатор запроса не только на получение данных о товаре, но и отправку уведомления об изменении его цены в будущем на указанный callback_url.
Как раз не жизненный кейс. Потому категории каталога и постраничку нужно так же парсить (сталкивался с вариантами где это была довольно нетривильная задача). А если у меня есть краулер, парсер, то зачем тогда Product API? При наличии такой инфраструктуры дописать парсинг товара уже не составляет труда. Работать нужно над полностью готовой услугой «скачать и мониторить весь каталог». Ваш клиент не разработчики. Кто в теме у того уже есть свои наработки. Ваш клиент — не технические спецы либо техспецы начального/среднего уровня которые в лучше случае кое как смогут интегрировать данные парсинга с некой другой системой.
Забыли еще «у которых есть пул IP», чтобы не банили.
Ведь для краулинга он нужен не меньше, а то и больше чем для разбора товаров.
Ведь для краулинга он нужен не меньше, а то и больше чем для разбора товаров.
Мы предоставляем API для тех, кто хочет делать сервисы для не технических специалистов. Кому нужно встроить функции парсинга данных или слежения за ценой в свои продукты. Мы не очередной парсер Яндекс.Маркета, у Product API проста функция по любому URL товара выдать информацию.
Если заказчик просит обработать конкретный сайт, то шаблон лучшее решение. А если нужно с уверенностью получить данные с любого интернет-магазина в любой стране, то без нашей технологии не обойтись.
Если заказчик просит обработать конкретный сайт, то шаблон лучшее решение. А если нужно с уверенностью получить данные с любого интернет-магазина в любой стране, то без нашей технологии не обойтись.
Ребят, небольшая ошибка на странице API
Prodcut API от Fetchee предоставляет стартапам и компаниям надёжный инструмент для парсинга товаров интернет-магазинов.
Prodcut API от Fetchee предоставляет стартапам и компаниям надёжный инструмент для парсинга товаров интернет-магазинов.
Вы описали краулер (ходит по URL), а у нас парсер (извлекает данные по URL). В интернете полно краулеров, которые могу начиная с главной пройти по всему дереву сайта, но вот URL для обработки они будут отправлять на Product API.
Не-не-не. Никуда ходить не надо.
Всёуже украдено до нас :)
На странице категории УЖЕ ЕСТЬ информация по 20 товарам. Вы предлагаете мне скачивать эту страницу, брать из нее ссылки (как? все равно ведь разбирать страницу как-то). отбрасывать название товара, цену и т.п.
А потом 20 раз дергать ваш АПИ, чтобы получить информацию которая и так была в категории (в 99.99% магазинов у категории инфы по товаром больше чем вы берете с карточки). Это не только мне глупо — это и вам глупо. В 20 раз больше запросов, больше трафа, больше банов IP, выше себестоимость, выше цена для клиента, меньше клиентов…
Не хотите ходить по пагинации — не ходите.
Но не разбирать категорию это просто глупо.
Ну и вернуть ссылки которые предположительно являются пагинацией — тоже не сложно.
Их буквально с пяток шаблонов.
А так то без цен изучать смысла нет никакого.
Возьмите отсюда уже готовые данные парсинга https://xmldatafeed.com — много бесплатного.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример использования Product API от Fetchee для парсинга товаров интернет-магазина