Acompanhamento de conversões

Figura 1. Visão geral do acompanhamento de conversões

Visão geral

O acompanhamento de conversões monitora as conversões iniciadas pelo Google em uma das nossas integrações da Central de ações. Isso ajuda a manter a integração funcionando bem, já que pode influenciar o ranking em determinadas páginas. Cada vez que o Google gera um action_link, o URL específico é modificado para incluir um parâmetro de consulta exclusivo: rwg_token. Você pode armazenar o token e retornar os valores apropriados quando um usuário concluir uma reserva.

Para concluir a integração, siga estas etapas:

1. Analise e armazene o rwg_token.
2. Analise e armazene as informações do comerciante.
3. Retorne os valores rwg_token e merchant_changed.
4. Teste e verifique o acompanhamento de conversões.

Observação: o procedimento padrão de integração exige que os parceiros implementem o acompanhamento de conversões para medição de performance, com etapas técnicas detalhadas na seção descrita mais adiante. A implementação do acompanhamento de conversões é opcional para parceiros na vertical de saúde com base nas necessidades comerciais

Analisar e armazenar o rwg_token

Para concluir a integração, colete e armazene o rwg_token por até 30 dias da indicação inicial do Google. O valor rwg_token é uma string codificada que contém metadados sobre o link e as informações do comerciante que geraram esse action_link.

Importante: nenhuma informação de identificação pessoal é armazenada ou criptografada.

Analisar o token

Quando um usuário é direcionado para sua página de agendamento de horário, um novo rwg_token é anexado ao URL fornecido. Na página de agendamento de horário, é necessário analisar o valor do token.

O exemplo a seguir mostra como o rwg_token é analisado para rastreamento no nível do dispositivo por um navegador.

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

Importante: o Google recomenda armazenar o token como um valor decodificado no cookie, já que os cookies do navegador têm usos específicos para caracteres especiais, como =. Em qualquer caso, verifique se a versão decodificada é enviada no RPC de conversão e se inclui caracteres especiais, como =.

Armazenar o token

Ao armazenar o rwg_token, você pode implementar o acompanhamento de conversões em dois níveis diferentes:

• No nível do dispositivo
• No nível do usuário

Você pode armazenar o token em qualquer nível, mas é necessário armazená-lo por 30 dias após a indicação inicial.

O exemplo a seguir mostra o acompanhamento de conversões no nível do dispositivo. É possível armazenar os valores de token em um navegador com o cookie primário. Neste exemplo, presumimos que você analisou o valor do token em uma variável. Não se esqueça de atualizar rootdomain.com com seu domínio.

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

Cada vez que o Google gera um action_link que você forneceu pelos feeds, o URL é modificado para incluir um parâmetro de consulta exclusivo: rwg_token. É necessário armazenar esse token e transmiti-lo como parte do evento de conversão.

Armazenar no nível do dispositivo

No nível do dispositivo, inclui o uso de cookies do navegador, armazenamento local, armazenamento local do app ou qualquer outro método que possa manter o token durante a janela de atribuição de 30 dias. O token é armazenado localmente no dispositivo do usuário. Assim, o evento de conversão não pode ser atribuído corretamente se o usuário:

• Mudar o dispositivo usado.
• Limpa o armazenamento local ou os cookies.
• Usar um navegador anônimo ou privado.

Ao usar o acompanhamento de conversões no nível do dispositivo, é necessário reimplementar o evento de conversão em todos os dispositivos compatíveis, incluindo dispositivos móveis.

Armazenar no nível do usuário

O nível do usuário mantém o token no banco de dados do aplicativo, usando um sistema de análise do lado do servidor ou outros sistemas do lado do servidor. O token é armazenado no lado do servidor. Assim, o evento de conversão ainda é atribuído corretamente depois que o usuário faz login novamente.

Ao usar o acompanhamento de conversões no nível do usuário com base na arquitetura do sistema, é possível implementar o evento de conversão uma vez no lado do servidor e reutilizá-lo em todos os dispositivos compatíveis.

Observação: você pode decidir onde armazenar o rwg_token com base na sua necessidade.

Atualizar o token

Quando o Google encaminha um usuário para o mesmo comerciante, o token armazenado é substituído pelo novo token do encaminhamento mais recente. Após a substituição do token, a janela de atribuição de 30 dias do armazenamento de token é redefinida, e todas as novas conversões desse comerciante são atribuídas ao token mais recente.

Consulte Requisitos para atribuição de conversão para mais detalhes.

Analisar e armazenar as informações do comerciante

Quando um usuário é direcionado à sua página de agendamento de horário, você precisa implementar a lógica que pode encontrar e capturar os detalhes do comerciante. Normalmente, os parceiros adicionam metadados do comerciante ou merchant_id aos links de ação e usam isso para identificar e armazenar as informações do comerciante.

Recomendamos armazenar o merchant_id ou o identificador selecionado com o rwg_token. Quando um usuário confirma uma reserva, você pode consultar o comerciante antes de enviar a solicitação de conversão completa. Assim como o armazenamento de token, você precisa salvar os detalhes do comerciante com o token por 30 dias após a indicação inicial.

