Śledzenie konwersji

Rysunek 1. Omówienie śledzenia konwersji

Przegląd

Śledzenie konwersji rejestruje konwersje zainicjowane przez Google za pomocą jednej z naszych integracji z Centrum działań. Pomaga to utrzymać integrację w dobrym stanie i zapewnić jej prawidłowe działanie, ponieważ może wpływać na pozycję na niektórych stronach. Za każdym razem, gdy Google generuje action_link, konkretny adres URL jest modyfikowany tak, aby zawierał unikalny parametr zapytania: rwg_token. Możesz zapisać token i zwrócić odpowiednie wartości, gdy użytkownik dokona rezerwacji.

Aby ukończyć integrację, wykonaj te czynności:

1. Przeanalizuj i zapisz rwg_token.
2. Przetwarzanie i przechowywanie informacji o sprzedawcy.
3. Zwróć wartości rwg_token i merchant_changed.
4. Przetestuj i sprawdź śledzenie konwersji.

Uwaga: standardowa procedura integracji wymaga od partnerów wdrożenia śledzenia konwersji na potrzeby pomiaru skuteczności. Szczegółowe kroki techniczne znajdziesz w sekcji opisanej poniżej. Pamiętaj, że wdrożenie śledzenia konwersji jest opcjonalne dla partnerów z branży opieki zdrowotnej i zależy od potrzeb biznesowych

Analizowanie i przechowywanie rwg_token

Aby dokończyć integrację, musisz zbierać i przechowywać rwg_token przez maksymalnie 30 dni od początkowego odesłania z Google. Wartość rwg_token to zakodowany ciąg znaków, który zawiera metadane linku i informacje o sprzedawcy, które wygenerowały ten action_link.

Ważne: nie przechowujemy ani nie szyfrujemy żadnych informacji umożliwiających identyfikację.

Analizowanie tokena

Gdy użytkownik zostanie przekierowany na stronę rezerwacji, do podanego adresu URL zostanie dodany nowy parametr rwg_token. Na stronie rezerwacji musisz przeanalizować wartość tokena.

Poniższy przykład pokazuje, jak znak rwg_token jest analizowany na potrzeby śledzenia na poziomie urządzenia w przeglądarce.

const rwgToken = new URLSearchParams(location.search).get('rwg_token') || undefined;

Ważne: Google zaleca przechowywanie tokena jako zdekodowanej wartości w pliku cookie, ponieważ pliki cookie przeglądarki mają określone zastosowania w przypadku znaków specjalnych, takich jak =. W każdym przypadku upewnij się, że w wywołaniu RPC dotyczącym konwersji wysyłana jest zdekodowana wersja, która zawiera wszystkie znaki specjalne, np. =.

Przechowywanie tokena

Gdy przechowujesz rwg_token, możesz wdrożyć śledzenie konwersji na 2 różnych poziomach:

• Na poziomie urządzenia
• Na poziomie użytkownika

Token możesz przechowywać na dowolnym poziomie, ale musisz go przechowywać przez 30 dni od pierwszego polecenia.

Poniższy przykład pokazuje śledzenie konwersji na poziomie urządzenia. Wartości tokena możesz przechowywać w przeglądarce za pomocą własnego pliku cookie. W tym przykładzie zakłada się, że wartość tokena została przeanalizowana i zapisana w zmiennej. Pamiętaj, aby zastąpić rootdomain.com swoją domeną.

if (rwgToken !== undefined) {
  document.cookie =
  "_rwgToken=" + rwgToken + "; max-age=2592000; domain=rootdomain.com; path=/";
}

Za każdym razem, gdy Google generuje action_link podany przez Ciebie w plikach danych, adres URL jest modyfikowany w taki sposób, aby zawierał unikalny parametr zapytania: rwg_token. Musisz zapisać ten token i przekazać go z powrotem w ramach zdarzenia konwersji.

Przechowywanie na poziomie urządzenia

Obejmuje to używanie plików cookie przeglądarki, pamięci lokalnej, pamięci lokalnej aplikacji lub dowolnej innej metody, która może przechowywać token w 30-dniowym okresie atrybucji. Token jest przechowywany lokalnie na urządzeniu użytkownika. Zdarzenie konwersji nie może być prawidłowo przypisane, jeśli użytkownik:

