Jakie błędy w konfiguracji zdarzeń kosztują zespoły dni szukania przyczyn? Zdublowane zdarzenia, które liczą tę samą akcję dwa razy. Zdarzenia ustawione na złych stronach. Parametry, które zbierają złe wartości. Niespójne nazwy, które powodują zamieszanie. Zdarzenia, które uruchamiają się w złym momencie albo wcale. Te błędy są częste, bo konfiguracja zdarzeń jest złożona. Można im jednak zapobiegać. Wiedza o tym, co się psuje, pomaga ich unikać.
Ten artykuł omawia najczęstsze błędy i sposoby, jak im zapobiegać.
Zdublowane zdarzenia
Najczęstszy błąd to dwukrotne stworzenie tego samego zdarzenia pod różnymi nazwami. Jeden programista tworzy „purchase”. Inny „purchase_conversion”. Teraz śledzisz tę samą akcję dwa razy. Raporty pokazują dwa zdarzenia. Zespoły spierają się, które jest poprawne.
Zapobiegaj duplikatom, sprawdzając rejestr zdarzeń przed utworzeniem nowego. Czy to zdarzenie już istnieje? Jeśli tak, użyj istniejącego. Jeśli nie, stwórz je według ustalonych zasad nazewnictwa.
Jeśli odkryjesz duplikaty, od razu usuń jeden z nich. Działające duplikaty zanieczyszczają Twoje dane.
Zdarzenia ustawione na złych stronach
Ustawiasz zdarzenie wysłania formularza. Testujesz je na formularzu kontaktowym. Działa. Wdrażasz. Ale zdarzenie uruchamia się na każdej stronie, nie tylko na stronach kontaktowych. Konfiguracja zdarzenia jest zbyt szeroka.
Zapobiegaj temu, testując na wielu stronach. Przetestuj stronę, na której zdarzenie ma się uruchamiać. Przetestuj strony, na których nie powinno. Upewnij się, że uruchamia się tylko tam, gdzie trzeba.
Zapisz, gdzie każde zdarzenie powinno się uruchamiać. Jeśli później zauważysz, że uruchamia się gdzie indziej, wyłapiesz błąd konfiguracji.
Parametry zbierają złe wartości
Zdarzenie zakupu ma parametr, który powinien zbierać kwotę zakupu. Zbiera jednak cenę produktu. To rzeczy powiązane, ale nie takie same. Dane są błędne.
Zapobiegaj temu, testując parametry ze znanymi wartościami. Zrób zakup za 50 USD. Sprawdź, czy parametr pokazuje 50 USD. Nie 45. Nie 55. Dokładnie 50.
Zapisz, skąd każdy parametr bierze dane. „Kwota zakupu pochodzi z pola purchase_amount w warstwie danych.” Jasna dokumentacja zapobiega pomyłkom.
Niespójne nazwy zdarzeń
Jedno zdarzenie to „purchase”. Inne to „Purchase”. Jeszcze inne to „purchase_event”. To samo zdarzenie ma trzy nazwy. Raporty pokazują trzy osobne zdarzenia. Powstaje zamieszanie.
Zapobiegaj temu, stosując spójne zasady nazewnictwa. Same małe litery. Bez spacji. Podkreślenia między słowami. Jeden standard nazewnictwa. Stosuj go do każdego zdarzenia.
Opisz swój standard nazewnictwa. Udostępnij go każdemu, kto tworzy zdarzenia. Spraw, by spójność była regułą.
Zdarzenia, które się nie uruchamiają
Konfigurujesz zdarzenie. Wdrażasz je. Nic się nie dzieje. W raportach brak zdarzeń. Zdarzenie w ogóle się nie uruchamia.
Typowe przyczyny to błędna konfiguracja wyzwalacza (zdarzenie ma uruchamiać się po kliknięciu konkretnego przycisku, ale wyzwalacz szuka złego elementu), błędna konfiguracja strony (zdarzenie ma uruchamiać się na konkretnej stronie, ale zmieniła się jej ścieżka) albo problemy z czasem (zdarzenie uruchamia się, zanim warstwa danych zostanie wypełniona).
Zapobiegaj temu, testując dokładnie przed wdrożeniem. Sprawdź konfigurację wyzwalacza. Sprawdź ścieżkę strony. Sprawdź czas. Testuj w środowisku testowym. Nie wdrażaj nieprzetestowanych zdarzeń.
Zdarzenia uruchamiają się zbyt często
Ustawiasz zdarzenie na kliknięcie przycisku. Ale uruchamia się dwadzieścia razy przy jednym kliknięciu. Wielokrotne uruchamianie zniekształca dane.
Typowe przyczyny to wiele nasłuchiwaczy tego samego zdarzenia (menedżer tagów i Twoja strona uruchamiają to samo zdarzenie) albo propagacja zdarzeń (kliknięcie elementu podrzędnego uruchamia też zdarzenie elementu nadrzędnego).
Zapobiegaj temu, rozumiejąc swój wyzwalacz. Testuj uważnie. Szukaj duplikatów. Obserwuj częstotliwość uruchamiania zdarzeń. Jeśli jest nietypowo wysoka, zbadaj sprawę.
Brakujące lub błędne wartości parametrów
Zdarzenie zakupu powinno zbierać kwotę zakupu. Ale parametr jest pusty. Albo zbiera złą wartość. Cierpi na tym jakość danych.
Typowe przyczyny to niewypełniona warstwa danych (zdarzenie uruchamia się, zanim warstwa danych ma informacje), błąd mapowania parametru (parametr szuka złego pola warstwy danych) albo wartości wpisane na stałe (parametr ma wartość wpisaną na sztywno zamiast pobierania jej z danych dynamicznych).
Zapobiegaj temu, sprawdzając, czy warstwa danych jest wypełniona, zanim uruchomią się zdarzenia. Testuj parametry na prawdziwych danych. Sprawdź, czy mapowanie jest poprawne. Używaj danych dynamicznych, a nie wartości wpisanych na stałe.
Brak testów na produkcji
Dokładnie przetestowano wszystko w środowisku testowym. Zdarzenia działają bez zarzutu. Wdrażasz na produkcję. Użytkownicy od razu zgłaszają, że zdarzenia nie działają. Środowisko testowe różni się od produkcyjnego w sposób, którego nie przewidziano.
Zapobiegaj temu, testując na produkcji na niewielkim procencie ruchu. Zacznij od 10%. Obserwuj błędy. Jeśli wszystko działa, zwiększ do 50%. Potem do 100%. Testy produkcyjne w małej skali wyłapują problemy specyficzne dla środowiska.
Brak monitorowania zdarzeń po wdrożeniu
Wdrażasz zdarzenia. Przechodzisz do kolejnego projektu. Trzy tygodnie później ktoś zauważa, że zdarzenie przestało się uruchamiać. To trzy tygodnie straconych danych.
Zapobiegaj temu, monitorując zdarzenia stale. Ustaw alerty. Jeśli zdarzenie nie uruchomi się przez godzinę, powiadom kogoś. Co tydzień sprawdzaj częstotliwość uruchamiania zdarzeń. Wyłapuj nieoczekiwane zmiany. Reaguj na problemy wcześnie.
Najczęściej zadawane pytania
Jak wyłapać zdublowane zdarzenia?
Opisz wszystkie zdarzenia w rejestrze zdarzeń. Zanim stworzysz zdarzenie, sprawdź rejestr. Jeśli istnieje coś podobnego, użyj tego. Regularne przeglądy listy zdarzeń wyłapują duplikaty, które umknęły. Z kreatorem stron WEMASY ustawisz to bezpośrednio na swojej stronie.
Zdarzenie się uruchamia, ale jakość danych jest słaba. Jak to zdiagnozować?
Sprawdź każdy element. Czy zdarzenie się uruchamia? Użyj raportów w czasie rzeczywistym. Czy wyzwalacz jest poprawny? Użyj narzędzi deweloperskich. Czy parametry są zbierane? Sprawdź ich wartości. Ustal, który element jest błędny. Napraw go. Przetestuj ponownie.
Mamy zepsute zdarzenie na produkcji. Usunąć je czy wyłączyć?
Wyłącz, nie usuwaj. Wyłączenie zachowuje dane historyczne. Usunięcie kasuje zdarzenie całkowicie. Możesz chcieć przeanalizować dane sprzed awarii. Zachowaj dane. Wyłącz tylko zdarzenie na przyszłość.
Jak zapobiegać błędom konfiguracji?
Stosuj ustandaryzowaną konfigurację zdarzeń. Stwórz szablon. Każde zdarzenie ma tę samą strukturę. Standaryzacja zmniejsza różnice. Mniej różnic to mniej błędów.
Jaki jest najgorszy błąd w konfiguracji zdarzeń?
Wdrażanie nieprzetestowanych zdarzeń na produkcję. Nieprzetestowane zdarzenia psują się po cichu. Przez wiele dni tego nie widzisz. Do tego czasu tracisz dane. Zawsze testuj przed produkcją.
Jak się podnieść po błędach w konfiguracji zdarzeń?
Reaguj szybko. Gdy zauważysz błąd, napraw go od razu. Wyłącz zepsute zdarzenie. Popraw konfigurację. Przetestuj. Wdróż ponownie. Im szybciej zareagujesz, tym mniej błędnych danych zbierzesz.