O exemplo a seguir modifica o rwg_token armazenado anteriormente. Ele pressupõe que você analisou as informações do comerciante com base nos metadados do URL fornecido e as salvou como um merchant_id ou as associou a um merchant_id existente.

// 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=/";
}

Retornar os valores rwg_token e merchant_changed

Quando um usuário conclui uma reserva que começa com uma indicação de action_link, você precisa enviar uma solicitação HTTP POST ao endpoint de conversão. Há dois endpoints:

• Ambiente de produção: https://www.google.com/maps/conversion/collect
• Ambiente de sandbox: https://www.google.com/maps/conversion/debug/collect

Ao enviar um evento de conversão, você precisa incluir o rwg_token armazenado e um valor merchant_changed de 1 ou 2. Para mais detalhes sobre merchant_changed, consulte Retornar o valor da mudança do comerciante.

O corpo da solicitação POST precisa ser um objeto codificado em JSON no formato:

{
  "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"
}

O exemplo a seguir inclui o acompanhamento de conversões no nível do dispositivo com um cookie no dispositivo do usuário, escrito em 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
    })
  });
}

Atenção: o único MIME Content-Type aceito é text/plain. Não defina nenhum outro Content-Type no cabeçalho, o que resulta em um erro de CORS.

Aviso: verifique se, como parte dos dados de conversão, as informações de identificação pessoal (PII) do usuário não são enviadas ao Google.

Observação: em produção, não envie eventos de conversão que não sejam atribuídos a essa integração. A prática recomendada é verificar se há um valor rwg_token válido e não expirado antes de enviar o evento.

Retornar o valor da mudança do comerciante

O valor merchant_changed é usado para determinar se o comerciante mudou do comerciante de redirecionamento inicial. A mudança de comerciantes é comum se a página de destino estiver em uma plataforma que inclui outros comerciantes. Nesse caso, se um usuário for encaminhado para sua plataforma pelo Google e decidir navegar até um comerciante diferente para concluir uma reserva, você precisa saber que uma conversão ocorreu com um comerciante separado. É possível usar um booleano para identificar a mudança de comerciante, mas não os detalhes dele.

Ao decidir qual valor atribuir ao merchant_changed, você precisa considerar o comerciante original salvo em Analisar e armazenar as informações do comerciante. Verifique se o comerciante mudou e atribua o valor de acordo com sua necessidade.

• Requisito: quando um usuário sai do site do comerciante original e conclui uma compra por sua plataforma com um comerciante diferente.
  • Valor da mudança do comerciante: 1
• Requisito: quando o usuário conclui uma transação pelo comerciante original.
  • Valor da mudança do comerciante: 2

Observação: se a página de agendamento de horário não estiver em uma plataforma ou se os usuários não puderem navegar até outra loja, você poderá fixar o valor dessas solicitações como 2. Isso é comum para parceiros que integram as páginas de agendamento ao site do comerciante ou têm páginas de destino personalizadas para processar um agendamento.

Testar e verificar o acompanhamento de conversões

Os casos de teste a seguir usam tokens de teste fornecidos na seção Tokens de teste e têm como objetivo ajudar você a entender todos os cenários que podem resultar em um evento de conversão. Isso garante que o token seja armazenado adequadamente, que o valor merchant_changed seja definido corretamente e que o evento de conversão seja enviado quando apropriado.

Use o link de ação ou os URLs da página de agendamento de horário fornecidos nos seus feeds e execute cada caso de teste anexando os tokens de teste ao final do URL. Use uma janela de navegador privada ou anônima. Isso vai limpar todos os tokens associados ao usuário atual e dar a você uma tela em branco para trabalhar.

Caso de teste	Descrição do teste	Fluxo de usuários	Resultado esperado
1	Um usuário conclui uma reserva que não foi feita no Google.	Um usuário navega diretamente até a página de agendamento de horário sem ser indicado pelo Google ou sem uma indicação. Isso não deve resultar em nenhum evento de conversão.	Nenhum evento de conversão porque o usuário não acessou a página de agendamento de horário antes ou não foi indicado pelo Google.
2	Um usuário conclui uma reserva feita no Google.	Um usuário encontra sua loja no Google, é encaminhado para sua página de agendamento de horário e faz uma reserva.	Um evento de conversão seria enviado com o Token A e o valor 2 de merchant changed porque o usuário foi encaminhado para a página de agendamento de horário pelo Google.
3	Um usuário (originário do Google) inicia o fluxo de reserva, mas abandona a sessão antes que uma reserva seja concluída. Observação: mantenha essa sessão aberta para os testes 4 e 5.	Um usuário é encaminhado para sua página de agendamento de horário, mas a sessão termina e ele não conclui a reserva.	Nenhuma conversão porque o usuário não concluiu uma reserva, mas o Token B precisa ser armazenado por 30 dias.
4	Um usuário retorna à página de agendamento de horário, sem ter vindo do Google, e conclui uma reserva. Observação: o URL do fluxo de reserva não pode incluir um rwg_token.	Um usuário volta à página de agendamento de horário após o Teste nº 4. O token B precisa ser armazenado por 30 dias, e qualquer conversão durante esse período deve retornar um evento de conversão.	Um evento de conversão seria enviado com o Token B e o valor merchant changed de 2 porque o usuário está voltando à página de agendamento de horário após uma indicação anterior do Google.
5	Um usuário conclui uma nova reserva originada do Google após o Teste nº 4.	Se um usuário voltar à sua página de agendamento de horário usando uma indicação do Google após uma indicação anterior, a janela de armazenamento de 30 dias será redefinida, e um novo token Token C vai substituir o antigo Token B. Todas as conversões futuras serão atribuídas ao Token C.	Um evento de conversão seria enviado com o Token C e o valor merchant changed de 2 porque o usuário concluiu a reserva e o novo token substituiu o token armazenado anteriormente.

