Zdarzenia są skonfigurowane. Parametry ustawione. Wydaje Ci się, że śledzenie jest gotowe. Ale czy je przetestowano? Zdarzenie zakupu, które nie zbiera kwoty. Zdarzenie formularza, które uruchamia się na złej stronie. Parametr, który wysyła złą wartość. Nieprzetestowane śledzenie psuje się w sposób, który wychodzi na jaw po tygodniach. Do tego czasu przez wiele dni zbierasz błędne dane. Testy wyłapują problemy, zanim trafią na żywo. Testowanie zajmuje godziny. Brak testów kosztuje dni.
Ten artykuł pokazuje kompleksowe testy, które potwierdzają, że zdarzenia działają poprawnie, zanim zaczniesz na nich polegać.
Czym jest testowanie zdarzeń
Testowanie zdarzeń sprawdza, czy zdarzenia uruchamiają się wtedy, gdy powinny, zbierają właściwe dane i wysyłają je do Twojej platformy analitycznej. Testy odbywają się w środowisku testowym, zanim zdarzenia trafią na produkcję.
Testowanie to nie jedno kliknięcie i rzut oka na raporty w czasie rzeczywistym. Prawdziwy test jest systematyczny. Testujesz każde zdarzenie. Testujesz różne scenariusze. Testujesz z różnymi danymi. Sprawdzasz, czy wszystko działa.
Celem jest pewność. Zanim wdrożysz zmiany na produkcję, masz pewność, że zdarzenie działa. Dokładnie je sprawdzono. Wiesz, jak wygląda poprawne działanie. Jeśli później coś się zepsuje, rozpoznasz problem.
Testuj w środowisku testowym
Zawsze testuj w środowisku testowym, zanim wdrożysz na produkcję. To Twoja piaskownica. Testuj zdarzenia. Zmieniaj je. Psuj je. Naprawiaj. Wszystko dzieje się tam. Dane produkcyjne zostają czyste.
W środowisku testowym uruchom każde zdarzenie. Kliknij przycisk, który je wywołuje. Wyślij formularz. Zrób zakup. Potem sprawdź testowe konto analityczne. Czy zdarzenie pojawia się w raportach w czasie rzeczywistym?
Testuj wielokrotnie. To, że zdarzenie zadziałało raz, nie znaczy, że działa zawsze. Przetestuj je pięć razy. Dziesięć razy. Liczy się to, by uruchamiało się za każdym razem.
Sprawdź nazwy zdarzeń i dane
Sprawdź, czy nazwy zdarzeń są poprawne. Zdarzenie o nazwie „purchase” powinno w raportach wyglądać jak „purchase”. Nie „Purchase”. Nie „purchase_event”. Dokładnie „purchase”.
Sprawdź, czy parametry są poprawne. Zdarzenie zakupu powinno mieć parametry kwoty, kategorii i kuponu. Zobacz, czy się pojawiają. Sprawdź, czy wartości są poprawne.
Skorzystaj z narzędzi deweloperskich przeglądarki. Otwórz kartę sieci. Uruchom zdarzenie. Poszukaj żądań do platformy analitycznej. Powinno być widać żądanie z nazwą zdarzenia i parametrami.
Testuj różne scenariusze
Nie testuj tylko idealnej ścieżki. Sprawdź przypadki skrajne. Co się stanie, gdy ktoś kupi bez kuponu? Czy parametr kuponu zostanie pusty? Czy przyjmie wartość domyślną? Oba rozwiązania są dobre, o ile jest spójne.
Testuj różne wartości. Zakup za 10 USD. Zakup za 1000 USD. Różne waluty. Różne kategorie produktów. Zdarzenia powinny działać niezależnie od wartości.
Testuj różne urządzenia. Komputer. Telefon. Tablet. Zdarzenia powinny uruchamiać się na wszystkich urządzeniach. Ta sama nazwa zdarzenia. Te same parametry. To samo zachowanie.
Testuj parametry zdarzeń
Dla każdego parametru sprawdź, czy zbiera właściwą wartość. Parametr kwoty w zdarzeniu zakupu powinien zbierać kwotę zakupu. Nie liczbę sztuk. Nie koszt wysyłki. Faktyczną kwotę zakupu.
Sprawdź dokładność parametrów. Zrób zakup za dokładnie 49,99 USD. Zobacz, czy parametr pokazuje 49.99. Rozbieżności wskazują na błąd w mapowaniu.
Przetestuj brakujące parametry. Co się stanie, gdy zabraknie wymaganego parametru? Czy zdarzenie nadal się uruchomi? A może zawiedzie po cichu? Zapisz to zachowanie.
Testuj kolejność i czas zdarzeń
Niektóre zdarzenia zależą od innych. Zdarzenie zakupu powinno uruchomić się po zdarzeniu płatności. Przetestuj kolejność. Uruchom zdarzenia po kolei. Sprawdź, czy uruchamiają się w poprawnej kolejności. Sprawdź, czy czas jest rozsądny. Zdarzenia powinny uruchamiać się w ciągu kilku sekund od akcji.
Testuj zdarzenia uruchamiane szybko jedno po drugim. Co się stanie, gdy ktoś kliknie przycisk dziesięć razy z rzędu? Dostaniesz dziesięć zdarzeń? Dwadzieścia? Duplikaty wskazują na problem. Brak zdarzeń też.
Testuj na prawdziwych danych
W końcu przetestuj na prawdziwych danych. Prawdziwe zakupy. Prawdziwe wysłane formularze. Prawdziwy ruch odwiedzających. Środowisko testowe jest bezpieczne, ale prawdziwe dane ujawniają problemy, które mogło ono przeoczyć.
Testuj poza godzinami szczytu. Nie testuj na żywym ruchu w czasie największego natężenia. Zrobisz szum w prawdziwych danych. Testuj wcześnie rano lub późno w nocy, gdy ruch jest mały.
Zacznij od małej skali. Testuj na niewielkim procencie ruchu. Obserwuj wyniki. Jeśli coś się zepsuje, dotknie to tylko kilku odwiedzających. Stopniowo zwiększaj procent. Gdy masz pewność, włącz dla całego ruchu.
Dokumentuj wyniki testów
Zapisz, co testowano. Data. Jakie zdarzenie. Jaki scenariusz. Czy zadziałało? Jeśli nie, co było nie tak? Jak to naprawiono?
Przechowuj wyniki testów co najmniej miesiąc. Jeśli ktoś zapyta „kiedy testowaliśmy zdarzenia zakupu?”, masz dokumentację. Jeśli zdarzenie się zepsuje, wiesz, jak je testowano, i możesz powtórzyć test.
Najczęściej zadawane pytania
Ile testów to wystarczająco dużo?
Przetestuj każde zdarzenie co najmniej pięć razy. Sprawdź różne scenariusze. Sprawdź przypadki skrajne. Sprawdź różne urządzenia. Większość zespołów poświęca na testy wszystkich zdarzeń kilka godzin. Zwykle to wystarcza. Z kreatorem stron WEMASY ustawisz to bezpośrednio na swojej stronie.
Czy testować zdarzenia na produkcji, czy tylko w środowisku testowym?
Najpierw w środowisku testowym. Gdy masz pewność, małe testy na produkcji są w porządku. Zacznij od niewielkiego procentu ruchu. Nie testuj krytycznych zdarzeń na pełnej produkcji.
Co zrobić, gdy zdarzenie nie przejdzie testu?
Zdiagnozuj je. Użyj narzędzi deweloperskich. Sprawdź warstwę danych. Sprawdź konfigurację zdarzenia. Znajdź problem. Napraw go. Przetestuj ponownie. Nie wdrażaj zepsutych zdarzeń.
Jak testować zdarzenia na urządzeniach mobilnych?
Użyj telefonu lub emulacji przeglądarki mobilnej. Uruchom zdarzenie na urządzeniu mobilnym. Sprawdź raporty w czasie rzeczywistym. Upewnij się, że zdarzenia mobilne działają tak samo jak na komputerze.
Czy testy automatyczne mogą sprawdzić, czy zdarzenia się uruchamiają?
Niektóre zespoły używają narzędzi do testów automatycznych. Do weryfikacji zdarzeń zwykle lepsze jest jednak testowanie ręczne. Testujesz logikę biznesową, a nie kod. Testy ręczne wyłapują problemy, które automatyczne pomijają.
Czy testować zdarzenia po każdej aktualizacji?
Tak. Za każdym razem, gdy zmieniasz konfigurację zdarzenia, przetestuj ją. Małe zmiany psują zdarzenia. Testuj po aktualizacjach. Nie dopuść, by zepsute zdarzenia trafiły na żywo.