Śledzenie kliknięć w GTM i GA4 za pomocą atrybutów data-*: zalety i konfiguracja krok po kroku

Śledzenie kliknięć to jedno z pierwszych zadań przy wdrażaniu GA4 i w teorii jedno z najprostszych, dlatego rzadko ktoś poświęca mu dużo uwagi. Osoba konfigurująca GA4 zwykle włącza rozszerzony pomiar albo ustawia w Google Tag Managerze regułę na przycisk kontaktu, sprawdza, że zdarzenie trafia do raportów, i przechodzi do pomiaru formularzy albo zakupów, który wydaje się ważniejszy. Problem pojawia się później, gdy właściciel strony chce z tych danych coś wyczytać, na przykład czy odwiedzający częściej klikają przycisk kontaktu na górze strony, czy w stopce. Takie porównanie jest możliwe tylko wtedy, gdy w raporcie da się odróżnić przyciski i miejsca, w których stoją, a przy pomiarze ustawionym w pośpiechu takich informacji w raporcie często nie ma. Pomiar kliknięć można skonfigurować na różne sposoby, a w tym artykule opiszę trzy z nich.

Zacznę od najprostszego i bardzo popularnego, ale też najbardziej ograniczonego sposobu, czyli rozszerzonego pomiaru GA4. Po włączeniu w ustawieniach strumienia danych sam rejestruje on zdarzenie click, ale wyłącznie dla linków prowadzących na inną domenę. Kliknięć w przyciski i linki wewnątrz serwisu nie rejestruje wcale, a przy linkach wychodzących nie zapisuje, w którym miejscu strony nastąpiło kliknięcie.

Bardziej świadomi użytkownicy konfigurują śledzenie kliknięć w Google Tag Managerze. Reguła sprawdza wtedy zwykle klasę CSS przycisku, tekst na przycisku albo adres linku, często w połączeniu z adresem podstrony. Taki pomiar może obejmować przyciski wewnątrz serwisu, ale klasa, tekst i adres linku nie powstały na potrzeby pomiaru, więc każdy z tych elementów można zmienić bez sprawdzania, czy korzysta z niego reguła. Reguła może wtedy przestać działać, a Google Tag Manager nie pokaże żadnego komunikatu o błędzie. Przy kilku przyciskach taki pomiar da się jeszcze kontrolować. Na większej stronie, z dziesiątkami przycisków, kilkoma wersjami językowymi i regularnymi zmianami w treści, rozróżnienie wszystkich elementów wymaga wielu osobnych reguł i warunków, a po każdej zmianie na stronie trzeba sprawdzić, czy żadna z nich nie przestała działać. Zbudowanie w ten sposób pełnego i niezawodnego pomiaru kliknięć jest skomplikowane, a jego utrzymanie w większym projekcie jest w praktyce bardzo trudne.

Trzecim sposobem, któremu poświęcam najwięcej miejsca, są custom data attributes, czyli informacje o elemencie zapisane na potrzeby pomiaru bezpośrednio w jego kodzie. Na ich podstawie można zbudować śledzenie kliknięć, które nie zależy od wyglądu strony i pozwala objąć nowe przyciski bez dokładania kolejnych reguł. Tag może wtedy wysyłać do GA4 informacje zapisane w atrybutach, na przykład nazwę sekcji, w której stoi przycisk.

Najpierw wyjaśnię, czym są atrybuty data-* i jak Google Tag Manager je odczytuje, a potem omówię ich zalety. Całą konfigurację, od zmiennych w Google Tag Managerze po raport w GA4, pokażę na przykładzie mojej strony, na której ta metoda działa od stycznia 2026 roku. Na koniec opiszę, kiedy lepiej sięgnąć po inny sposób pomiaru, oraz pułapki, które łatwo przeoczyć przy wdrożeniu.

Czym są custom data attributes

Custom data attributes, w skrócie atrybuty data-*, to standardowa część języka HTML służąca do zapisywania w elemencie własnych informacji przeznaczonych dla skryptów. Każdy atrybut zaczyna się od przedrostka data-, po którym następuje dowolna nazwa. Wartość atrybutu domyślnie nie jest wyświetlana na stronie, ale Google Tag Manager może ją odczytać w chwili kliknięcia.

