Парсинг ОЛХ. Без номерів, але без необхідності режувати рахунки

Доброго дня! Необхідно виконати дві задачі: 1. Розробити парсер товарів з стороннього сайту (10–40 тис. позицій, маркетплейс) з збереженням структурованих даних у MySQL для подальшого виводу в WordPress. 2. Встановити та налаштувати n8n на VPS, а також організувати AI-обробку контенту: налаштування промптів, рерайт текстів, обробка зображень, SEO-оптимізацію та перевірку текстів на AI-детекцію. Можна оцінити вартість виконання як всього проекту, так і кожної задачі окремо. .

Потрібно виконати парсинг з каналів Вайбер (Загальна кількість - 49 каналів, близько 80 тис. підписників).

Для існуючої мікросервісної системи потрібно розробити незалежний сервіс-обробник Excel-файлів. Завдання полягає у створенні надійного конвеєра для прийому, валідації та трансформації даних з таблиць у структурований формат бази даних. Функціональні завдання: Розробка API на базі gRPC для отримання команд на обробку та повернення статусів виконання. Реалізація логіки парсингу файлів: читання великих обсягів даних (XLSX), очищення, перевірка типів та приведення до бізнес-моделей. Реалізація шару доступу до даних (Repository/Unit of Work) для збереження результатів у PostgreSQL через Entity Framework Core. Забезпечення потокобезпеки та ефективного використання ресурсів (особливо при обробці файлів великого розміру). Технічні вимоги: Платформа: .NET 10. Архітектурні патерни: Dependency Injection, CQRS, модульна архітектура проекту. Комунікація: Строго gRPC. Робота з Excel: Використання продуктивних бібліотек (наприклад, EPPlus, OpenXML або аналоги на вибір). Модульність: Код має бути організований так, щоб сервіс легко масштабувався і був придатний для тестування. Очікуваний результат: Повністю робочий мікросервіс, готовий до розгортання в контейнеризованому середовищі. Чиста кодова база з дотриманням принципів SOLID. Документовані .proto файли. Базові unit-тести для критичних вузлів обробки даних. Вимоги до кандидата:В відповіді, будь ласка, вкажіть: Ваш досвід роботи з .NET у мікросервісній архітектурі. Приклади того, як ви організовуєте DI та модульність у своїх проектах. Досвід роботи з Excel-бібліотеками в .NET. Готовність працювати за gRPC контрактами.

Доброго дня. Потрібен парсер за ключовими словами з виводом результатів через телеграм бота. Як це має працювати: Автоматичний пошук на 4 сайтах за ключовими словами, які час від часу змінюються. Пошукові запити надсилаються кожні кілька хвилин. Слова завантажуються у вигляді .txt файлу. ТГ має містити кнопки: запустити бота, зупинити бота, завантажити файл (завантажується файл з діючими ключовими словами), завантажити файл (завантажує відредагований файл з новими словами). Бот має ігнорувати раніше знайдені результати, тобто не вказує одне й те саме оголошення двічі. Результат приходить у бота у вигляді посилання з фото, але достатньо і просто посилання. P.S. пошук по сайтах без API, VPS на 6Тб і 50 IPs вже є. За детальною інформацією, будь ласка, звертайтеся в ЛС.

Завдання: один дашборд з усіма показниками бізнесу — реклама, воронка, оплати, робота менеджерів, планування виручки. Дані підтягуються по 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) нові рекламні канали. Оплата поетапна, по кожному етапу — демо. У відгуку вказати: схожі проєкти (наскрізна аналітика), стек з обґрунтуванням, оцінку строків і вартості за етапами, щомісячну вартість володіння (хостинг, токени, ліцензії).