Парсер

Завдання: один дашборд з усіма показниками бізнесу — реклама, воронка, оплати, робота менеджерів, планування виручки. Дані підтягуються по 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 Імпорт на сайт можливий через плагіни, так і кастомне рішення, тому формат таблиці може обговорюватися