Ile atrybutów dodać do elementu i co w nich zapisać, zależy od tego, jakie informacje o kliknięciach mają trafić do raportów. Developer dopisuje je do przycisku albo linku tak samo łatwo jak klasę. W konfiguracji opisanej w tym artykule każdy przycisk i link, którego kliknięcia są mierzone, ma trzy atrybuty. Pierwszy zawiera nazwę zdarzenia, które tag wyśle do GA4, drugi nazwę sekcji, w której stoi element, a trzeci opis samego elementu. Przycisk w sekcji otwierającej stronę główną mateuszpoplawski.pl wygląda w kodzie tak:

<!-- Przycisk „Umów konsultację” w sekcji hero strony głównej.
     Trzy atrybuty data-track-* niosą informację dla pomiaru,
     klasy odpowiadają wyłącznie za wygląd. -->
<a href="/kontakt"
   class="btn-primary inline-flex items-center gap-2"
   data-track-event="cta_click"
   data-track-location="hero_section"
   data-track-label="Umów konsultację">
  Umów konsultację
  <svg><!-- ikona strzałki --></svg>
</a>

Klasy i atrybuty stoją obok siebie, ale każde z nich odpowiada za coś innego. Klasy developer może zmienić przy każdej zmianie wyglądu strony, a atrybuty zmienia tylko wtedy, gdy zmienia się to, co ma być mierzone.

Jak trigger kliknięcia i Auto-Event Variable odczytują atrybut elementu

Google Tag Manager rozpoznaje kliknięcie przez trigger kliknięcia, czyli regułę, która nasłuchuje kliknięć na stronie i zapamiętuje element, w który kliknięto. Trigger ma dwa warianty. „Just Links” reaguje wyłącznie na kliknięcia w linki, czyli elementy <a>, a „All Elements” na kliknięcie w dowolny element: przycisk, obrazek albo fragment tekstu. W obu przypadkach cechy klikniętego elementu udostępniają wbudowane zmienne kliknięć (Click Element, Click Classes, Click ID, Click Text, Click URL, Click Target), które trzeba najpierw włączyć w zakładce zmiennych.

Atrybuty data-* nie mają swojej wbudowanej zmiennej, ale odczytuje je zmienna zdarzenia automatycznego (Auto-Event Variable, w skrócie AEV). To typ zmiennej użytkownika, który sięga do elementu zapamiętanego przez trigger i zwraca wybraną jego cechę, w tym wartość dowolnego atrybutu. Wystarczy wybrać typ „Element Attribute” i wpisać nazwę atrybutu, na przykład data-track-location, a zmienna przy każdym kliknięciu zwróci jego wartość. Cała konfiguracja odbywa się w interfejsie GTM, bez pisania kodu w kontenerze. Przy linkach trigger „Just Links” ma jeszcze jedną cechę, ważną dla przycisków z ikonami. Kliknięcie w ikonę albo fragment tekstu umieszczony wewnątrz linku przypisuje do linku, więc AEV odczyta atrybuty z elementu <a>, a nie z ikony.

Zalety atrybutów data-* w śledzeniu kliknięć

Zalety tej metody wynikają z tego, gdzie zapisana jest informacja o tym, co ma być mierzone. Przy regułach opartych na klasach, tekstach i adresach linków ta informacja zwykle istnieje tylko w Google Tag Managerze, bo to reguła zawiera warunek, a w kodzie strony nie widać, że któryś przycisk jest mierzony. Przy atrybutach data-* jest odwrotnie. Developer zapisuje nazwę zdarzenia, sekcję i opis bezpośrednio w kodzie przycisku, a Google Tag Manager odczytuje te wartości zmiennymi i nie musi rozpoznawać przycisku po jego wyglądzie ani treści. Z tej różnicy wynikają wszystkie korzyści opisane niżej.

Pomiar przetrwa zmianę wyglądu i technologii

Wygląd i treść strony zmieniają się zwykle częściej niż to, co ma być na niej mierzone. Przyciski dostają nowe style, teksty są poprawiane i tłumaczone, a co jakiś czas cały serwis przechodzi na nowy szablon albo framework. Reguła oparta na klasie, tekście albo adresie linku może przestać działać po każdej z tych zmian, a Google Tag Manager nie zgłosi wtedy błędu, bo kliknięcie po prostu przestanie spełniać warunek reguły.

