Parser olx.pl.Olx.ua. Auto.ria
Tutaj nie ma co więcej dodać.
Potrzebny parser Olx.pl i Olx.ua
Później jeszcze kilka krajów olx.
Zazwyczaj są identyczne.
Istota -
Wybieramy parametry w wyszukiwarce. Kopiujemy link. Wklejamy. Parsujemy.
Dane, które trzeba zbierać - to numer telefonu i miejscowość.
Dane wyprowadzać do Exela
Budżet: 3000 UAH Termin: 5 dni
Dzień dobry. Już mam gotowy parser dla ukraińskiej strony, bez problemu dostosuję go również do polskiej. Sprzedawałem ukraiński za 3500, gotowy sprzedać oba za podaną cenę. Będę zadowolony ze współpracy
Budżet: 3500 UAH Termin: 3 dni
Dzień dobry, Romanie!
Zrobię w ciągu dnia! Na Pythonie!
Mam duże doświadczenie w parsowaniu danych, będę używać bs4
Budżet: 2000 UAH Termin: 2 dni
Dzień dobry, Roman!
Będę w stanie opracować taki parser, mam duże doświadczenie z podobnymi parserami!
Napiszę w Pythonie! Zrobię wszystko bardzo starannie, mogę zrobić exe lub wrzucić na serwer!
Będę w stanie wspierać parser w przyszłości, mogę obejść captcha i opracowywać przyszłe parsery
Budżet: 3500 UAH Termin: 2 dni
Dzień dobry.
Mogę stworzyć rozszerzenie chrome, które będzie zbierać dane i zawieszać je w Google Arkuszach.
Budżet: 1200 UAH Termin: 3 dni
Dzień dobry.
Gotowy do wykonania za pomocą ZennoPoster. Doświadczenie ponad 4 lata
Budżet: 2500 UAH Termin: 2 dni
Witaj, mam już realizację parsera olx z parsowaniem wszystkich ogłoszeń według kategorii i danych samych ogłoszeń, może pracować z proxy, jeśli jesteś zainteresowany - pisz, omówimy 🤝
Budżet: 4000 UAH Termin: 3 dni
Dzień dobry. Z radością jestem gotowa pomóc. Proponuję omówić szczegóły w wiadomościach prywatnych.
Będę zadowolona ze współpracy!
Budżet: 1500 UAH Termin: 2 dni
Dzień dobry, wykonywałem już podobne zadanie, więc mam doświadczenie w tej dziedzinie, są też opinie (możecie je przejrzeć). Wykonam szybko, praktycznie, jakościowo.
Skontaktujmy się z wami w celu pomyślnej realizacji tego projektu.
Zawsze w kontakcie!
Budżet: 1000 UAH Termin: 1 dzień
Dzień dobry. Jest gotowy parser dla autorii. przeszukuje całą stronę w ciągu dwóch dni, zbiera ponad 300k zapisów.
Budżet: 1000 UAH Termin: 2 dni
Dzień dobry, wykonam twoje zadanie szybko i jakościowo!
Doświadczenie w pracy ponad dwa lata.
Budżet: 2000 UAH Termin: 3 dni
Cześć! Twój projekt przykuł moją uwagę. Jestem gotów zacząć pracę i zapewnić wysoką jakość wykonania.
Budżet: 1000 UAH Termin: 1 dzień
Dzień dobry
już robiłem podobny projekt, pisz na priv, omówimy szczegóły
cena i terminy po omówieniu szczegółów
Budżet: 20000 UAH Termin: 1 dzień
Dzień dobry!
Jestem gotów pomóc w realizacji tego projektu.
Z niecierpliwością czekam na możliwość wyjaśnienia wszystkich szczegółów i rozpoczęcia nad nim pracy!
Budżet: 16000 UAH Termin: 1 dzień
Dzień dobry,
Jestem gotów zająć się Państwa projektem. Mam doświadczenie w automatyzacji procesu zbierania danych z różnych stron, w tym Olx.pl i Olx.ua. Opracuję parser do wyboru parametrów wyszukiwania, kopiowania linków, parsowania i uzyskiwania danych o numerze telefonu i miejscowości. Wynik przedstawię w formacie Excel.
Moja stawka to 16$ za godzinę. Będę zadowolony, aby rozpocząć pracę nad tym projektem.
Z poważaniem,
Maksym
Budżet: 1000 UAH Termin: 2 dni
Dzień dobry, zainteresował mnie Państwa projekt, mam rozwiązanie dla autorii, dla olx będzie trudniej z numerami. Proszę o kontakt
Dzień dobry! Należy wykonać dwa zadania: 1. Opracować parser produktów z zewnętrznej strony (10–40 tys. pozycji, marketplace) z zachowaniem zorganizowanych danych w MySQL do późniejszego wyświetlenia w WordPressie. 2. Zainstalować i skonfigurować n8n na VPS, a także zorganizować przetwarzanie treści AI: konfiguracja promptów, przeredagowanie tekstów, przetwarzanie obrazów, optymalizacja SEO i sprawdzanie tekstów pod kątem detekcji AI. Można oszacować koszt realizacji zarówno całego projektu, jak i każdego zadania osobno. .
Trzeba wykonać parsowanie z kanałów Viber (Łączna liczba - 49 kanałów, około 80 tys. subskrybentów).
Dla istniejącego systemu mikroserwisowego wymagana jest opracowanie niezależnej usługi do przetwarzania plików Excel. Zadanie polega na stworzeniu niezawodnego procesu przyjmowania, walidacji i transformacji danych z tabel do zorganizowanego formatu bazy danych. Funkcjonalne zadania: Opracowanie API opartego na gRPC do odbierania poleceń przetwarzania i zwracania statusów wykonania. Realizacja logiki parsowania plików: odczyt dużych ilości danych (XLSX), czyszczenie, sprawdzanie typów i przekształcanie do modeli biznesowych. Realizacja warstwy dostępu do danych (Repository/Unit of Work) do zapisywania wyników w PostgreSQL za pomocą Entity Framework Core. Zapewnienie bezpieczeństwa wątków i efektywnego wykorzystania zasobów (szczególnie przy przetwarzaniu dużych plików). Wymagania techniczne: Platforma: .NET 10. Wzorce architektoniczne: Dependency Injection, CQRS, modułowa architektura projektu. Komunikacja: Wyłącznie gRPC. Praca z Excelem: Wykorzystanie wydajnych bibliotek (np. EPPlus, OpenXML lub analogi według wyboru). Modularność: Kod powinien być zorganizowany w sposób umożliwiający łatwe skalowanie usługi i testowanie. Oczekiwany rezultat: W pełni działający mikroserwis, gotowy do wdrożenia w środowisku kontenerowym. Czysta baza kodu z przestrzeganiem zasad SOLID. Udokumentowane pliki .proto. Podstawowe testy jednostkowe dla krytycznych punktów przetwarzania danych. Wymagania dla kandydata: W odpowiedzi proszę podać: Twoje doświadczenie w pracy z .NET w architekturze mikroserwisowej. Przykłady tego, jak organizujesz DI i modularność w swoich projektach. Doświadczenie w pracy z bibliotekami Excel w .NET. Gotowość do pracy na podstawie kontraktów gRPC.
Dzień dobry. Potrzebny parser według słów kluczowych z wyświetlaniem wyników przez bota Telegram. Jak to ma działać: Automatyczne wyszukiwanie na 4 stronach według słów kluczowych, które czasami się zmieniają. Zapytania są wysyłane co kilka minut. Słowa są ładowane w formie pliku .txt. TG powinien zawierać przyciski: uruchom bota, zatrzymaj bota, pobierz plik (pobiera plik z aktualnymi słowami kluczowymi), załaduj plik (ładuje edytowany plik z nowymi słowami). Bots powinien ignorować wcześniej znalezione wyniki, tzn. nie wskazuje tego samego ogłoszenia dwa razy. Wynik przychodzi do bota w formie linku z zdjęciem, ale wystarczy też sam link. P.S. wyszukiwanie na stronach bez API, VPS na 6TB i 50 IP już są dostępne. Po szczegółowe informacje proszę kontaktować się na PW.
Zadanie: jeden dashboard ze wszystkimi wskaźnikami biznesowymi — reklama, lejek, płatności, praca menedżerów, planowanie przychodu. Dane są pobierane automatycznie przez API. Zakres: tylko kierunek YCL (zatrudnienie w Europie). W Kommo są też inne kierunki — do magazynu trafiają tylko transakcje z lejek YCL (filtr według lejka/tagu ustalimy).1. Źródła danych (integracje) Kommo CRM — leady, transakcje, etapy lejka, odpowiedzialni, źródła, daty przejść między etapami (koniecznie zachować historię), przyczyny odmowy, pola niestandardowe transakcji (patrz p. 2). Stripe — płatności, kwoty, statusy (sukces/odmowa/zwrot), powiązanie z transakcją. Meta Ads — wydatki, wyświetlenia, kliknięcia, CPL, leady według kampanii (działa teraz). Google Ads, Reddit Ads, LinkedIn Ads — planowane; architektura — rozszerzalne konektory bez przeróbek rdzenia. SEO/organika— Google Search Console + GA4. Przeszły związek: źródło ruchu → lead w Kommo → płatność w Stripe (UTM, ID transakcji w metadanych Stripe — mechanikę zaproponować). 2. Obowiązkowe przekroje (pola transakcji w Kommo) Każda metryka musi być filtrowana/grupowana według: Obywatelstwo klienta (Kenia, Nigeria, Indie itp.). Status pobytu: mieszka w swoim kraju / ekspat (już przebywa w Europie). To dwa różne segmenty z różnym cyklem, konwersją i wartością transakcji. Kraj umiejscowienia / usługa: Polska, Serbia, Słowacja, Niemcy (ZAV). Menedżer, zespół, kanał ruchu, okres. Jeśli jakichś pól w Kommo brakuje — wykonawca wskazuje, jakie pola należy dodać, zamawiający dodaje.3. Lejek i wskaźniki wyprzedzające Dane w przekroju lejka, dla każdego etapu — podsumowujące i wyprzedzające (leading) metryki: Ruch → lead: leady, CPL według kanałów + dynamika wydatków/kliknięć dzień do dnia. Lead → kwalifikacja: konwersja + czas pierwszej odpowiedzi, kontakty/telefony do menedżera dziennie, leady bez odpowiedzi. Kwalifikacja → umowa/faktura: konwersja + wysłane oferty, zawieszone transakcje (dni na etapie powyżej normy). Faktura → płatność: płatności, średnia wartość transakcji + niezapłacone faktury, nieudane płatności. Podsumowanie: przychód, ROMI według kanałów, run rate do planu miesiąca. 4. Cykl transakcji Średni i medianowy cykl lead → płatność (punkt odniesienia biznesu ~4 tygodnie), trend cyklu w czasie. Rozkład cyklu według etapów (ile dni transakcja spędza na każdym etapie) — aby zobaczyć, który etap się wydłuża. Lista transakcji, które utknęły na etapie dłużej niż norma. Przekrój cyklu według segmentów: obywatelstwo, status pobytu, kraj umiejscowienia, menedżer. 5. Wczesne ostrzeżenie o spadku (kluczowy blok) Ponieważ cykl ~4 tygodnie, dzisiejsze leady = płatności za miesiąc. System powinien: Porównywać leady/kwalifikacje bieżącego tygodnia z średnią ruchomą (4 tygodnie) i przy odchyleniu w dół wydawać alert: „leadów −X%, przy cyklu 4 tygodnie oczekuj spadku płatności w tygodniu [daty]”. Budować prognozę płatności na 4 tygodnie do przodu z bieżącego pipeline'u: transakcje na każdym etapie × historyczna konwersja etapu × pozostały cykl. Podświetlać na czerwono tygodnie, gdzie prognoza jest niższa od planu — z zapasem czasu na reakcję. 6. Dopłaty i planowanie sprzedaży W karcie transakcji Kommo przechowywane są data i kwota planowanej dopłaty. System powinien: Zbierać kalendarz przyszłych dopłat: całkowita liczba oczekiwanych, według tygodni/miesięcy. Podświetlać przeterminowane dopłaty (data minęła, brak płatności w Stripe) — osobna lista do dociśnięcia. Liczyć plan miesiąca jako: plan − już opłacone − dopłaty zgodnie z harmonogramem = ile nowych sprzedaży potrzebnych (w pieniądzach i w sztukach transakcji przy średniej wartości transakcji). Harmonogram według tygodni: dopłaty + prognoza nowych płatności w stosunku do tygodniowego planu. 7. Praca menedżerów Dzienny przekrój dla każdego menedżera: kontakty/telefony, rozmowy, wysłane oferty, płatności — dla każdego dnia osobno, z wykresem za okres. Postęp realizacji osobistego planu w porównaniu z tempem miesiąca (na przodzie / w tempie / w tyle). Benchmarking z kolegami. 8. Wizualizacja i role „Sygnalizatory” (zielony/żółty/czerwony) w kluczowych metrykach w odniesieniu do norm/planu; skale postępu; wykresy trendów; adaptacja do urządzeń mobilnych. Role: CEO — wszystko; ROP — cały lejek i menedżerowie; team lead — swój zespół; menedżer — swoje wskaźniki i pozycja w stosunku do kolegów. 9. Raporty i AI Automatyczne raporty według harmonogramu (codzienne podsumowanie, tygodniowy raport) w dashboardzie i/lub komunikatorze. Zapytania w dowolnej formie („jak zmienił się CPL z Meta w ciągu 2 tygodni?”) — LLM nad magazynem. Alerty w strefie czerwonej oraz według zasad z p. 5–6. 10. Oczekiwania techniczne i etapowość Magazyn (PostgreSQL/BigQuery lub analog) + ETL: webhooks Kommo + okresowa synchronizacja (15–60 min). Frontend: niestandardowy lub narzędzie BI — zaproponować z uzasadnieniem; wymagania dotyczące ról, sygnalizatorów, prognoz i zapytań AI muszą być wykonalne. Etapy: (1) audyt i mapa metryk → (2) MVP: Kommo + Stripe + Meta, lejek, sygnalizatory, role → (3) cykl transakcji, wczesne ostrzeżenie, dopłaty i plan → (4) SEO, raporty AI, alerty → (5) nowe kanały reklamowe. Płatność etapowa, po każdym etapie — demo. W odpowiedzi proszę wskazać: podobne projekty (analiza przeszła), stack z uzasadnieniem, oszacowanie czasów i kosztów według etapów, miesięczny koszt posiadania (hosting, tokeny, licencje).