• zmienić urządzenie, którego używa,
• Czyści pamięć lokalną lub pliki cookie.
• używa przeglądarki w trybie prywatnym lub incognito;

Jeśli używasz śledzenia konwersji na poziomie urządzenia, musisz ponownie wdrożyć zdarzenie konwersji na każdym obsługiwanym urządzeniu, w tym na urządzeniach mobilnych.

Przechowywanie na poziomie użytkownika

Dane na poziomie użytkownika są przechowywane w bazie danych aplikacji za pomocą systemu analitycznego po stronie serwera lub innych systemów po stronie serwera. Token jest przechowywany po stronie serwera. Dzięki temu zdarzenie konwersji będzie nadal prawidłowo przypisywane po ponownym zalogowaniu się użytkownika.

Jeśli korzystasz ze śledzenia konwersji na poziomie użytkownika na podstawie architektury systemu, możesz zaimplementować zdarzenie konwersji tylko raz po stronie serwera i używać go ponownie na wszystkich obsługiwanych urządzeniach.

Uwaga: miejsce przechowywania rwg_token możesz wybrać w zależności od swoich potrzeb.

Odświeżanie tokena

Gdy Google kieruje użytkownika do tego samego sprzedawcy, dotychczasowy token, który jest już przechowywany, zostaje zastąpiony nowym tokenem z najnowszego odesłania. Po zastąpieniu tokena 30-dniowe okno atrybucji przechowywania tokena zostanie zresetowane, a wszystkie nowe konwersje tego sprzedawcy zostaną przypisane do najnowszego tokena.

Więcej informacji znajdziesz w wymaganiach dotyczących atrybucji konwersji.

Analizowanie i przechowywanie informacji o sprzedawcy

Gdy użytkownik zostanie przekierowany na Twoją stronę rezerwacji, musisz wdrożyć logikę, która umożliwi znajdowanie i przechwytywanie szczegółów sprzedawcy. Partnerzy zwykle dodają metadane sprzedawcy lub merchant_id do linków do działań i używają ich do identyfikowania i przechowywania informacji o sprzedawcy.

Zalecamy przechowywanie elementu merchant_id lub wybranego identyfikatora wraz z elementem rwg_token. Gdy użytkownik potwierdzi rezerwację, możesz skontaktować się ze sprzedawcą, zanim wyślesz pełną prośbę o konwersję. Podobnie jak w przypadku przechowywania tokena, musisz zapisywać szczegóły sprzedawcy wraz z tokenem przez 30 dni od pierwszego odesłania.

W poniższym przykładzie modyfikujemy wcześniej zapisany element rwg_token. Zakłada, że informacje o sprzedawcy zostały wyodrębnione z metadanych w podanym adresie URL i zapisane jako merchant_id lub dopasowane do istniejącego merchant_id.

// Store the rwgToken and merchantId in your cookie and set the cookie
// expiration date to 30 days.
if (typeof rwgToken !== 'undefined') {
  document.cookie =
  "_rwgToken=" + rwgToken + "; _merchantId=" + merchantId + "; max-age=2592000;domain=rootdomain.com; path=/";
}

Zwróć wartości rwg_token i merchant_changed

Gdy użytkownik dokona rezerwacji, która rozpoczyna się od action_link odesłania, musisz wysłać żądanie HTTP POST do punktu końcowego konwersji. Dostępne są 2 punkty końcowe:

• Środowisko produkcyjne: https://www.google.com/maps/conversion/collect
• Środowisko piaskownicy: https://www.google.com/maps/conversion/debug/collect

Gdy wysyłasz zdarzenie konwersji, musisz uwzględnić zapisany rwg_token i wartość merchant_changed równą 1 lub 2. Więcej informacji o merchant_changed znajdziesz w artykule Zwracanie wartości zmiany sprzedawcy.

Treść żądania POST musi być obiektem zakodowanym w formacie JSON:

{
  "conversion_partner_id": "<partnerId>",
  "rwg_token": "<rwg_token_val>",
  "merchant_changed": "1|2"
}