Atrybutów data-* te zmiany nie dotyczą, o ile developer przenosi je razem z przyciskiem do nowego kodu. Dobrze widać to na mojej stronie. Trigger obsługujący kliknięcia w przyciski i trzy zmienne odczytujące atrybuty były ostatnio zmieniane 16 stycznia 2026 roku, w dniu wdrożenia atrybutów. Od tamtej pory strona przeszła na nowy framework (Next.js) i dostała wersję angielską, a przyciski zmieniały wygląd, teksty i komponenty, w których są osadzone, i żadna z tych zmian nie wymagała poprawki w Google Tag Managerze.

Ponieważ atrybut data-* to zwykły atrybut HTML, można go dodać na stronie z WordPressa, w sklepie internetowym i w aplikacji napisanej w React. W aplikacjach opartych na komponentach atrybuty wygodnie jest przekazywać jak każdą inną właściwość. Komponent przycisku przyjmuje wtedy nazwę zdarzenia i lokalizację, a wszystkie jego użycia na stronie dostają te same atrybuty, pod warunkiem że komponent przekazuje atrybuty dalej do elementu <a> albo <button>. Najpewniej sprawdzić to w wyrenderowanym HTML, a nie w kodzie komponentu. W opisywanej konfiguracji tą samą drogą atrybuty trafiają do przycisków osadzanych w artykułach z systemu zarządzania treścią. Redaktor wpisuje w polu wpisu nazwę lokalizacji, a szablon strony zamienia ją na atrybut data-track-location, więc pomiar obejmuje również treści, których nie dotyka developer.

Jeden trigger dla wielu przycisków i lokalizacja zapisana w atrybucie

Trigger nie musi znać poszczególnych przycisków, bo reaguje na wartość atrybutu. Na mojej stronie jeden trigger z warunkiem „atrybut zdarzenia równa się cta_click” obsługuje kilkadziesiąt przycisków z ponad osiemdziesięciu miejsc w kodzie. Nowy przycisk z tymi samymi atrybutami zaczyna być mierzony w chwili publikacji strony, bez żadnej zmiany w Google Tag Managerze. Wejście do GTM jest potrzebne dopiero wtedy, gdy pojawia się zupełnie nowa nazwa zdarzenia, i wrócę do tego w ostatniej sekcji.

Skoro trigger reaguje na wartość atrybutu, lokalizację też można przekazać atrybutem. Ma to znaczenie, ponieważ ten sam link bywa umieszczony na stronie kilka razy, w nagłówku, w sekcji hero, w treści i w stopce. Trigger oparty na adresie linku widzi wtedy jedno i to samo kliknięcie, a rozróżnienie miejsc wymaga osobnych reguł dla każdej sekcji. Atrybut lokalizacji rozwiązuje to bez dodatkowych reguł, pod warunkiem że developer nada każdemu elementowi nazwę sekcji, w której stoi. W opisywanej konfiguracji zdarzenie cta_click przyjmuje w GA4 kilkadziesiąt wartości lokalizacji i wszystkie da się porównać w jednym raporcie. Przycisk „Umów konsultację” z przykładu na początku tekstu ma w raporcie lokalizację hero_section, a przycisk na dole strony głównej, prowadzący pod ten sam adres, lokalizację home_bottom.

Informację o pomiarze widać w kodzie przycisku

Developer, który zmienia wygląd albo kod przycisku, zwykle nie wie, że kliknięcia w ten przycisk są mierzone, bo przy regułach opartych na klasach, tekstach i adresach linków w kodzie przycisku nie ma o tym żadnej informacji. Zmiana nazwy klasy wygląda więc dla niego na całkowicie bezpieczną, choć może sprawić, że kliknięcia w przycisk przestaną trafiać do raportów.

Atrybut z nazwą zdarzenia stoi natomiast w kodzie obok klas i tekstu przycisku, więc developer, który edytuje przycisk, widzi go i wie, że kliknięcia w ten przycisk są mierzone. Jeśli zmiany w kodzie strony przechodzą przegląd przed publikacją, atrybuty są przeglądane razem z nimi. Osoba sprawdzająca zmiany może wtedy zauważyć usunięty atrybut albo zmienioną wartość, zanim nowa wersja strony trafi do odwiedzających.

Ponieważ wszystkie atrybuty zaczynają się od tego samego przedrostka, wyszukanie data-track w kodzie strony daje listę wszystkich przycisków i linków, które mają atrybuty, razem z nazwami zdarzeń i lokalizacjami. Przy selektorach CSS taki spis trzeba odtwarzać z reguł kontenera i porównywać z kodem ręcznie. Na mojej stronie wyszukanie zwraca ponad czterysta atrybutów i od niego zaczyna się każdy przegląd pomiaru po większej zmianie strony. Wyjątkiem są komponenty, w których lokalizacja jest przekazywana jako zmienna, a nie wpisana na sztywno. Wyszukanie pokaże wtedy nazwę zmiennej, więc takie miejsca przegląda się osobno.

