Парсер объявлений из Android приложения

Задача: один дашборд со всеми показателями бизнеса — реклама, воронка, оплаты, работа менеджеров, планирование выручки. Данные подтягиваются по API автоматически. Периметр: только направление YCL (трудоустройство в Европе). В Kommo есть и другие направления — в хранилище попадают только сделки воронок YCL (фильтр по воронке/тегу согласуем).1. Источники данных (интеграции) Kommo CRM — лиды, сделки, этапы воронки, ответственные, источники, даты переходов между этапами (обязательно сохранять историю), причины отказов, кастомные поля сделки (см. п. 2). Stripe — платежи, суммы, статусы (успех/отказ/возврат), привязка к сделке. Meta Ads — расходы, показы, клики, CPL, лиды по кампаниям (работает сейчас). Google Ads, Reddit Ads, LinkedIn Ads — планируются; архитектура — расширяемые коннекторы без переработки ядра. SEO/органика— Google Search Console + GA4. Сквозная связь: источник трафика → лид в Kommo → оплата в Stripe (UTM, ID сделки в metadata Stripe — механику предложить). 2. Обязательные разрезы (поля сделки в Kommo) Каждая метрика должна фильтроваться/группироваться по: Гражданство клиента (Кения, Нигерия, Индия и т.д.). Статус проживания: живет в своей стране / экспат (уже находится в Европе). Это два разных сегмента с разным циклом, конверсией и чеком. Страна размещения / услуга: Польша, Сербия, Словакия, Германия (ZAV). Менеджер, команда, канал трафика, период. Если каких-то полей в Kommo нет — исполнитель указывает, какие поля нужно завести, заказчик добавляет.3. Воронка и опережающие показатели Данные в разрезе воронки, по каждому этапу — итоговые и опережающие (leading) метрики: Трафик → лид: лиды, CPL по каналам + динамика расходов/кликов день-до-дня. Лид → квалификация: конверсия + скорость первого ответа, касания/звонки на менеджера в день, лиды без ответа. Квалификация → договор/счет: конверсия + отправленные офферы, зависшие сделки (дней на этапе более нормы). Счет → оплата: оплаты, средний чек + неоплаченные счета, неудачные платежи. Итог: выручка, ROMI по каналам, run rate до плана месяца. 4. Цикл сделки Средний и медианный цикл лид → оплата (ориентир бизнеса ~4 недели), тренд цикла во времени. Разложение цикла по этапам (сколько дней сделка сидит на каждом этапе) — чтобы видеть, какой именно этап растягивается. Список сделок, что зависли на этапе дольше нормы. Разрез цикла по сегментам: гражданство, статус проживания, страна размещения, менеджер. 5. Раннее предупреждение просадки (ключевой блок) Поскольку цикл ~4 недели, сегодняшние лиды = оплаты через месяц. Система должна: Сравнивать лиды/квалификации текущей недели с скользящим средним (4 недели) и при отклонении вниз выдавать алерт: «лидов −X%, при цикле 4 недели ожидайте просадку оплат в неделю [даты]». Строить прогноз оплат на 4 недели вперед из текущего пайплайна: сделки на каждом этапе × историческая конверсия этапа × остаток цикла. Подсвечивать красным недели, где прогноз ниже плана, — с запасом времени на реакцию. 6. Доплаты и планирование продаж В карточке сделки Kommo хранятся дата и сумма запланированной доплаты. Система должна: Собирать календарь будущих доплат: тотал ожидаемых, по неделям/месяцам. Подсвечивать просроченные доплаты (дата прошла, оплат в Stripe нет) — отдельный список для доталкивания. Считать план месяца как: план − уже оплачено − доплаты по графику = сколько нужно новых продаж (в деньгах и в штуках сделок за средним чеком). График по неделям: доплаты + прогноз новых оплат против недельного плана. 7. Работа менеджеров Дневной срез по каждому менеджеру: касания/звонки, разговоры, отправленные офферы, оплаты — по каждому дню отдельно, с графиком за период. Прогресс выполнения личного плана с сравнением с темпом месяца (впереди / в темпе / отстает). Бенчмаркинг с коллегами. 8. Визуализация и роли «Светофоры» (зеленый/желтый/красный) в ключевых метриках относительно норм/плана; шкалы прогресса; графики трендов; адаптив под мобильный. Роли: CEO — все; РОП — вся воронка и менеджеры; тимлид — своя команда; менеджер — свои показатели и позиция относительно коллег. 9. Отчеты и AI Автоматические отчеты по расписанию (ежедневное сведение, недельный отчет) в дашборд и/или мессенджер. Запросы в свободной форме («как изменился CPL с Meta за 2 недели?») — LLM поверх хранилища. Алерты по красной зоне и по правилам из п. 5–6. 10. Технические ожидания и этапность Хранилище (PostgreSQL/BigQuery или аналог) + ETL: webhooks Kommo + периодическая синхронизация (15–60 мин). Фронтенд: кастомный или BI-инструмент — предложить с обоснованием; требования к ролям, светофорам, прогнозу и AI-запросам должны быть реализуемыми. Этапы: (1) аудит и карта метрик → (2) MVP: Kommo + Stripe + Meta, воронка, светофоры, роли → (3) цикл сделки, раннее предупреждение, доплаты и план → (4) SEO, AI-отчеты, алерты → (5) новые рекламные каналы. Оплата поэтапная, по каждому этапу — демо. В отзыве указать: похожие проекты (сквозная аналитика), стек с обоснованием, оценку сроков и стоимости по этапам, ежемесячную стоимость владения (хостинг, токены, лицензии).

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

