Obietnica decyzji dla czytelnika
Werdykt w skrócie: jeśli musisz podjąć jedną decyzję teraz, wprowadź konwencję akcja_obiekt_kontekst (np. click_button_signup_mobile) i trzy proste zasady: małe litery, podkreślenia zamiast spacji, maks. 40 znaków dla nazw eventów. To minimalizuje bałagan i problemy z limitami.
Co to znaczy w praktyce: eventy w GA4 mają ograniczenia (np. 40 znaków), a system traktuje różne warianty wielkości liter jako osobne eventy — więc jednoznaczność nazewnictwa zmniejsza techniczny dług. ([support.google.com)
Najważniejsze pytania — szybkie wskazówki
Jak krótko nazwać event, żeby był zrozumiały? Akcja + obiekt wystarczy w 80% przypadków; dopisz kontekst tylko gdy jest konieczny.
Czy używać wielkich liter lub spacji? Nie — wybierz małe litery i podkreślenia (snake_case).
Co zrobić z istniejącymi, rozbitymi eventami? Wyeksportuj listę, pogrupuj podobne nazwy i zrób migrację z mapowaniem stary→nowy.
Czym jest konwencja nazewnictwa eventów
Konwencja nazewnictwa to uporządkowany sposób nadawania nazw zdarzeń w systemie śledzenia (np. GA4, Firebase, mParticle). Ma na celu uniknięcie dublowania, ułatwienie raportów i możliwość automatycznej agregacji. W praktyce to proste reguły, które każdy deweloper i analityk musi znać przed wdrożeniem. ([support.mparticle.com)
Krótka definicja techniczna
Event — pojedyncze zdarzenie wysyłane do narzędzia analitycznego opisujące akcję użytkownika (np. kliknięcie, otwarcie strony). Parametry eventu to dodatkowe informacje (np. product_id, page_type). Parametry są lepsze do przekazywania kontekstu niż długie nazwy eventów. ([firebase.google.com)
Zasady praktyczne (Fakt → Skutek → Werdykt)
Fakt: GA4 i Firebase wymagają, że nazwy eventów zaczynają się literą i mogą zawierać tylko znaki alfanumeryczne i podkreślenia; nazwa nie może przekraczać 40 znaków.
Skutek: długie, opisowe nazwy rozbijają liczniki, trudno je potem przefiltrować i mogą nie być zliczane jako konwersje. ([support.google.com)
Werdykt: krótkie nazwy + parametry — nazwy dla typu akcji, parametry dla szczegółów.
Fakt: eventy są case-sensitive (różne wielkości liter = różne eventy).
Skutek: przypadkowe mieszanie camelCase i snake_case generuje duplikaty i fałszywe wskaźniki. ([webstrategies-inc.gitbook.io)
Werdykt: ustal jedną konwencję (np. snake_case) i egzekwuj ją w kodzie oraz dokumentacji.
Proponowany schemat nazewnictwa
Najprostszy i skalowalny wzór: akcja_obiekt_kontekst
Przykłady:
click_button_signup— kliknięcie przycisku zapisu.view_page_product— wyświetlenie strony produktu.purchase_item_checkout— sfinalizowanie zakupu w checkout.
Dlaczego tak: akcja (co się stało) jest kluczowa dla agregacji; obiekt (co dotyczy) pozwala filtrować; kontekst dodajesz tylko, gdy inaczej nie da się odróżnić przypadków.
Tabela: porównanie stylów nazewnictwa
| Styl | Czy łatwy do filtrowania? | Mini-werdykt |
|---|---|---|
| snake_case (akcja_obiekt) | Tak | Polecam |
| camelCase (akcjaObiekt) | Umiarkowanie | Unikaj — błędy case-sensitive |
| long descriptive names | Nie | Tylko z mapowaniem do krótkich kluczy |
Jak zacząć — 5-minutowy plan wdrożenia
Wyeksportuj aktualną listę eventów z GA4 / narzędzia (raport lub API).
Przejrzyj, pogrupuj duplikaty (różna wielkość liter, podkreśniki vs spacje).
Wybierz docelowy schemat (np. akcja_obiekt_kontekst) i zapisz trzy obowiązkowe reguły.
Zaimplementuj walidację po stronie trackera (linter/debugger) i mapowanie stary→nowy dla istniejących eventów.
Zaktualizuj dokumentację śledzenia i przeszkol zespół.
Jeśli nie wiesz, jak wyeksportować eventy — zacznij od panelu GA4 → Admin → Events lub skorzystaj z API; dokumentację limitów znajdziesz w oficjalnym poradniku Google. [Limity zbierania eventów w Google Analytics].(https://support.google.com/analytics/answer/9267744) ([support.google.com)
Typowe błędy i jak ich uniknąć
Mieszanie formatów (snake_case vs camelCase) → w praktyce: wprowadź hook w CI, który blokuje merge z niepoprawnymi nazwami.
Używanie eventów do przekazywania zbyt wiele kontekstu w nazwie → w praktyce: przenieś szczegóły do parametrów. ([ken-williams.com)
Ignorowanie limitów liczby eventów i parametrów → w praktyce: mapuj i konsoliduj, aby nie przekroczyć 500 distinct eventów (aplikacje) i limitów parametrów. ([support.google.com)
Werdykt per segment
Zespół product + analityka (mały ruch): zacznij od prostego schematu i dokumentu 1 stronicowego.
Zespół rozwinięty/międzydziałowy: wprowadź governance — lista dozwolonych eventów, code-review naming, automatyczne testy.
Firma z integracjami zewnętrznymi: najpierw audit — zbierz wszystkie źródła eventów, zintegruj mapowanie i automatyczne transformacje. ([support.mparticle.com)
Plusy / minusy konwencji
Plusy:
Mniej duplikatów, czytelniejsze raporty, krótszy onboarding nowych analityków.
Minusy:Wymaga dyscypliny i pracy porządkowej na starcie; migracja historycznych eventów nie przeniesie danych wstecz.
Podsumowanie i prosty next step
Idealne dla: zespołów, które chcą stabilnych raportów i prostszego utrzymania tracking planu.
Będzie frustrować: jeśli oczekujesz natychmiastowego efektu bez audytu istniejących eventów — trzeba poświęcić czas na porządki. Jeśli nie jesteś pewny, które eventy możesz zsunąć, zacznij od eksportu i pogrupowania.
Pierwszy krok teraz: pobierz listę eventów z GA4 i zastosuj filtr na nazwy podobne (case/different separators). Jeśli potrzebujesz oficjalnych limitów i reguł technicznych, sprawdź stronę Google [Limity zbierania eventów].(https://support.google.com/analytics/answer/9267744) ([support.google.com)