{
  "conversion_partner_id": "XXXXXXX",
  "rwg_token": "AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==",
  "merchant_changed": "2"
}

Poniższy przykład zawiera śledzenie konwersji na poziomie urządzenia za pomocą pliku cookie na urządzeniu użytkownika. Jest on napisany w JavaScript:

const partnerId = XXXXXXXXXX;
const endpoint = `https://www.google.com/maps/conversion/collect`;

// Retrieve the value of the rwgToken stored in the browser's cookie
const match = document.cookie.match(new RegExp('(?:^| )_rwgToken=([^;]+)'));
const storedRwgToken = match ? match[1] : undefined;

// Send Conversion event with decoded token, verify any special characters
// are sent properly.
if (storedRwgToken !== undefined) {
  fetch(endpoint, {
    method: "POST",
    body: JSON.stringify({
      conversion_partner_id: partnerId,
      rwg_token: decodeURIComponent(storedRwgToken),
      merchant_changed: merchantChanged
    })
  });
}

Ostrzeżenie: jedynym akceptowanym znakiem MIME Content-Type jest text/plain. Nie ustawiaj w nagłówku żadnych innych Content-Type, ponieważ spowoduje to błąd CORS.

Ostrzeżenie: sprawdź, czy w ramach danych o konwersjach do Google nie są wysyłane informacje umożliwiające identyfikację użytkownika.

Uwaga: w środowisku produkcyjnym nie wolno wysyłać zdarzeń konwersji, które nie są przypisane do tej integracji. Przed wysłaniem zdarzenia sprawdź, czy wartość jest prawidłowa i nie wygasła.

rwg_token

Zwraca wartość zmiany sprzedawcy

Wartość merchant_changed służy do określania, czy sprzedawca został zmieniony w stosunku do początkowego sprzedawcy przekierowującego. Zmiana sprzedawców jest powszechna, jeśli Twoja strona docelowa znajduje się na platformie, która obejmuje innych sprzedawców. W takim przypadku, jeśli użytkownik zostanie przekierowany na Twoją platformę przez Google i zdecyduje się przejść do innego sprzedawcy, aby dokonać rezerwacji, musisz wiedzieć, że konwersja nastąpiła u innego sprzedawcy. Za pomocą wartości logicznej możesz zidentyfikować zmianę sprzedawcy, ale nie jego szczegóły.

Gdy zdecydujesz, jaką wartość przypisać do parametru merchant_changed, musisz wziąć pod uwagę pierwotnego sprzedawcę zapisanego w sekcji Analizowanie i przechowywanie informacji o sprzedawcy. Sprawdź, czy sprzedawca się zmienił, i przypisz wartość zgodnie z wymaganiami.

• Wymaganie: gdy użytkownik opuści witrynę pierwotnego sprzedawcy i dokona zakupu za pośrednictwem Twojej platformy u innego sprzedawcy.
  • Wartość zmiany sprzedawcy: 1
• Wymaganie: gdy użytkownik dokona transakcji u pierwotnego sprzedawcy.
  • Wartość zmiany sprzedawcy: 2

Uwaga: jeśli strona rezerwacji nie znajduje się na platformie lub użytkownicy nie mogą przejść do innego sprzedawcy, możesz na stałe zakodować wartość tych żądań jako 2. Jest to powszechne w przypadku partnerów, którzy integrują swoje strony rezerwacji ze stroną internetową sprzedawcy lub mają niestandardowe strony docelowe do przetwarzania rezerwacji.

Testowanie i weryfikowanie śledzenia konwersji

Poniższe przypadki testowe wykorzystują tokeny testowe podane w sekcji Tokeny testowe i mają na celu przeprowadzenie Cię przez wszystkie różne scenariusze, które mogą prowadzić do zdarzenia konwersji. Dzięki temu token będzie prawidłowo przechowywany, wartość merchant_changed będzie prawidłowo ustawiona, a zdarzenie konwersji będzie wysyłane w odpowiednim momencie.