Prostsza konfiguracja w GTM i czytelny podział pracy

Odczytanie atrybutu nie wymaga żadnego kodu, bo robi to wbudowany typ zmiennej. Metody oparte na strukturze strony często kończą się zmiennymi z własnym JavaScriptem, które szukają nadrzędnego elementu, wycinają fragment tekstu albo składają lokalizację z kilku klas. Każda taka zmienna to kod, który trzeba utrzymywać, testować po zmianach strony i rozumieć za pół roku. Przy atrybutach kontener zawiera wyłącznie standardowe zmienne, triggery i tagi.

Z prostej konfiguracji wynika też czytelny podział odpowiedzialności między dwie osoby. Developer dopisuje atrybuty do elementów według ustalonej konwencji nazw, a osoba odpowiedzialna za pomiar decyduje, które zdarzenia trafiają do GA4 i z jakimi parametrami. W dokumentacji kodu mojej strony zasada, że przyciski prowadzące do kontaktu mają mieć trzy atrybuty, jest zapisana wprost, więc obowiązuje także przy zmianach wprowadzanych bez udziału osoby odpowiedzialnej za pomiar.

Konfiguracja śledzenia kliknięć w GTM krok po kroku

Konfiguracja w GTM składa się z trzech zmiennych, triggera i tagu GA4, a poniżej opisuję ją dokładnie w takiej postaci, w jakiej działa na mojej stronie.

Zmienne Auto-Event Variable

Każdy atrybut dostaje własną zmienną typu Auto-Event Variable z ustawieniem „Element Attribute”, nazwaną tak, żeby w kontenerze było od razu widać, który atrybut czyta:

Zmienne nie potrzebują wartości domyślnej. Gdy kliknięty element nie ma atrybutu, zmienna zwraca wartość pustą i trigger po prostu nie zareaguje.

Trigger kliknięcia

Sam trigger jest typu „Click - Just Links”, ustawiony na „Some Link Clicks”, czyli wybrane kliknięcia, z jednym warunkiem: aev_Data Track Event równa się cta_click. W kontenerze działają trzy takie triggery, różniące się tylko warunkiem. Pierwszy obsługuje przyciski wezwania do działania przez warunek „równa się”, drugi kliknięcia w odznakę partnera przez warunek „zawiera”, a trzeci jednocześnie nawigację i stopkę przez wyrażenie regularne:

// Warunek triggera „Click - Nav & Footer”
// Jedno wyrażenie obsługuje dwie nazwy zdarzeń.
aev_Data Track Event   pasuje do wyrażenia regularnego   ^(nav_click|footer_click)$

Opcja „Wait for tags”, która wstrzymuje przejście na nową stronę, aż tagi zdążą się wysłać, jest w tej konfiguracji wyłączona, bo przyciski otwierają panel kontaktowy na tej samej stronie, lub przenoszą odwiedzającego w obrębie aplikacji bez przeładowania dokumentu. Warto ją włączyć, gdy to samo kliknięcie uruchamia także tagi inne niż GA4, a link prowadzi na inną domenę i otwiera się w tej samej karcie. Tag GA4 wysyła zdarzenie w sposób, który przetrwa opuszczenie strony, ale inne tagi mogą nie zdążyć wysłać danych przed przejściem na nową stronę. Opcja opóźnia wtedy to przejście najwyżej o czas ustawiony w polu „Max wait time”, domyślnie 2000 milisekund.

Tag GA4 Event

Ostatnim elementem jest tag typu „Google Analytics: GA4 Event”, który wysyła zdarzenie z parametrami odczytanymi przez zmienne:

// Tag „GA4 Event - CTA Click”
Nazwa zdarzenia:   cta_click
Parametry:
  link_location    {{aev_Data Track Location}}   // gdzie stoi element
  link_label       {{aev_Data Track Label}}      // co to za element
  link_url         {{Click URL}}                 // dokąd prowadzi link
  page_path        {{dlv - page_path}}           // ścieżka bieżącej podstrony
  page_location    {{cjs - page_location (normalized fallback)}}
                                                 // adres liczony w chwili kliknięcia