Se você tiver uma plataforma em que os usuários podem fazer o pagamento com um comerciante diferente, teste o seguinte:

Importante: conforme observado na seção Retornar o valor da mudança de comerciante, você pode codificar o valor dessas solicitações como 2 se as páginas de reserva ou os links de ação não permitirem que um usuário mude de comerciante. Isso é comum para parceiros que integram as páginas de agendamento ao site do comerciante ou têm páginas de destino personalizadas para processar uma reserva. Se você for um desses parceiros, pule os casos de teste a seguir.

Caso de teste	Descrição do teste	Fluxo de usuários	Resultado esperado
6	Um usuário é encaminhado para sua página de agendamento de horário pelo Google e conclui uma reserva com um comerciante diferente.	Um usuário é encaminhado para sua página de agendamento de horário pelo Google, o Token A é usado, mas, antes de concluir uma reserva, ele navega para uma página diferente e conclui a reserva com um comerciante diferente da indicação original.	Um evento de conversão seria enviado porque o usuário concluiu uma reserva originada de uma indicação do Google com o Token A e o valor merchant changed de 1 porque o usuário concluiu a reserva em um comerciante diferente da indicação.

Durante o teste, envie a solicitação HTTP POST para o endpoint de conversão. Há dois endpoints:

• Ambiente de produção: https://www.google.com/maps/conversion/collect
• Ambiente de sandbox: https://www.google.com/maps/conversion/debug/collect

Tokens de teste

Para testar o acompanhamento de conversões, adicione um dos seguintes tokens de teste ao final dos links de ação ou dos URLs da página de reserva que você fornece nos seus feeds.

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

Quando você envia os eventos de conversão bem-sucedidos, eles aparecem agregados na Central de ações, no painel de acompanhamento de conversões.

Observação: as conversões podem levar até uma hora para aparecer no painel.

Requisitos para atribuição de conversão

O padrão obrigatório do Google para atribuição de conversão é uma janela de atribuição de 30 dias para qualquer interação com um link de posicionamento de ação em qualquer loja.

Essa janela de atribuição significa que o Google pode esperar que um evento de conversão seja enviado em qualquer um dos seguintes cenários:

• Um usuário clica em um link de posicionamento de ação e faz um pedido do mesmo comerciante na mesma sessão. Valor da mudança do comerciante = 2.
• Um usuário segue um link de posicionamento de ação e retorna de um canal diferente na janela de atribuição de 30 dias para fazer um pedido do mesmo comerciante. Valor da mudança do comerciante = 2.
• Um usuário segue um link de posicionamento de ação e faz um pedido em uma loja diferente, na mesma sessão ou em outra sessão dentro de uma janela de atribuição de 30 dias. Valor da mudança do comerciante = 1.

Além disso, o Google espera enviar eventos de conversão de qualquer dispositivo que um usuário possa acessar por um link de posicionamento de ação. Esses dispositivos incluem:

• Aplicativos da Web para computadores ou dispositivos móveis.
• Apps para dispositivos móveis, seja por um link direto do app ou uma intent de app registrada para seu domínio.

Se o token for armazenado no nível do usuário, é esperado que você forneça atribuição multidispositivo. Para mais informações, consulte Armazenar no nível do usuário. Nesse caso, um usuário que segue um link de ação no computador e conclui a transação no dispositivo móvel com a mesma conta de usuário precisa acionar um evento de conversão.

Se o token for armazenado exclusivamente no nível do dispositivo, como em cookies do navegador, não é necessário fornecer atribuição multidispositivo. Nesse caso, cada dispositivo pode ter um token persistente separado se o usuário seguir um link de ação nele, e cada dispositivo pode seguir as regras de atribuição separadamente.

Observação: essa estrutura de atribuição pode ser diferente da forma como seu sistema de análise atribui conversões. Esse sistema foi projetado para operar de forma independente de qualquer acompanhamento de conversões que você faça nos seus sistemas e não precisa afetar suas análises internas.