Problem
EventTracker zbierał dane o zachowaniu odwiedzających, ale tabele i wykresy nie pokazują, gdzie na stronie to się dzieje. Klienci potrzebowali zobaczyć dane bezpośrednio na swoim landing page’u: które elementy przyciągają uwagę, a do którego miejsca odwiedzający w ogóle docierają.
Moja rola
Implementacja całego frontendu map, łącznie z jego architekturą: renderowanie podglądu strony z nałożonymi danymi, warstwy heatmapy i scrolla oraz interakcje z elementami.
Co zbudowałem
- Mapa zdarzeń: heatmapa kliknięć nałożona na podgląd strony, ze skalą od najczęściej do najrzadziej klikanych miejsc.
- Szczegóły elementu po kliknięciu: nazwa zdarzenia, liczba zdarzeń i wizyt oraz ich udział we wszystkich.
- Mapa scrolla: pasma pokazujące, jaki procent odwiedzających dotarł do danej głębokości strony.
- Przełączanie widoku między desktopem, tabletem i telefonem oraz wybór zakresu dat.
- Osobne dane dla każdego wariantu strony w testach A/B.
Wyzwania
01 · Dane w dokładnie tym miejscu
Zdarzenia muszą trafić na właściwe elementy strony, choć układ zmienia się z rozdzielczością. Stąd osobne widoki dla desktopu, tabletu i telefonu oraz przypisanie zdarzeń do identyfikatorów elementów, a nie do współrzędnych.
02 · Bezpieczny podgląd strony
Strona klienta jest renderowana jako podgląd bez uruchamiania jego skryptów i widżetów HTML. Dzięki temu mapa nie zależy od cudzego kodu, a użytkownik wie, czego podgląd nie pokaże.
03 · Czytelność przy dużej liczbie danych
Heatmapa i pasma scrolla muszą pozostać płynne i czytelne zarówno przy kilkudziesięciu, jak i przy tysiącach wizyt.
Efekt
- Klienci widzą zachowanie odwiedzających bezpośrednio na swojej stronie, bez zewnętrznych narzędzi typu Hotjar.
- Łatwiej znaleźć elementy, które nie działają, np. CTA, którego nikt nie klika, albo sekcję, do której mało kto dociera.
- Kolejna funkcjonalność zbudowana na danych z EventTrackera.