Współczynnik odrzuceń wg czasu spędzanego na stronie. Kiedy warto i jak go ustawić?

W pierwszej części materiału o współczynniku odrzuceń mówiliśmy czym dokładnie jest bounce rate, jak jest definiowany w Google Analytics i w jaki sposób BR wpływa na miarę średniego czasu spędzanego na stronie. Jednym z dodatkowych wątków związanym z BR jest możliwość ustawienia odrzuceń na podstawie czasu spędzonego przez użytkownika na stronie. I jest to zdecydowanie temat, który wymaga dokładnego omówienia.

Krótkie przypomnienie: wywoływane zdarzenia mogą wpływać na odrzucenia. Szczegóły znajdziesz w pierwszej części tekstu. Dlatego zdarzenie, które ma miejsce po określonym czasie i nie posiadające parametru nonInteraction sprawi, że odrzucenie nie będzie mieć miejsca, jeśli tylko użytkownik spędził na stronie odpowiedni czasu. Nie ma przy tym znaczenia czy przeszedł do kolejnej strony.

W serwisie podanym jako przykład do poprzedniego artykułu ustawiony został dodatkowy event Analytics wywołujący się dokładnie po minucie czasu. Efekty wdrożenia tego rozwiązania ilustruje zrzut ekranu:

Spadek współczynnika odrzuceń

Współczynnik odrzuceń przed zmianą średnio wynosił 73%, po zmianie średnio 24% porównując ze sobą okresy miesięczne. To znaczy, że około połowa użytkowników serwisu spędza na stronie minimum minutę, a mimo to ich wizyty były uznawane za “odrzucone” oraz nie uwzględniane w wyliczeniu średniego czasu spędzanego na stronie.

Pamiętać trzeba o tym, że nie tyle bounce rate się obniżył, co raczej zmianie uległa definicja bounce rate, którą przyjmujemy dla danego serwisu. To dla mnie bardzo ważne rozróżnienie, ponieważ łatwo ulec iluzji, że oto po małej zmianie widzimy “taaaaaką wielką zmianę bounce rate” – co jest nieprawdą. Widzimy zupełnie nowy współczynnik odrzuceń i porównywanie z poprzednimi wartościami nie ma większego sensu.

Kiedy warto użyć tego rozwiązania?

Czy taka zmiana definicji BR ma sens w przypadku każdego serwisu? W mojej ocenie zdecydowanie nie. Nawet w ramach jednego serwisu może mieć sens tylko dla części podstron. Na przykład dla tego bloga zdecydowałem się uruchomić taki event tylko na stronach konkretnego tekstu. Strona główna i kategorie już go nie posiadają.

Kiedy więc warto definiować BR wg czasu spędzonego na stronie? To zależy :) Zdecydowanie w sytuacji, gdy to czas jest głównym wskaźnikiem potencjalnego zainteresowania użytkownika, a czytanie lub przeglądanie zawartości jest główną funkcją danej strony. Blogi i szerzej serwisy contentowe to idealne przykłady takiego serwisu.

Jeśli jednak celem serwisu jest dokonanie przez użytkownika interakcji to nie odważyłbym się definiować odrzuceń wg czasu spędzonego na stronie. Przykładem może być np. landing page, którego celem jest pozyskanie leadu czy strona rejestracji. Ostrożny byłbym także w przypadku ecommerce – samo wejście na konkretną podstronę sklepu i spędzenie określonego czasu nie musi świadczyć o zaangażowaniu zbieżnym z naszymi celami biznesowymi.

Podsumowując: w sytuacjach, gdy czas jest dobrym wskaźnikiem, że użytkownik robi to na czym nam zależy – zdecydowanie posłużenie się czasem spędzonym na stronie jako definicję odrzuceń jest bardzo dobrym rozwiązaniem.

Dobrą alternatywą dla śledzenia czasu jest śledzenie konkretnych akcji wykonywanych na stronie. Akcje, które domyślnie nie powodują przeładowania strony nie wpływają na odrzucenia, chyba że posłużymy dodatkowymi zdarzeniami. Interesującym pomysłem może być także śledzenie miejsca do którego doscrollował użytkownik. Te tematy poruszymy szerzej w trzeciej części tekstu :)

