Tutorial: page_location, fragmenty URL i żądania serwera

Adres w przeglądarce, żądanie HTTP strony i zdarzenie GA4 to różne reprezentacje. Fragment po znaku # nie trafia do żądania pobierającego stronę. JavaScript może jednak odczytać fragment i przesłać wartość osobnym żądaniem.

GA4 domyślnie nie uwzględnia fragmentu. Dokumentacja odsłon Google wyraźnie wskazuje ten wyjątek względem location.href. Własna wartość page_location może zmienić przesyłane dane. Sam pasek adresu nie potwierdza więc zawartości otrzymanej przez Analytics.

Od adresu do żądania

W adresie https://shop.example/checkout?page=2#payment schemat to https, host to shop.example, ścieżka to /checkout, zapytanie to page=2, a fragment to payment. Inne adresy URL mogą dodatkowo zawierać port lub informacje o użytkowniku.

Żądanie strony wskazuje /checkout?page=2. HTTP/1.1 zwykle przekazuje adres serwera w nagłówku Host, a cel w linii żądania; HTTP/2 i HTTP/3 używają odpowiednich pseudonagłówków. Żądanie dla /#/catalog nie ujawnia zatem serwerowi strony wybranej trasy zapisanej we fragmencie. Zmiana takiej trasy często nie wymaga kolejnego pobrania dokumentu. Same żądania dokumentów nie pozwalają policzyć tych przejść.

Co opisują wymiary GA4

Poniższy przykład zakłada udokumentowane ustawienia domyślne, poprawny URL oraz brak własnego przepisywania lub usuwania danych. Wymiary są widokami zebranych danych zdarzeń, a nie czterema niezależnymi systemami pomiaru.

Własna wartość zawierająca fragment wymaga osobnej kontroli wychodzącego zdarzenia oraz używanego raportu lub eksportu. Tabela ustawień domyślnych nie gwarantuje jednakowej obsługi dowolnych fragmentów we wszystkich analizach. Stabilna nazwa trasy bez danych osobowych albo zatwierdzona ścieżka wirtualna często lepiej opisuje nawigację opartą na fragmencie.

Wartości zapytania mogą rozdzielać tę samą stronę na wiele wierszy. Rzeczywisty wynik zależy również od usuwania danych, przekształceń i raportu. Wymiar oparty na ścieżce umożliwia grupowanie bez usuwania informacji kampanijnych podczas zbierania. Własne route_name wymaga niestandardowego wymiaru o zakresie zdarzenia w zwykłych raportach GA4.

Długość i prywatność przed wysłaniem

Google podaje limit 1000 znaków dla page_location. Dłuższa wartość przekracza limit; ciche i niezawodne obcięcie nie jest bezpiecznym założeniem projektowym. Krótki, poprawny i znaczący URL jest lepszy niż przypadkowe ucięcie ciągu, które może zmienić znaczenie trasy lub parametrów.

Usuwanie parametrów według nazwy nie stanowi pełnego filtra prywatności. Dane osobowe mogą występować również w ścieżkach, dozwolonych wartościach parametrów, fragmentach i tytułach. Funkcja usuwania danych Google stanowi dodatkową kontrolę, a nie gwarancję wykrycia wszystkich danych osobowych. Lokalna kontrola długości może wypisywać tylko liczbę znaków; już pierwsze 120 znaków URL może ujawnić poufne informacje.

Usunięcie UTM lub identyfikatorów kliknięcia przed przetworzeniem kampanii może zmienić raportowanie pozyskania. Początkowy tag z niezmienionym adresem nie rozwiązuje problemu, gdy adres zawiera dane osobowe. Zatwierdzone przetwarzanie kampanii i oszczędne identyfikatory stron wymagają wspólnego projektu oraz testów. Jawne pola kampanii nie zastępują dowolnie identyfikatorów kliknięć automatycznego tagowania.

Aplikacje jednostronicowe (SPA): pomiar po zakończonym przejściu

Aplikacje jednostronicowe zmieniają widoczną treść bez pobierania całego nowego dokumentu dla każdego widoku. Automatyczny pomiar oparty na historii przeglądarki już istnieje. Własna nakładka na History API nie jest więc zawsze potrzebna ani nie potwierdza gotowości nowego tytułu. pushState() nie wywołuje hashchange, a zmiana URL nie dowodzi zakończenia asynchronicznego renderowania.

Przydatna reguła działania aplikacji to dokładnie jedno powiadomienie route_ready po zakończeniu rzeczywistej zmiany widoku. Poniższy przykład należy do kodu aplikacji, z jednym wywołaniem po przygotowaniu nowego widoku i jego tytułu. Dwa dozwolone klucze tras i angielskie tytuły są przykładami wymagającymi dopasowania do rzeczywistego katalogu tras. Nieznane trasy oraz brak lub fałszywa wartość zezwolenia są odrzucane.

