|

Jak mierzyć przejścia do systemu rezerwacyjnego ze strony hotelu?

PrzezBartosz Spychalski Czas czytania 4 min.

Cel projektu

Celem projektu było precyzyjne mierzenie przejść z witryny hotelu do zewnętrznego systemu rezerwacyjnego, z jednoczesnym zapisywaniem kontekstu, z którego użytkownik rozpoczął proces rezerwacji.

Nie chodziło wyłącznie o to, czy użytkownik kliknął „Rezerwuj”, ale skąd dokładnie to zrobił. W projekcie wyróżniliśmy trzy kluczowe źródła:

  • widget rezerwacyjny (top menu / header),
  • podstrona z pokojami lub listing pokoi,
  • podstrony z ofertami specjalnymi.

Tylko taka granularność pozwala odpowiedzieć na realne pytania biznesowe:

  • Czy użytkownicy rezerwują głównie przez widget?
  • Czy sekcja „Pokoje” faktycznie sprzedaje?
  • Czy oferty specjalne realnie inicjują rezerwacje?

Główne wyzwanie: widget widoczny na każdej podstronie

Największym wyzwaniem okazał się fakt, że widget rezerwacyjny był wyświetlany globalnie — na każdej podstronie serwisu, w tym również:

  • na stronach z pokojami,
  • na listingach pokoi,
  • na stronach z ofertami specjalnymi.

To oznaczało, że samo analizowanie adresu URL strony było niewystarczające.

Przykład problemu:

  • użytkownik znajduje się na stronie „Oferty specjalne”,
  • klika przycisk „BOOK” w górnym menu (widget),
  • klasyczne rozwiązanie oparte tylko o URL zapisze to jako „oferty specjalne”,
  • mimo że klik faktycznie pochodził z widgetu.

Efekt?
Błędne dane, mylne wnioski i złe decyzje UX lub marketingowe.

Rozwiązanie: 3-krokowy plan pomiarowy

Zamiast prostych reguł opartych wyłącznie o URL, zaprojektowano trzystopniowy model decyzyjny, który rozdziela:

  • miejsce kliknięcia
    od
  • kontekstu strony.

Krok 1: Identyfikacja kliknięcia w widget

Pierwszym krokiem było jednoznaczne wykrycie, czy klik pochodził z widgetu rezerwacyjnego.

Zrobiono to poprzez analizę:

  • tekstu przycisku (np. „REZERWUJ”, „BOOK”),
  • klas CSS charakterystycznych dla widgetu.

Na tej podstawie stworzono zmienną logiczną, która:

  • zwraca wartość widget, jeśli klik pochodził z widgetu,
  • zwraca pustą wartość w każdym innym przypadku.

DLV – is_widget_click

function() {
  var text = {{Click Text}} || '';
  var classes = {{Click Classes}} || '';

  var isBookText = /^(REZERWUJ|BOOK)$/.test(text.trim());
  var isWidgetClass = classes.indexOf('button-white') > -1;

  if (isBookText && isWidgetClass) return 'widget';
  return '';
}

Ten krok był kluczowy, bo widget musiał mieć absolutny priorytet, niezależnie od tego, na jakiej stronie użytkownik się znajdował.

Krok 2: Określenie kontekstu strony na podstawie URL

Drugim krokiem było zbudowanie mapowania kontekstu strony, ale tylko jako fallback, gdy klik nie pochodził z widgetu.

Na podstawie ścieżki URL rozpoznawano:

  • strony pokoi (/pokoje, /rooms) → pokoje,
  • strony ofert (/oferty-specjalne, /special-offers) → oferty-specjalne.

Jeśli użytkownik klikał przycisk rezerwacji bezpośrednio w treści tych podstron, kontekst był zapisywany poprawnie.

DLV – booking_source_from_url

RegEx Table

.*\/(pokoje|rooms)\/?.*

oraz

.*\/(oferty-specjalne|special-offers)\/?.*

Jeśli jednak klik pochodził z widgetu — ten krok był celowo ignorowany.

Krok 3: Zmienna decyzyjna – jedno źródło prawdy

Ostatnim etapem było stworzenie jednej finalnej zmiennej decyzyjnej, która działa według jasnej hierarchii:

  1. Jeśli klik pochodzi z widgetu → widget
  2. W przeciwnym razie, jeśli rozpoznano kontekst URL → pokoje lub oferty-specjalne
  3. Jeśli nie da się jednoznacznie określić źródła → widget (bezpieczny fallback)

DLV – booking_source_final

function() {
  var widgetClick = {{DLV – is_widget_click}};
  if (widgetClick === 'widget') {
    return 'widget';
  }

  var fromUrl = {{DLV – booking_source_from_url}};
  if (fromUrl) {
    return fromUrl;
  }

  return 'widget';
}

Dopiero ta finalna wartość była:

  • przekazywana do Google Analytics 4 jako parametr zdarzenia,
  • rejestrowana jako niestandardowy wymiar,
  • wykorzystywana w raportach i analizach.

Efekt końcowy

Wdrożone rozwiązanie pozwoliło uzyskać:

Co najważniejsze — dane zaczęły odpowiadać na rzeczywiste pytania biznesowe, a nie tylko rejestrować techniczne zdarzenia.

Dodatkowa zmienna określająca wersję językową strony:

DLV – language_version z wpisem RegEx Table:

^/en(/|$)

Podsumowanie

Ten projekt pokazuje, że w analityce hotelowej „klik w rezerwację” to za mało.
Dopiero połączenie:

  • miejsca kliknięcia,
  • kontekstu strony,
  • i logicznej hierarchii decyzji

pozwala zrozumieć, co faktycznie napędza rezerwacje.

To drobna różnica w implementacji — ale ogromna różnica w jakości danych.

Podobne wpisy