Dwa ostatnie parametry są potrzebne na stronie bez przeładowań, bo konfiguracja tagu Google ustala tu adres strony raz, przy jej wczytaniu. Tag zdarzenia bez własnego adresu przejąłby więc adres strony wejścia. Przy nawigacji i stopce nazwa zdarzenia też pochodzi z atrybutu. Tag ma w polu nazwy zmienną {{aev_Data Track Event}}, więc ten sam tag wysyła nav_click albo footer_click, zależnie od tego, w co kliknięto. Kilka zdarzeń o identycznym zestawie parametrów obsługuje w ten sposób jeden tag zamiast kilku, a nowa nazwa zdarzenia wymaga tylko dopisania jej do wyrażenia regularnego w triggerze.

Jak nazywać zdarzenia, lokalizacje i etykiety w GA4

Trzy atrybuty pełnią w raporcie różne role, więc osoba projektująca pomiar powinna od początku ustalić, który z nich jest stałym kluczem. Nazwa zdarzenia i lokalizacja opisują to, co się nie zmienia: rodzaj interakcji i miejsce na stronie. Para cta_click z hero_section znaczy to samo dziś i za rok, niezależnie od tego, co jest napisane na przycisku, i to na niej opierają się zestawienia w czasie. Dlaczego jedno zdarzenie z parametrem lokalizacji sprawdza się lepiej niż osobne zdarzenie dla każdej sekcji, opisałem w artykule o architekturze danych.

Etykieta na mojej stronie jest tekstem przycisku. Taki wybór ma zaletę, bo w raporcie od razu widać, o który przycisk chodzi, ale ma też konsekwencję, o której trzeba pamiętać: etykieta zmienia się razem z treścią i językiem strony. Ten sam przycisk ma w wersji polskiej etykietę „Umów konsultację”, a w angielskiej inną, więc etykieta służy do opisu, a nie do porównywania okresów. Kto potrzebuje etykiety niezależnej od treści, może wpisywać w atrybut stały identyfikator, na przykład umow_konsultacje, kosztem czytelności raportu.

Konwencja nazw w tej konfiguracji jest prosta. Zdarzenia z kliknięć mają postać {rzecz}_click, na przykład cta_click, nav_click, footer_click, a lokalizacje opisują sekcję w małych literach z podkreślnikami, na przykład hero_section, home_bottom albo about_hero. Adres podstrony, na której doszło do kliknięcia, tag wysyła do GA4 w osobnym parametrze page_path. Dzięki temu ta sama sekcja może mieć jedną nazwę lokalizacji na wszystkich podstronach i w obu wersjach językowych, a w raporcie kliknięcia rozróżnia się po lokalizacji razem z adresem podstrony. Nazwy lokalizacji najlepiej ustalić raz i później ich nie zmieniać. GA4 traktuje nową nazwę jako zupełnie inną wartość wymiaru, więc kliknięcia w tę samą sekcję sprzed zmiany i po niej pojawią się w raporcie w dwóch osobnych wierszach. Żeby zobaczyć wszystkie kliknięcia w sekcję, trzeba będzie zsumować oba wiersze samodzielnie.

Kliknięcia według lokalizacji w raportach GA4

Parametry wysłane przez tag trafiają do GA4 razem ze zdarzeniem, ale nie pojawiają się w raportach automatycznie. Własne parametry, czyli link_location i link_label, rejestruje się w panelu administracyjnym usługi, w definicjach niestandardowych, jako wymiar niestandardowy o zakresie zdarzenia. Parametr link_url rejestracji nie wymaga, ponieważ GA4 obsługuje go w ramach rozszerzonego pomiaru i pokazuje w gotowym wymiarze „Link URL”. Raporty pokazują wymiar dopiero dla danych zebranych po rejestracji i nie uzupełniają go wstecz. Surowe dane w eksporcie do BigQuery zawierają parametr od pierwszego wysłania, ale w raportach GA4 tej historii nie będzie, dlatego wymiary najlepiej dodać jeszcze przed publikacją tagu. Darmowa wersja GA4 pozwala na maksymalnie pięćdziesiąt wymiarów o zakresie zdarzenia, a dwa parametry obsługujące kliknięcia zajmują z tej puli niewiele.

Po rejestracji link_location i link_label są dostępne w eksploracjach jak każdy inny wymiar. Da się w nich zestawić kliknięcia według lokalizacji z dowolnym innym wymiarem, na przykład ze źródłem ruchu, z urządzeniem albo ze stroną, na której doszło do kliknięcia, i w ten sposób zobaczyć, które sekcje pracują na konwersję w poszczególnych kanałach.