function reportRouteReady(routeKey, measurementAllowed) {
  var routes = {
    catalog: { path: "/catalog", title: "Catalog" },
    checkout: { path: "/checkout", title: "Checkout" }
  };
  if (measurementAllowed !== true ||
      !Object.prototype.hasOwnProperty.call(routes, routeKey)) {
    return false;
  }
  var route = routes[routeKey];
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: "route_ready",
    route_name: routeKey,
    page_location: new URL(route.path, location.origin).href,
    page_title: route.title
  });
  return true;
}

Funkcja pomocnicza sama nie wysyła żądania. Integracja musi przekazywać bieżące zezwolenie na pomiar i zatrzymywać wywołania po wycofaniu zgody; wartość logiczna nie zastępuje obsługi zgody w pozostałych tagach. W GTM wyzwalacz zdarzenia niestandardowego route_ready może uruchamiać tag GA4 ze zdarzeniem page_view, korzystając ze zmiennych warstwy danych dla trzech przekazanych pól. Kolejne zdarzenia również wymagają spójnych wartości. Funkcja celowo nie odczytuje surowych adresów ani tytułów. Przypisane adresy nie zawierają zapytania ani fragmentu; przykład nie jest pełną implementacją pomiaru pozyskania.

Router musi zapewnić dokładnie jedno wywołanie na liczone przejście, także zgodnie z ustaloną obsługą pierwszego widoku. Skok w spisie treści nie jest automatycznie odsłoną. Ta sama trasa może oznaczać świadomy ponowny powrót, dlatego równość URL nie jest uniwersalną regułą deduplikacji. Analiza nawigacji wymaga również uwzględnienia poprzedniego zatwierdzonego adresu wirtualnego jako page_referrer.

Przy całkowicie ręcznym pomiarze osobnego wyłączenia wymagają pierwsza automatyczna odsłona oraz odsłony historii w pomiarze zaawansowanym. Samo send_page_view: false nie wyłącza odsłon historii. Testy odbiorcze obejmują pierwszy widok, nawigację wstecz i dalej, kotwice, powtarzane trasy, zmiany zgody oraz jedno zamierzone zdarzenie na przejście. Podgląd tagów, wychodzące żądania i DebugView odpowiadają na różne pytania.

Pytania i odpowiedzi

Czy kontener serwerowy może usunąć fragment?

Tak, jeżeli klient jawnie przesłał fragment jako dane zdarzenia. Kontener może zmienić lub wykluczyć wartość przed dalszym wysłaniem. Nie cofa to odbioru przez punkt końcowy ani zapisu w logach przed transformacją. Wartości, które muszą pozostać na urządzeniu, wymagają usunięcia przed wychodzącym żądaniem.

Czy przekierowanie serwera może zmienić trasę z fragmentu na ścieżkę?

Nie na podstawie samego żądania strony. Przekierowanie z / na /app/ bez własnego fragmentu zwykle zachowuje pierwotny fragment zgodnie z HTTP. Mapowanie w przeglądarce może tłumaczyć zatwierdzone stare trasy na nowe ścieżki. Po zmianie przez History API serwer musi obsługiwać nową ścieżkę także przy ponownym wczytaniu; zmiana przez Location powoduje nawigację. Pomiar powinien rozpocząć się po przewidzianym mapowaniu, z jawną regułą porównania raportów obejmujących dzień migracji.

Czy fragment chroni dane osobowe?

Nie. Skrypty mogą odczytywać i przesyłać fragmenty. Brak fragmentu w żądaniu dokumentu to ograniczona właściwość protokołu, a nie gwarancja prywatności.

Źródła

• RFC 3986: Ogólna składnia URI, sekcja 3.5
• RFC 9110: Znaczenie HTTP, Location
• Google Analytics: Pomiar odsłon
• Google Analytics: Pomiar aplikacji jednostronicowych
• Google Analytics Data API: Wymiary i dane
• Google Analytics: Zdarzenia zbierane automatycznie
• Google Analytics: Limity zbierania zdarzeń
• Google Analytics: Usuwanie danych
• Google Analytics: Zapobieganie wysyłaniu danych osobowych
• MDN: History.pushState()
• Google Tag Manager: Przekształcenia po stronie serwera
• Google Analytics: Ustawianie własnych danych kampanii
• Tag Google: Konfigurowanie trybu zgody w witrynach
• Google Analytics: Tworzenie wymiarów niestandardowych o zakresie zdarzenia