尚未检测到更新。GitHub 发布版本后会显示在这里。
个人 GitHub 账号下公开仓库的所有者可以登录并验证所有权,自行管理介绍,无需管理员批准。
登录并生成验证文件,在 30 分钟内将其提交到此仓库的默认分支。其他分支或分叉仓库中的文件无效。然后在下方检查文件,即可无需管理员批准直接管理项目。请保留文件以维持管理权限。
如需登录,将前往登录页面。登录后请回到此处,再次点击所选的验证按钮。
在项目文件夹中运行 /nomorevibe verify,即可验证所有权并自行管理介绍。
一分钟完成验证制作者的介绍仅有上面的一句话。 更多详情请阅读仓库 README。 仓库 README ↗
正在加载完整 README。
查看完整 README ↗Rozwiązanie zadania rekrutacyjnego na stanowisko Head of B2C. Dane to dwa lata biznesu B2C (1.10.2024 – 30.09.2026), wygenerowane na potrzeby zadania.
Narzędzie: https://jakubgierasimiuk.github.io/kohorty-i-lejki/ — strona otwiera się w przeglądarce, bez instalacji i bez konta.
Repozytorium (ślad pracy): https://github.com/jakubgierasimiuk/kohorty-i-lejki
Nie: pacjentów przybywa, ale wracają rzadziej. Prawie cały przyrost pacjentów (86%) to pacjenci dwóch nowych kampanii na zwolnienie lekarskie (L4), w Mecie i w TikToku, a na ich pacjencie po koszcie pozyskania prawie nic nie zostaje: 7 zł w ciągu 180 dni wobec 30 zł na pacjencie pozostałych kampanii płatnych, a na pacjentach pozyskanych od wiosny 2026 szacunkowo wychodzimy na zero. Marża po wszystkich kosztach wzrosła o 27%, w 88% dzięki zakupom pacjentów pozyskanych w pierwszym roku. Pacjenci pozyskani w ostatnich 12 miesiącach zarobili w roku pozyskania, po kosztach kampanii, tylko o 3% więcej niż ci pozyskani rok wcześniej, choć było ich o 52% więcej.
Źródło pacjenta przypisujemy na dwa sposoby i w całym narzędziu nazywamy je tak samo. Pacjentów i retencję liczymy według pierwszego wejścia (pierwsze wejście pacjenta na stronę, a kod kampanii na pierwszym zamówieniu rozstrzyga). Według sesji z płatnością do innych kanałów trafia 2 081 pacjentów nowych kampanii: 1 918 weszło z ich reklamy, a zapłaciło w innej sesji, a 163 zapłaciło z kodem kampanii po wejściu z innego kanału. Bez nich obie reguły przypisania dają ten sam przyrost pacjentów, powrót i marżę. W ekonomii kampanii pokazujemy oba.
Ta sama lista stoi w narzędziu: w zakładce „Czy to wzrost” i w zasadach listy priorytetów (pozycje 1, 3 i 4 oraz pierwsze kroki pozycji 2, 5, 6, 8 i 11).
Lista priorytetów obejmuje działania wynikające z problemów widocznych w danych (naprawy, pauzy i testy), a celowo nie obejmuje działań na wzrost, które wymagają wiedzy spoza tych danych (nowe kanały i kampanie, rozwój oferty i TelemediGO poza naprawą warunków z pozycji 10, rozmowy z pacjentami); plan wzrostu przygotujemy po wynikach pierwszych testów (pozycje 7, 9 i 12).
Pełna odpowiedź, lista 12 priorytetów (wartość w marży, sposób pomiaru, czas wdrożenia) i lista niewiadomych z testami są w narzędziu, w zakładkach „Czy to wzrost”, „Priorytety” i „Czego nie wiemy”. Każda karta ma zwijane „Szczegóły” z liczebnościami, wynikiem według sesji z płatnością (druga reguła przypisania), metodą i źródłem liczb.
| Zakładka | Co pokazuje |
|---|---|
| Czy to wzrost | odpowiedź na pytanie zadania: werdykt z trzema linijkami (więcej pacjentów, lepsza retencja, więcej zarabiamy) i osiem kroków, każdy z pytaniem, odpowiedzią i tym, co znaczy dla biznesu: liczby z dashboardu, skąd są nowi pacjenci, czy wracają, ile zostaje na nowym pacjencie po koszcie pozyskania, skąd +27% marży, kierunek z kwartału na kwartał, co robimy (z decyzjami na pierwszy tydzień) i czego nie wiemy; TelemediGO osobno |
| Kohorty | wniosek o powrotach, pasek „Pacjenci w analizie” (przypisanie źródła, zawężenia, „Przywróć domyślne”), mapa kohort miesięcznych, tygodniowych albo dziennych z nazwami zdarzeń, kohorty dzień po dniu z przyciskami zdarzeń (porównanie 60 dni przed i po) i tabelą grup (kolor tylko przy zmianie większej niż przypadek), krzywa powrotu |
| Lejek | pasek „Sesje w analizie” z „Przywróć domyślne”, kroki od wejścia na stronę do płatności, dzień po dniu z przyciskami zdarzeń i tabelą grup (urządzenie, przeglądarka, kanał, kampania, strona wejścia), rozpoznane problemy (Safari, przeglądarki w aplikacjach) |
| Po zakupie | punktualność wizyt według pory i specjalizacji, opóźnienia według godziny i porannego ruchu, powrót i oceny po spóźnionej wizycie, zwroty, anulacje i wizyty nieodebrane |
| Zdarzenia | na górze tabela zdarzeń i naszych decyzji, które zmieniły kohorty i wynik (skutek w złotych, pewność, co robimy, odnośnik do porównania 60 dni przed i po na kohortach dziennych); oś czasu zdarzeń znalezionych w danych (lejek, retencja, obsługa pacjenta, jakość danych) i ich opisy |
| Wynik biznesu | wniosek o marży, kwartały rok do roku, marża i wydatki na kampanie w czasie, ekonomia kampanii według pierwszego wejścia i według sesji z płatnością |
| Jakość danych | podejrzane rzeczy w danych i to, jak je potraktowaliśmy |
| Priorytety | 12 działań od najważniejszego |
| Czego nie wiemy | czego dane nie rozstrzygają i jaki test albo jakie dane by to domknęły |
| Mapa biznesu | cały biznes B2C na jednym widoku: źródła nowych osób, lejek, zamówienia i wizyty, powroty, rachunek do marży, oś zdarzeń i 12 pozycji listy priorytetów jako znaczniki na mapie; suwak miesięcy; liczby wyłącznie z danych pozostałych zakładek |
| Folder | Zawartość |
|---|---|
narzedzie/ | strona narzędzia: HTML, JavaScript, biblioteka wykresów uPlot w przypiętej wersji i przeliczone dane (dane_strony/, bez danych pojedynczych pacjentów z identyfikatorami) |
analiza/ | cały kod analizy w Pythonie (DuckDB i pandas), kolejność uruchamiania w analiza/README.md |
analiza/wyniki/ | raporty i zestawienia z każdego kroku; każda liczba w notatkach i w narzędziu pochodzi z tych plików |
notatki/ | ślad pracy: założenia (ZALOZENIA.md), znaleziska w danych (ZNALEZISKA.md), decyzje (DECYZJE.md), plan (PLAN.md) i notatki z kolejnych kroków |
notatki/recenzje/ | niezależne recenzje drugiego modelu AI: polecenia, odpowiedzi i to, co poprawiliśmy |
notatki/konsylium/ | ocena listy priorytetów i końcowa weryfikacja całego rozwiązania przez kilka modeli AI różnych firm, z wynikiem |
bezpieczenstwo/ | kontrola paczki z danymi przed rozpakowaniem i raporty z niej |
Surowych danych, paczki i bazy danych nie ma w repozytorium.
duckdb 1.5.5, pandas 2.3.3 i pyarrow.dane/.analiza/README.md, zawsze przez python -I. Pierwsze dwa budują bazę: python -I analiza/a1_baza.py, potem python -I analiza/a2_czyste.py. Każdy następny skrypt tylko czyta bazę i zapisuje raport do analiza/wyniki/.python -I analiza/b_eksport.py. Uruchamia on też analiza/b2_eksport_c.py i moduły tekstów analiza/e_teksty.py oraz analiza/e_teksty_zakladki.py, które składają zdania z liczb w raportach. Eksport sprawdza każdą liczbę na stronie z raportami i z notatkami z tekstami.python -m http.server 8765 uruchomione w folderze narzedzie/, potem http://127.0.0.1:8765/.notatki/DECYZJE.md.notatki/recenzje/.notatki/ZALOZENIA.md. Tam, gdzie dane dopuszczają więcej niż jedno wyjaśnienie, nie przesądzamy przyczyny i podajemy test, który ją rozstrzygnie.Głównym narzędziem był Claude Code. Pracował w kilku sesjach naraz: sesja prowadząca rozdzielała punkty planu, a pozostałe sesje je wykonywały i zgłaszały wynik. Kuba (autor rozwiązania) zatwierdzał każdy punkt planu i każdy wniosek.
Gdzie są prompty i rozmowy:
rozmowy/ — oczyszczony zapis wszystkich rozmów z Claude Code: polecenia Kuby słowo w słowo, odpowiedzi Claude i polecenia, które sesje wysyłały sobie nawzajem i agentom pomocniczym. W rozmowy/README.md jest opis, co usunęliśmy i dlaczego (między innymi tekst zadania i adresy stron).notatki/e_runda.md, notatki/d_poprawki.md i cytaty w notatki/DECYZJE.md — dłuższe polecenia Kuby z kolejnych rund, przepisane do notatek.CLAUDE.md — zasady pracy z AI w tym projekcie: kontrola bezpieczeństwa danych, kiedy zatrzymać się u Kuby, jak sprawdzamy liczby, kiedy sięgamy po drugi model.notatki/recenzje/ — polecenia i odpowiedzi drugiego modelu (Codex) oraz tabele „co przyjmujemy, co odrzucamy i dlaczego”.notatki/konsylium/ — briefy i odpowiedzi konsylium, czyli kilku modeli różnych firm, które oceniały to samo bez naszej opinii.notatki/lekcje.md — lekcje, które Claude zapisywał po drodze w pamięci projektu: co poszło źle, dlaczego i jak tego unikać.Ślepe uliczki i poprawki. Historii commitów nie przepisywaliśmy, więc każda pomyłka jest w repozytorium razem z poprawką. Poniżej dziesięć najważniejszych. Miejsca, w których dzieją się w rozmowach, są w rozmowy/README.md.
f596688, notatki/DECYZJE.md (19.10, plan pracy).12a0128 i cab14b8, notatki/DECYZJE.md (dwie korekty po uwadze Kuby z 19.10).8f0a767 i 0696058, notatki/a5_retencja.md, notatki/recenzje/a5r_codex2.md.date_diff liczyło przekroczone granice minut, a nie upływ czasu; po poprawce data wzrostu opóźnień przesunęła się z 17.11 na 24.11.2025 i przestała się dokładnie pokrywać ze skokiem ruchu kampanii. Oba błędy znalazł Codex, który przeliczał liczby własnym kodem. Commity 0b157c4 i 8f0a767, notatki/recenzje/a5p_codex.md, notatki/recenzje/a5r_codex2.md, notatki/lekcje.md.notatki/ZNALEZISKA.md)f240505351f556notatki/DECYZJE.md17603fa i 98a5028, notatki/e_runda.md (punkty 1 i 4).849e12c i 825c977, notatki/d_poprawki.md (punkt 7 Kuby), notatki/recenzje/d_astra.md.1bfa75f, notatki/recenzje/d2_codex.md, notatki/ZALOZENIA.md (punkt 59).f596688 (zasada), 17603fa i bd827b0 (lista), notatki/konsylium/c_priorytety/synteza.md, notatki/c_szkic.md (pozycje 3 i 4).ba9e32c, 4c594b5 i 3b5eeaa, notatki/DECYZJE.md (21.10 wieczorem i 22.10), notatki/f_kontrola.md (punkt 3).