Użyj adresów URL linków do działania lub stron rezerwacji podanych w plikach danych i przeprowadź każdy przypadek testowy, dodając tokeny testowe na końcu adresu URL. Użyj prywatnego lub incognito okna przeglądarki – spowoduje to usunięcie wszystkich tokenów powiązanych z bieżącym użytkownikiem i umożliwi rozpoczęcie pracy od zera.

Test Case	Opis testu	User Flow	Oczekiwany wynik
1	Użytkownik dokonuje rezerwacji, która nie została zainicjowana w Google.	Użytkownik przechodzi bezpośrednio na stronę rezerwacji, bez przekierowania z Google lub bez istniejącego przekierowania. Nie powinno to spowodować żadnego zdarzenia konwersji.	Brak zdarzenia konwersji, ponieważ użytkownik nie odwiedził wcześniej strony rezerwacji lub nie został przekierowany przez Google.
2	Użytkownik dokonuje rezerwacji, która została zainicjowana w Google.	Użytkownik znajduje Twojego sprzedawcę w Google, zostaje przekierowany na stronę rezerwacji i dokonuje rezerwacji.	Zostanie wysłane zdarzenie konwersji z wartościami Token A i merchant changed równymi 2, ponieważ użytkownik został przekierowany na stronę rezerwacji przez Google.
3	Użytkownik (pochodzący z Google) rozpoczyna proces rezerwacji, ale przerywa sesję, zanim rezerwacja zostanie ukończona. Uwaga: pozostaw tę sesję otwartą na potrzeby testów 4 i 5.	Użytkownik zostaje przekierowany na stronę rezerwacji, ale sesja kończy się i nie dokonuje rezerwacji.	Brak konwersji, ponieważ użytkownik nie dokonał rezerwacji, ale token B powinien być przechowywany przez 30 dni.
4	Użytkownik wraca na stronę rezerwacji (nie z Google) i dokonuje rezerwacji. Uwaga: adres URL procesu rezerwacji nie może zawierać parametru rwg_token.	Użytkownik wraca na stronę rezerwacji po teście 4. Token B powinien być przechowywany przez 30 dni, a każda konwersja w tym okresie powinna zwracać zdarzenie konwersji.	Zostanie wysłane zdarzenie konwersji z wartością 2 zmiennej merchant changed i tokenem B, ponieważ użytkownik wraca na stronę rezerwacji po wcześniejszym odesłaniu z Google.
5	Użytkownik dokonuje nowej rezerwacji pochodzącej z Google po teście 4.	Jeśli użytkownik wróci na stronę rezerwacji z odesłania z Google po wcześniejszym odesłaniu z Google, 30-dniowe okno przechowywania zostanie zresetowane, a nowy token Token C zastąpi stary token Token B. Wszystkie przyszłe konwersje będą przypisywane do Tokena C.	Zdarzenie konwersji zostanie wysłane z wartościami Token C i merchant changed równymi 2, ponieważ użytkownik dokonał rezerwacji, a nowy token zastąpił wcześniej zapisany token.

Jeśli masz platformę, na której użytkownicy mogą dokonywać płatności u innego sprzedawcy, przetestuj te elementy:

Ważne: jak wspomniano w sekcji Zwracanie wartości zmiany sprzedawcy, możesz na stałe zakodować wartość tych żądań jako 2, jeśli strony rezerwacji lub linki do działań nie umożliwiają użytkownikowi przełączania się między sprzedawcami. Jest to powszechne w przypadku partnerów, którzy integrują swoje strony rezerwacji ze stroną sprzedawcy lub mają niestandardowe strony docelowe do przetwarzania rezerwacji. Jeśli jesteś jednym z tych partnerów, możesz pominąć te przypadki testowe.

Test Case	Opis testu	User Flow	Oczekiwany wynik
6	Użytkownik zostaje przekierowany z Google na Twoją stronę rezerwacji i dokonuje rezerwacji u innego sprzedawcy.	Użytkownik zostaje przekierowany na Twoją stronę rezerwacji przez Google. Używany jest token A, ale przed dokonaniem rezerwacji użytkownik przechodzi na inną stronę i dokonuje rezerwacji u sprzedawcy, który różni się od pierwotnego źródła przekierowania.	Zostanie wysłane zdarzenie konwersji, ponieważ użytkownik dokonał rezerwacji, która została zainicjowana przez odesłanie z Google z wartością Token A i merchant changed równą 1, ponieważ użytkownik dokonał rezerwacji u innego sprzedawcy niż ten, do którego został odesłany.