Техническое задание Проект Настройка наполнения и синхронизации двух магазинов Prom.ua с поставщиками автозапчастей. Задача Необходимо реализовать загрузку и обновление товаров от поставщиков автозапчастей для двух интернет-магазинов на Prom.ua. ⸻ 1. Подключение поставщиков Необходимо подключить поставщиков через: API поставщика; XML, CSV, XLS прайс-листы; или другой доступный способ получения товаров с сайта поставщика. Важно обеспечить полную синхронизацию товаров между поставщиком и магазинами Prom.ua. ⸻ 2. Фильтрация и отбор товаров Необходимо реализовать возможность отбора товаров во время импорта по следующим параметрам: марка автомобиля; категория запчастей; подкатегория запчастей; другие доступные характеристики. Пример: Для каждого магазина должна быть возможность отдельно определять, какие категории товаров и какие марки автомобилей необходимо загружать. Дополнительные требования к отбору товаров Необходимо реализовать возможность отбора товаров во время импорта не только по маркам автомобилей и категориям запчастей, а также по статусу наличия товара. Должна быть возможность настроить такие сценарии: импортировать только товары, которые есть в наличии у поставщика; не импортировать товары со статусом "нет в наличии"; отключать или удалять товары с Prom.ua после исчезновения их из наличия у поставщика; Во время настройки прайсинга должна быть возможность комбинировать фильтры: по марке автомобиля; по категории запчастей; по подкатегории; по наличию товара. Пример: Импортировать только запчасти для Volkswagen и Audi, категория "Тормозная система", которые есть в наличии у поставщика. Также необходимо реализовать механизм предотвращения дублирования товаров от разных поставщиков. Если один и тот же товар присутствует у нескольких поставщиков, в каталог должен импортироваться только один запись товара. Критерии выбора товара при обнаружении дубликатов: приоритет отдается товару, который есть в наличии у поставщика; если товар есть в наличии у нескольких поставщиков, приоритет отдается товару с наименьшей ценой; если самый дешевый товар отсутствует в наличии, система должна выбрать самый дешевый товар среди тех, что есть в наличии; товары-дубликаты от других поставщиков не должны создавать отдельные позиции в каталоге. Пример: Импортировать только запчасти для Volkswagen и Audi, категория "Тормозная система", которые есть в наличии у поставщика. Если одна и та же запчасть доступна у нескольких поставщиков, в каталог импортируется только одна позиция — от поставщика с наименьшей ценой среди тех, у кого товар есть в наличии. ⸻ 3. Импорт карточек товаров Во время импорта должны автоматически загружаться: название товара; артикул; фотографии; описание товара; цена; характеристики товара; производитель; другие доступные параметры. ⸻ 4. обновление Необходимо настроить автоматическое: обновление цен при изменении от поставщика ⸻ 5. Удаление отсутствующих товаров Товары, которых больше нет в наличии у поставщика, должны: отключаться; или удаляться с Prom.ua (по согласованию). ⸻ 6. Наполнение магазинов Необходимо: создать структуру категорий; создать подкатегории; правильно распределить товары по категориям; проверить корректность импорта товаров. ⸻ 7. Результат работы После завершения работ должно быть: подключены поставщики; настроен импорт товаров; настроено обновление цен; настроено добавление новых товаров; настроено отключение или удаление отсутствующих товаров; магазины Prom.ua полностью наполнены и готовы к работе.

Необходимо создать Telegram-бота для автоматического поиска и мониторинга автомобилей "BUY IT NOW" на аукционах США (Copart, IAAI). Бот должен работать в автоматическом режиме и отправлять сообщения о новых автомобилях, которые соответствуют заданным фильтрам.Основной функционалНастройка фильтров: 1. Марка автомобиля; 2. Модель; 3. Год выпуска (от/до); 4. Тип топлива; 5. Объем двигателя; 6. Пробег; 7. Диапазон цены; Функции бота: 1. Автоматический мониторинг новых лотов; 2. Проверка обновлений каждые 1-2 минуты; 3. Защита от повторных уведомлений (антидубль); 4. Возможность добавлять и удалять фильтры через меню бота; 5. Сохранение настроек уже существующего поиска автомобилей. Формат сообщения: 1. Фото автомобиля (4-фото); 2. Название и номер лота; 3. Год выпуска; 4. Пробег; 5. Тип двигателя и объем; 6. Цена buy it now; 7. Ссылка на лот.

Спарсить полный каталог этих сайтов: https://svit-mebliv.ua/ https://kompanit.com.ua/ru https://amia.com.ua/ https://mebliromax.com.ua/ https://pehotin.com.ua/catalog/ https://www.sokme.ua/ru/ Все товары нужно объединить в одну обющую таблицу для импорта в WP. Каждый товар должен быть на двух языках (UA+RU). Также есть вариативные товары, это должно быть сохранено как вариации в базовом функционале WP Импорт на сайт возможен через плагины, так и кастомное решение, поэтому формат таблицы может обсуждаться