Kliknięcia według lokalizacji pokazują, ile razy kliknięto w przyciski w każdej sekcji, ale nie to, ile osób tę sekcję w ogóle zobaczyło. Sekcja na górze strony, którą widzi prawie każdy odwiedzający, zwykle zbierze więc więcej kliknięć niż sekcja na dole, nawet jeśli przyciski na dole skuteczniej zachęcają do kliknięcia. Do porównania skuteczności sekcji potrzebne jest osobne zdarzenie, wysyłane w chwili, gdy sekcja pojawia się na ekranie, które w Google Tag Managerze można skonfigurować triggerem widoczności elementu (Element Visibility).

Kiedy wystarczy trigger na adres linku, a kiedy lepszy jest dataLayer.push

Atrybuty data-* trzeba dopisać w kodzie strony, więc ich wdrożenie wymaga pracy developera. Nie w każdym projekcie są na to zasoby i nie zawsze taka praca się opłaca. Gdy mierzony jest pojedynczy element, który rzadko się zmienia, zwykle wystarczy trigger oparty na tekście, klasie albo adresie linku. Trzeba przy tym przyjąć, że po każdej zmianie klas, tekstów albo adresów linków pomiar wymaga sprawdzenia. Do kliknięć w numery telefonu i adresy e-mail dobrze sprawdza się warunek na adres linku, bo przedrostki tel: i mailto: nie zmieniają się razem z wyglądem strony.

Interakcje, które zmieniają stan strony, na przykład rozwinięcie odpowiedzi w sekcji pytań, wybór filtra albo otwarcie okna, pewniej obsłużyć zdarzeniem, które kod strony wysyła do warstwy danych (dataLayer.push). W Google Tag Managerze takie zdarzenie odczytuje trigger typu „Custom Event”. Kod strony wysyła je dopiero wtedy, gdy interakcja faktycznie się wykonała, i może od razu dołączyć do niego szczegóły, na przykład którą odpowiedź rozwinięto albo jaki filtr wybrano. W opisywanej konfiguracji w ten sposób mierzone są rozwinięcia pytań i podgląd certyfikatów, a atrybuty zostały przy linkach i przyciskach nawigacyjnych.

Dlaczego trigger kliknięcia nie reaguje na atrybut data-*

Przyciski zbudowane z elementu <button> wymagają innego triggera niż linki. Trigger „Just Links” reaguje wyłącznie na kliknięcia w elementy <a>, więc kliknięć w takie przyciski nie zarejestruje. Do przycisków <button> potrzebny jest trigger „All Elements” z tym samym warunkiem na wartość atrybutu. Trigger „All Elements” zapamiętuje jednak dokładnie ten element, w który kliknął odwiedzający. Jeśli wewnątrz przycisku jest ikona, kliknięcie w nią zostanie przypisane do ikony, która nie ma atrybutów. Żeby takie kliknięcie zostało przypisane do przycisku, ikonie trzeba nadać w stylach CSS właściwość pointer-events: none.

Kliknięcia w przycisk z nową nazwą zdarzenia nie trafią do GA4, dopóki ktoś nie dopisze tej nazwy do warunku triggera. Trigger w Google Tag Managerze reaguje tylko na nazwy zdarzeń wpisane w jego warunku, więc dodanie nowego rodzaju zdarzenia wymaga zmiany zarówno w kodzie strony, jak i w Google Tag Managerze.

Do odczytania wartości atrybutu potrzebna jest zmienna zdarzenia automatycznego (AEV). Zmienna warstwy danych (Data Layer Variable) z nazwą atrybutu, na przykład data-track-location, zwróci wartość pustą, bo w warstwie danych nie ma klucza o takiej nazwie.

Jeśli Twoja strona mierzy dziś kliknięcia na podstawie klas, tekstów albo adresów linków, nie musisz przebudowywać całego pomiaru naraz. Najprościej zacząć od przycisków prowadzących do kontaktu, ustalić dla nich konwencję nazw zdarzeń i lokalizacji, a atrybuty do kolejnych elementów dopisywać przy następnych zmianach na stronie. Jeśli potrzebujesz pomocy przy takim wdrożeniu, napisz do mnie, jak dziś mierzysz kliknięcia na swojej stronie, a ustalimy, od których elementów zacząć i jakie informacje o kliknięciach powinny trafiać do raportów.