Podczas testowania wyślij żądanie HTTP POST do punktu końcowego konwersji. Dostępne są 2 punkty końcowe:

• Środowisko produkcyjne: https://www.google.com/maps/conversion/collect
• Środowisko piaskownicy: https://www.google.com/maps/conversion/debug/collect

Tokeny testowe

Aby przetestować śledzenie konwersji, dodaj jeden z tych tokenów testowych na końcu linków do działań lub adresów URL strony rezerwacji podanych w plikach danych.

Token A:

rwg_token=AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ%3D%3D

Token B:

rwg_token=AJKvS9U2QfiQanHFQrlJxBjD0AyFany3qpaJVEWOcY4nHqY_UkLYFFDj6RIa-EXS1iEmV8gtFPG6v1cU1jnusJK66ijXXnaqkQ%3D%3D

Token C:

rwg_token=AJKvS9VwInjZ_hGZPvBz0COVWJ5oFDzocFt9hGi7TMurlo2l71uiXP48PspPUMmRnqCUDE1mF_A5H_dMV78cBTF8jIfSQK6lEA%3D%3D

Gdy wyślesz zdarzenia udanych konwersji, zobaczysz je w formie zbiorczej w Centrum działań na panelu śledzenia konwersji.

Uwaga: zanim konwersje pojawią się w panelu, może minąć do godziny.

Wymagania dotyczące atrybucji konwersji

Wymagany przez Google standard atrybucji konwersji to 30-dniowe okno atrybucji w przypadku każdej interakcji z linkiem do działania związanego z miejscem w dowolnym sklepie.

To okno atrybucji oznacza, że Google może oczekiwać przesłania zdarzenia konwersji w każdym z tych przypadków:

• Użytkownik klika link do działania związanego z miejscem i składa zamówienie u tego samego sprzedawcy w tej samej sesji. Wartość zmiany sprzedawcy = 2.
• Użytkownik klika link do działania związanego z miejscem, a potem wraca z innego kanału w ciągu 30-dniowego okna atrybucji, aby złożyć zamówienie u tego samego sprzedawcy. Wartość zmiany sprzedawcy = 2.
• Użytkownik klika link do działania związanego z miejscem, a potem składa zamówienie w innym sklepie, w ramach tej samej sesji lub innej sesji w 30-dniowym oknie atrybucji. Wartość zmiany sprzedawcy = 1.

Google oczekuje też wysyłania zdarzeń konwersji z dowolnego urządzenia, do którego użytkownik może uzyskać dostęp za pomocą linku do działania związanego z miejscem. Do tych urządzeń należą:

• aplikacje internetowe na komputery lub urządzenia mobilne;
• Aplikacje mobilne za pomocą precyzyjnego linku do aplikacji lub zarejestrowanego zamiaru aplikacji w przypadku Twojej domeny.

Jeśli token jest przechowywany na poziomie użytkownika, oczekujemy, że podasz atrybucję na różnych urządzeniach. Więcej informacji znajdziesz w sekcji Przechowywanie na poziomie użytkownika. W tym przypadku użytkownik, który kliknie na komputerze link do działania, a następnie sfinalizuje transakcję na urządzeniu mobilnym na tym samym koncie użytkownika, musi wywołać zdarzenie konwersji.

Jeśli token jest przechowywany wyłącznie na poziomie urządzenia, np. w plikach cookie przeglądarki, nie musisz podawać atrybucji na różnych urządzeniach. W takim przypadku każde urządzenie może mieć zapisany osobny token, jeśli użytkownik kliknie link do działania na tym urządzeniu, a każde urządzenie może oddzielnie stosować reguły atrybucji.

Uwaga: ten model atrybucji może się różnić od sposobu, w jaki konwersje są przypisywane w Twoim systemie analitycznym. Ten system jest zaprojektowany tak, aby działać niezależnie od śledzenia konwersji w Twoich systemach i nie musi wpływać na Twoje wewnętrzne statystyki.