Konfiguracja przy użyciu Tag Managera

Najprostszą metodą na skonfigurowanie dodatkowego eventu wywoływanego po określonym czasie jest skorzystanie z Tag Managera. Planuję temu narzędziu poświęcić osobną serię tekstów. Rozbudowane możliwości tego systemu w pełni na to zasługują. Zdarzenia takie wywoływane po określonym czasie możemy wdrożyć bez ingerencji w kod serwisu. A to tylko wierzchołek góry lodowej możliwości Tag Managera.

Nie poruszaliśmy jeszcze tematu Tag Managera, więc ten artykuł może posłużyć jako wstęp do konfigurowania automatycznych zdarzeń w Tag Managerze. Wymaga jednak podstawowej znajomości interfejsu TM.

Na początek tworzymy nowy tag wybierając standardowo Google Analytics i Universal Analytics:

Tworzenie nowego tagu

W kroku konfiguracji tagu ustawiamy “Event” jako typ tagu, a potem obowiązkowo podajemy kategorię i akcję zdarzenia:

Wybór typu tagu

 

W części “Fire On” sterującej warunkiem odpalenia tagu wybieramy “More” i konfigurujemy nowy trigger (triggery decydują o tym, kiedy konkretny tag zostanie uruchomiony) klikając w “New”:

Tworzenie nowego triggera

 

Potrzebujemy teraz ustawić szczegóły triggera. Wybieramy opcję “Timer”:

Wybór opcji Timer

I ustawiamy:

Ustawianie czasu dla triggera

 

Nazwy gtm.timer nie należy modyfikować w żaden sposób. Jako interwał podajemy czas po jakim ma się uruchomić event GA. Podajemy go w milisekundach (1 sekunda = 1000 milisekund). Limit steruje tym, jak często dany tag się uruchomi (moglibyśmy więc ustawić wielokrotne uruchamianie w konkretnych odstępach czasu). Na razie zdecydowałem się na pojedyncze uruchomienie, więc ustawiłem limit, jako 1.

Część “Enable when” decyduje o tym, kiedy dany trigger będzie dostępny. Jeśli chcę wywoływać nowe zdarzenia Analytics w całym serwisie, wybieram dopasowanie do adresu strony i posługuję się wyrażeniem regularnym “.*” – wskazuje ono na dowolną stronę.

Konfiguracja opcji Enable when

W ostatniej części “Fire on” ustawiam “All timers” ponieważ nie chcę żadnych dodatkowych warunków:

Warunki uruchomienia triggera

Czy dokładnie różni się “Enable when” od “Fire on”? Pierwsza opcja decyduje o tym, kiedy trigger jest dostępny i nasłuchuje czy miało miejsce zdarzenie. Jest dostępna tylko dla triggerów automatycznych “Link Click”, “Timer” i “Form” oraz gdy zaznaczyliśmy “Wait for Tags” lub “Check Validation“. Dzięki tej opcji w razie ewentualnych problemów możemy ograniczyć obecność triggera do konkretnych sytuacji. Dopiero druga opcja decyduje o dokładnych warunkach uruchomienia triggera. W tym przypadku ustawiając “All timers” nie nadaję żadnego dodatkowego warunku.

Podsumowanie

Współczynnik odrzuceń zdefiniowany wg czasu spędzonego na stronie lepiej oddaje zachowanie użytkowników na stronach, gdzie spędzony czas wskazuje na zaangażowanie użytkownika. Pozwala zobaczyć bardziej realny czas na stronie. Warto jednak podejść do tematu ostrożnie – nie dla każdego rodzaju serwisu jest to dobry sposób mierzenia odrzuceń.

W kolejnej części porozmawiamy o tym, jakie akcje warto mierzyć na stronie, aby widzieć realniejszy bounce rate.

Przeczytaj poprzedni wpis:
Czym dokładnie jest współczynnik odrzuceń?

Braki w rozumieniu współczynnika odrzuceń (ang. bounce rate) dosyć często rodzą problemy przy analizie danych. Dlatego współczynnik odrzuceń to temat...

Zamknij