Znacznie częściej, niż możesz przypuszczać, użytkownik wchodzi na Twoją stronę z aplikacji na swoim telefonie.
I znacznie częściej, niż myślisz, taki ruch jest raportowany jako bezpośredni w Google Analytics.
Innymi słowy, trafia do tej czarnej skrzynki jaką jest ruch bezpośredni.
W zależności od projektu może to być pokaźny wolumen, bo mówimy o tak masowych aplikacjach jak:
- Gmail.
- Pasek nawigacyjny Androida (uwaga na niego, bo często w ogóle się go nie bierze pod uwagę).
- Sieci społecznościowe.
- Telegram i WhatsApp.
- Slack i podobne aplikacje.
Jeśli masz dużą grupę odbiorców z któregokolwiek z tych kanałów, to, co zaraz opowiem, będzie dla Ciebie interesujące.
Dlaczego tak się dzieje
Powodem, dla którego takie przypadki są przypisywane do ruchu bezpośredniego, jest to, że są to sesje, które nie mają referrer HTTP.
Mówiąc prosto i pomijając technikalia, chodzi o użytkowników, którzy nie przychodzą z innej strony internetowej, tylko z aplikacji.
Innymi słowy, kliknęli link w aplikacji na telefonie i trafili na Twoją stronę.
Co więcej, najczęściej oglądają Twoją stronę w wewnętrznej przeglądarce wbudowanej w prawie każdą z tych aplikacji, a nie w przeglądarce telefonu (Chrome, Safari itd.).
Jak mówię, takie zachowanie jest częstsze, niż nam się wydaje, zwłaszcza jeśli mamy dużą publiczność w którymś z tych kanałów (email, Telegram, Instagram…).
Dlatego warto zobaczyć ten ruch i móc go analizować.
Jak zobaczyć ruch na stronie pochodzący z aplikacji w GA4
Łatwiej, niż myślisz. To tylko trzy kroki:
Krok 1: utwórz pusty raport eksploracyjny
W tym celu przejdź do linku „Eksploruj” w lewej kolumnie i wybierz „Pusty raport”:

Krok 2: dodaj dane i wymiary
Zaczynamy od zaimportowania tych wymiarów:
- Adres URL strony odsyłającej.
- Źródło/medium sesji.
- Strona docelowa.
Następnie importujemy następujące dane:
- Sesje.
- Łączna liczba użytkowników.
- Aktywni użytkownicy (opcjonalnie).

W polu „Wiersze” umieszczamy wymiar Adres URL strony odsyłającej.
W polu „Wartości” umieszczamy sesje, , łączną liczbę użytkowników, lub aktywnych użytkowników, zależnie od tego, co chcemy analizować.
Krok 3: odfiltruj interesujący nas ruch
I tu pojawia się magia tego triku.
Przefiltrujemy ruch, którego adres URL odsyłający zawiera „-app:”, w ten sposób:

Wynik
Oto on:

Ważne: żeby było jasne, jeśli wcześniej nie powiedziałem tego wystarczająco wyraźnie: ten ruch NIE pochodzi z Twojej aplikacji, tylko z Twojej strony, z linków umieszczonych w innych aplikacjach, OK?
Kolejne kroki
Skoro wykryliśmy już cały ruch, jaki przynoszą nam aplikacje, możemy pogrzebać trochę głębiej — bo właśnie o to chodzi.
Teraz, gdy wiesz już, jak filtrować, dopasuj raport do tego, czego naprawdę potrzebujesz. Proponuję dwa rozszerzenia.
Dodaj źródło i medium sesji
Pierwsze, co możesz zrobić, to dodać do raportu wymiar Źródło i medium sesji:

