UXY1 to wewnętrzny system operacyjny pracy z revenue w ecommerce.
Służy do tego, żeby diagnozować problemy revenue, decydować co ma znaczenie, uruchamiać experiments i zamieniać wyniki w reusable learning.
To repo ma być używane operacyjnie co tydzień, a nie pełnić roli pasywnej dokumentacji.
Pętla pracy wygląda tak:
DATA -> DIAGNOSIS -> MATRIX -> PRIORITY -> EXPERIMENT -> VERDICT -> LEARNING -> NEXT
Czym to nie jest
To nie jest analytics tool.
To nie jest A/B testing engine.
To nie jest BI warehouse.
To nie jest luźny backlog pomysłów.
Korzystamy z najlepszych zewnętrznych narzędzi do danych, analizy zachowań i experimentation. Nasza wartość jest gdzie indziej: diagnosis, prioritization, experimentation logic i learning.
Główna pętla operacyjna
1. Data
Przeglądamy warstwę danych, żeby zobaczyć, gdzie ucieka revenue.
2. Diagnosis
Zmieniamy surowe obserwacje w krótką listę realnych problemów revenue, a nie luźnych opinii.
3. Matrix
Każdy insight, pomysł i expert intuition staje się formalnym node’em w matrix.
4. Priority
Ranking node’ów opiera się na impact, confidence i effort, żeby zespół pracował nad właściwymi rzeczami.
5. Experiment
Wybrane node’y zmieniają się w formalne experiments z hypothesis, metric, guardrails, ownerem i rollout planem.
6. Verdict
Każdy test kończy się decyzją: KEEP, KILL, ITERATE albo INCONCLUSIVE.
7. Learning
Każdy zamknięty test daje reusable learning, a nie tylko lokalny wynik.
8. Next
Learning wraca do kolejnej diagnosis i kolejnej listy priorities.
What we use vs what we build
Czego używamy
- GA4 do funnel behavior, traffic quality i conversion signals
- Shopify do commercial truth, AOV, cart, checkout i repeat purchase data
- Meta Ads do acquisition context
- Microsoft Clarity i Hotjar do behavior evidence
- Optimizely i Statsig do execution layer
Co budujemy
- diagnosis logic
- revenue matrix
- priority engine
- experiment decision rules
- learning system
- uporządkowany przepływ human + AI input
Nie przebudowujemy commodity tooling.
Używamy zewnętrznych narzędzi do analytics i experimentation.
Budujemy warstwę, która decyduje co testować, kiedy to testować i czego się z tego uczyć.
Struktura repo
docs/
System framing, philosophy, decision logic i rules dotyczące stacku.
sop/
Procedury operacyjne, z których zespół może korzystać od razu.
matrix/
Żywa warstwa decyzji: active nodes, backlog i archive.
experiments/
Specyfikacje aktywnych experiments i zapis experiments zakończonych.
learning/
Ustrukturyzowane wins, losses i recurring patterns.
templates/
Copy-ready templates do diagnosis, matrix nodes, experiments, learnings i weekly review.
data/
Structured notes i insight summaries z GA4, Shopify i ads platforms.
automation/
Manual-first placeholder pod przyszłą automation.
Jak zespół powinien tego używać co tydzień
Początek tygodnia
- review data notes
- odśwież diagnosis
- zaktualizuj matrix
- ustaw top priorities
- potwierdź następne 3 do 5 aktywnych rzeczy
W trakcie tygodnia
- uruchamiaj nowe experiments z wybranych node’ów
- aktualizuj status aktywnych experiments
- zapisuj wszystko, co zmienia confidence albo expected impact
- nie pozwalaj, żeby pomysły żyły poza matrix
Koniec tygodnia
- nadaj verdict zakończonym testom
- zapisz wins, losses i patterns
- archiwizuj zamknięte node’y
- ustaw następne priorities na bazie learning, a nie pamięci
Zasady pracy
- Revenue first, nie vanity metrics
- Jeden leak naraz
- Żadnego redesign-first thinking
- No idea exists outside the system
- Human intuition jest dozwolone, ale musi być sformalizowane
- AI pomaga generować opcje i strukturę, ale system kontroluje decyzje
Dlaczego to repo ma znaczenie
Moat nie polega na tym, że mamy więcej narzędzi.
Moat polega na tym, że wiemy który leak jest ważny, jak ustawić priority, kiedy testować i jak zamieniać wyniki w narastający learning.