Парсер данных из тг каналов

Добрый день! Необходимо выполнить две задачи: 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) новые рекламные каналы. Оплата поэтапная, по каждому этапу — демо. В отзыве указать: похожие проекты (сквозная аналитика), стек с обоснованием, оценку сроков и стоимости по этапам, ежемесячную стоимость владения (хостинг, токены, лицензии).