Парсінг фото з Instagram
Зроблено складний парсінг з закритого каналу Instagram.
Задача, з якою далеко не всі зможуть справлятися, зроблена на відмінно.
Я рекомендую .
Я збираюся звертатися до Ніки.
Щасливо врятуйте!!!І!
Уважаемые фрилансеры, я очень ценю ваше и свое время, но с этим парсингом меня пытались дважды кинуть на деньги. Типа переведи оплату, я все спарсил. А прислать спасенные фото никто не желает. Так со мной не сработает.
Заплачу сразу если пришлете архив с фотками.
Можете писать мне в телегу, но сначала архив с фотками, потом деньги.
Бюджет: 1500 RUB Термін: 1 день
Вітаємо Вас!
У нас є готове рішення, зробимо це швидко, напишіть ми обговорюємо!
Бюджет: 1500 RUB Термін: 1 день
Добрий день, готова виконати проект за 1 день.
Деталі можна обговорити в ЛС.
Бюджет: 1500 RUB Термін: 1 день
Вітаю, Сергій, без проблем збираю потрібну вам інформацію, маю великий досвід парсінга Instagram. Також я можу написати для вас парсер, яким ви зможете скористатися і парізувати інформацію, коли потрібно. Пишіть, ми все обговорюємо.
Бюджет: 1000 RUB Термін: 2 дні
Привітання, готові виконати Ваш замовлення! Збираючи інформацію і парсингом займався багато разів. В результаті відправляю архіви з усіма папками з фото та відео. За розрахунком термінів, то намагаюся зробити швидше. Дякуємо за увагу, не боліть
Для існуючої мікросервісної системи потрібно розробити незалежний сервіс-обробник 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) нові рекламні канали. Оплата поетапна, по кожному етапу — демо. У відгуку вказати: схожі проєкти (наскрізна аналітика), стек з обґрунтуванням, оцінку строків і вартості за етапами, щомісячну вартість володіння (хостинг, токени, ліцензії).
Потрібен спеціаліст для збору та структурування відкритої інформації про продавців з маркетплейсів. Необхідно визначити можливість автоматизованого збору даних та сформувати базу продавців. У відгуку, будь ласка, вкажіть: з якими маркетплейсами маєте досвід роботи; які дані можете отримати (назва продавця, посилання, категорії, рейтинг, кількість товарів, інші доступні поля); приклади подібних проєктів.
Потрібно створити 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. Посилання на лот.