W ten sposób zobaczysz, że część ruchu z aplikacji nie jest bezpośrednia.
Z czego to wynika?
Z tego, że rozwiązaliśmy problem: otagowaliśmy linki i dodaliśmy odpowiednie parametry UTM. Niżej wrócę do tego tematu.
Dodaj stronę docelową
Kolejnym wymiarem, który polecam dodać do raportu, jest Strona docelowa. Dzięki temu dowiesz się kilku dodatkowych rzeczy i zyskasz więcej kontekstu.
Na przykład spójrzmy na to:

Tutaj „gm” na końcu adresu URL odsyłającego mówi mi, że aplikacją jest Gmail.
A landingiem jest strona logowania do mojego serwisu.
Na podstawie tych informacji najpierw pomyślałem, że link nie jest otagowany — a jak mówiłem wyżej, to sposób, by uniknąć problemu —, ale tak nie jest. Link w e-mailu JEST otagowany.
Dlaczego więc GA4 klasyfikuje go jako ruch bezpośredni?
Z powodu typowego problemu: adres URL mojej strony, który umieściłem w linku (prawidłowo otagowany), ma redirect gdy użytkownik go otwiera.
Redirect powoduje, że parametry UTM zostają utracone a przez to GA4 nie potrafi poprawnie przypisać źródła, medium i kampanii.
To mój błąd, nie GA4. Mogę go naprawić na jeden z dwóch sposobów:
- Zmienić link w e-mailu na końcowy adres URL, do którego trafia użytkownik po redirectcie, i otagować ten URL. Najłatwiejsze rozwiązanie, ale nie zawsze możliwe.
- Sprawić, by redirect zachowywał parametry UTM i stosował je na stronie końcowej. Technicznie trochę trudniejsze, ale działa zawsze.
Pamiętaj, że taki problem z redirectami zdarza się często. Wpływa zarówno na analytics, jak i kampanie płatne, na przykład przez parametr GCLID.
Wyjątek
Jeśli przyjrzysz się obrazom, być może zauważyłeś jedną rzecz: wszystkie aplikacje działają na Android.

Nie do końca rozumiem dlaczego —przypuszczam, że chodzi o jakąś cechę Safari in-app która blokuje Analytics — ale przy tej metodzie zobaczysz wyłącznie ruch z mobilnego systemu operacyjnego Google.
Na szczęście w Hiszpanii zdecydowanie dominuje, więc masz znacznie więcej danych, niż Ci brakuje.
Rozwiązanie dla bezpośredniego ruchu z aplikacji: jak go uniknąć
Jak wspominałem już kilka razy, sposobem na jego uniknięcie jest używanie parametrów UTM. W tym celu wystarczy otworzyć Google URL Builder i dodać prawidłowe parametry.
I to wszystko? Jeśli będę robić to zawsze, przestanę mieć bezpośredni ruch na stronie z aplikacji?
Niestety muszę powiedzieć, że nie.
Powód jest taki, że kontrolujesz linki publikowane przez siebie, ale nie te, które udostępniają inni ludzie. Im więcej osób udostępnia Twoją stronę, tym lepiej, ale ponieważ nie wchodzą oni do Google URL Builder, żeby tagować linki, będziesz mieć ZAWSZE bezpośredni ruch z aplikacji.
Dlatego ważne jest, żeby wiedzieć, jak go wyświetlić w narzędziu.
Zakończenie
To niezbyt znany trik, który pozwala mocno zagłębić się w jeden segment ruchu i który, szczególnie w niektórych projektach, może być bardzo istotny.
Teraz znajdziesz wyjaśnienie dla niektórych skoków ruchu, których wcześniej nie rozumiałeś. Możesz też naprawić kilka innych rzeczy, takich jak redirecty.
Wszystko bardzo prosto, jak większość trików GA4, które opublikowałem do tej pory.
Jeśli lubisz analitykę i Google Analytics, moim zdaniem warto je przejrzeć.
A jeśli masz problemy z analityką swojego projektu i uważasz, że potrzebujesz pomocy, porozmawiajmy.

Dodaj komentarz