Jak nazywać zdarzenia? „purchase” czy „purchase_conversion”? „button_click” czy „click_button”? „form_submit” czy „submit_form”? Nazewnictwo wydaje się błahe, ale jeśli je zepsujesz, śledzenie zamieni się w chaos. Jedna osoba nazywa zdarzenie „purchase”. Druga podobne zdarzenie nazywa „conversion”. Masz zdublowane śledzenie pod różnymi nazwami. Raporty pokazują sprzeczne liczby. Zespoły spierają się, która jest właściwa. Dobre nazewnictwo temu zapobiega. Spójne nazwy sprawiają, że każdy wie, co robi dane zdarzenie.
Ten artykuł wyjaśnia, jak nazywać zdarzenia i je układać, by system śledzenia pozostał uporządkowany w miarę Twojego wzrostu.
Czym jest nazewnictwo i struktura zdarzeń
Nazewnictwo to sposób, w jaki oznaczasz zdarzenia. „purchase”, „form_submit”, „video_play”. Struktura to sposób, w jaki je porządkujesz. Które zdarzenia należą do siebie? Jak je kategoryzujesz? Dobre nazwy i struktura utrzymują śledzenie w ryzach.
Złe nazewnictwo wygląda tak. Jedna osoba tworzy „purchase”. Druga „buy”. Trzecia „transaction”. To samo ma trzy różne nazwy. Raporty pokazują trzy osobne zdarzenia. Zespoły nie wiedzą, której liczbie ufać.
Dobre nazewnictwo opiera się na spójnych zasadach. Wszystkie zdarzenia zakupu nazywają się „purchase”. Wszystkie zdarzenia formularzy zaczynają się od „form_”. Wszystkie zdarzenia zaangażowania zaczynają się od „engagement_”. Spójność daje jasność.
Stwórz zasady nazewnictwa
Zdefiniuj, jak będziesz nazywać wszystkie zdarzenia. Uwzględnij kategorię. „conversion_purchase”. „conversion_signup”. „engagement_video_play”. Najpierw kategoria. Potem konkretne zdarzenie.
Konsekwentnie używaj podkreśleń albo camelCase. Same małe litery z podkreśleniami. Albo camelCase. Wybierz jedno i się go trzymaj. Niespójna wielkość liter wprowadza zamieszanie.
Nazwy mają być krótkie, ale opisowe. „purchase” jest lepsze niż „user_completes_purchase_transaction”. „form_submit” jest lepsze niż „form_submission_event_trigger”. Nazwy powinny być jasne, a nie rozwlekłe.
Grupuj powiązane zdarzenia
Zdecyduj, które zdarzenia są powiązane. Zdarzenia zakupu należą do siebie. Zdarzenia formularzy należą do siebie. Zdarzenia nawigacji też. Grupuj powiązane zdarzenia w dokumentacji i panelu.
Używaj przedrostków, by pokazać grupę. „conversion_purchase”. „conversion_signup”. Oba zaczynają się od „conversion”. Każdy, kto czyta nazwę, rozumie, że mierzą konwersje.
W raportach porządkuj zdarzenia według grup. Miej panel zdarzeń konwersji. Panel zdarzeń zaangażowania. Panel zdarzeń błędów. Porządek pomaga zespołom znaleźć to, czego potrzebują.
Stwórz hierarchię zdarzeń
Niektóre zdarzenia są ważniejsze od innych. Zakup jest krytyczny. Wysłane formularze są ważne. Przewijanie stron jest drugorzędne. Stwórz hierarchię.
Zapisz, które zdarzenia są krytyczne. Które ważne. Które to miły dodatek. Krytyczne zdarzenia testuj dokładniej. Ważne przeglądaj regularnie. Drugorzędne obserwuj w podstawowym zakresie.
Wykorzystaj tę hierarchię do podziału zasobów. Więcej czasu poświęcaj na pewność, że krytyczne zdarzenia działają. Mniej na te drugorzędne.
Dokumentuj definicje zdarzeń
Dla każdego zdarzenia opisz, czym jest. Kiedy się uruchamia? Jakie dane zbiera? Gdy ktoś nowy dołączy do zespołu, przeczyta dokumentację i zrozumie system.
Dodaj przykłady. „Zdarzenie purchase uruchamia się, gdy ktoś sfinalizuje zakup. Zbiera kwotę zamówienia, kategorię produktu i identyfikator użytkownika. Przykład: zdarzenie purchase uruchamia się z wartościami 49,99 USD, electronics, user123.”
Dokumentacja zapobiega dublowaniu zdarzeń. Zanim ktoś stworzy nowe zdarzenie, sprawdza dokumentację. Jeśli istnieje coś podobnego, używa tego.
Dopasuj zdarzenia do celów firmy
Zdarzenia powinny odpowiadać celom firmy. Jeśli celem jest sprzedaż, masz zdarzenia zakupu. Jeśli celem są kontakty, masz zdarzenia zapisów. Jeśli celem jest zaangażowanie, masz zdarzenia zaangażowania.
Przypisz każde zdarzenie do celu firmy. „To zdarzenie mierzy nasz cel sprzedażowy.” „To zdarzenie mierzy pozyskiwanie kontaktów.” „To zdarzenie mierzy zaangażowanie.” Dopasowanie pomaga zespołom zrozumieć, po co zdarzenia istnieją.
Przeglądaj zdarzenia co kwartał. Czy śledzone zdarzenia nadal pasują do celów firmy? Jeśli firma się zmienia, może potrzebujesz nowych zdarzeń. Pozbądź się tych, które nie mają znaczenia.
Najczęściej zadawane pytania
Czy nazwy zdarzeń powinny być w liczbie pojedynczej czy mnogiej?
W pojedynczej. „purchase”, a nie „purchases”. „form_submit”, a nie „form_submits”. Liczba pojedyncza jest jaśniejsza. „purchase” to pojedyncze wystąpienie akcji. Nazwy w liczbie pojedynczej zapobiegają zamieszaniu. Z kreatorem stron WEMASY ustawisz to bezpośrednio na swojej stronie.
Ile zdarzeń powinniśmy nazwać i śledzić?
Zacznij od krytycznych. Zakup, zapis, wysłany formularz. Dodaj ważne. Odtworzenia wideo, akcje zaangażowania. Dodaj drugorzędne. Przewijanie, kliknięcia. Większość stron kończy z 10 do 30 zdarzeniami. Przy większej liczbie tracisz skupienie.
Mamy stare zdarzenia ze złymi nazwami. Czy zmieniać im nazwy?
Nie. Zmiana nazwy psuje dane historyczne. Na przyszłość stosuj dobre zasady nazewnictwa. Dla danych historycznych stwórz dokument mapowania. „Stara nazwa: purchase_complete. Nowa nazwa: conversion_purchase.” Mapowanie pomaga zespołom zrozumieć, że obie nazwy oznaczają to samo.
Czy umieszczać nazwę strony w nazwie zdarzenia?
Nie. Informacja o stronie to dane dołączone do zdarzenia, a nie nazwa zdarzenia. Zdarzenie uruchamia się, gdy ktoś kliknie przycisk. Strona, na której się znajduje, to kontekst, a nie nazwa zdarzenia. Nazwy zdarzeń powinny być ogólne.
Jak postępować ze zdarzeniami, które uruchamiają się na wielu stronach?
Używaj tej samej nazwy zdarzenia niezależnie od strony. „form_submit” uruchamia się na każdej stronie z formularzem. Informacja o stronie jest dołączona jako dane zdarzenia. To uproszczenie oznacza jedno zdarzenie zamiast dziesięciu.
Zagnieżdżać zdarzenia czy trzymać je w płaskiej strukturze?
Trzymaj je płasko na poziomie nazw. Kategorie umieszczaj w przedrostkach. „conversion_purchase”, „engagement_video_play”. Płaska struktura z przedrostkami jest jaśniejsza niż zagnieżdżona. Większość zespołów stosuje płaskie nazwy z przedrostkami kategorii.