Suivi des conversions

Figure 1. Présentation du suivi des conversions

Présentation

Le suivi des conversions permet de comptabiliser les conversions initiées par Google via l'une de nos intégrations Action Center. Cela permet de maintenir votre intégration en bon état de fonctionnement, car cela peut influencer le classement sur certaines pages. Chaque fois que Google génère un action_link, l'URL spécifique est modifiée pour inclure un paramètre de requête unique : rwg_token. Vous pouvez stocker le jeton et renvoyer les valeurs appropriées lorsqu'un utilisateur effectue une réservation.

Pour finaliser l'intégration, procédez comme suit :

1. Analysez et stockez le rwg_token.
2. Analysez et stockez les informations sur le marchand.
3. Renvoyez les valeurs rwg_token et merchant_changed.
4. Testez et vérifiez le suivi des conversions.

Remarque : La procédure d'intégration standard exige des partenaires qu'ils implémentent le suivi des conversions pour mesurer les performances. Les étapes techniques sont détaillées dans la section décrite plus loin. Notez que l'implémentation du suivi des conversions est facultative pour les partenaires du secteur de la santé en fonction de leurs besoins commerciaux.

Analyser et stocker le rwg_token

Pour finaliser l'intégration, vous devez collecter et stocker le rwg_token pendant 30 jours maximum à compter de la date de la première recommandation Google. La valeur rwg_token est une chaîne encodée qui contient des métadonnées sur le lien et les informations sur le marchand qui ont généré ce action_link.

Important : Aucune information permettant de vous identifier personnellement n'est stockée ni chiffrée.

Analyser le jeton

Lorsqu'un utilisateur est redirigé vers votre page de réservation, un nouveau rwg_token est ajouté à l'URL fournie. Sur votre page de réservation, vous devez analyser la valeur du jeton.

L'exemple suivant montre comment rwg_token est analysé pour le suivi au niveau de l'appareil via un navigateur.

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

Important : Google vous recommande de stocker le jeton en tant que valeur décodée dans votre cookie, car les cookies de navigateur ont des utilisations spécifiques pour les caractères spéciaux tels que =. Dans tous les cas, assurez-vous que la version décodée est envoyée dans le RPC de conversion et qu'elle inclut tous les caractères spéciaux tels que =.

Stocker le jeton

Lorsque vous stockez le rwg_token, vous pouvez implémenter le suivi des conversions à deux niveaux différents :

• Au niveau de l'appareil
• Au niveau de l'utilisateur

Vous pouvez stocker le jeton à n'importe quel niveau, mais vous devez le stocker pendant 30 jours après le premier parrainage.

L'exemple suivant montre le suivi des conversions au niveau de l'appareil. Vous pouvez stocker les valeurs des jetons dans un navigateur avec le cookie propriétaire. Cet exemple suppose que vous avez analysé la valeur du jeton dans une variable. Veillez à remplacer rootdomain.com par votre domaine.

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

Chaque fois que Google génère un action_link que vous avez fourni dans les flux, l'URL est modifiée pour inclure un paramètre de requête unique : rwg_token. Vous devez stocker ce jeton et le renvoyer dans l'événement de conversion.

Stocker au niveau de l'appareil

Au niveau de l'appareil, cela inclut l'utilisation de cookies de navigateur, du stockage local, du stockage local de l'application ou de toute autre méthode permettant de conserver le jeton pendant la période d'attribution de 30 jours. Le jeton est stocké localement sur l'appareil de l'utilisateur. Par conséquent, l'événement de conversion ne peut pas être attribué correctement si l'utilisateur :

• changer d'appareil ;
• Efface le stockage local ou les cookies.
• Utilise un navigateur privé ou en mode navigation privée.

Lorsque vous utilisez le suivi des conversions au niveau de l'appareil, vous devez réimplémenter l'événement de conversion sur tous les appareils compatibles, y compris les appareils mobiles.

Stocker au niveau de l'utilisateur

Au niveau de l'utilisateur, le jeton est conservé dans la base de données de votre application, via un système d'analyse côté serveur ou d'autres systèmes côté serveur. Le jeton est stocké côté serveur. L'événement de conversion est donc toujours attribué correctement une fois que l'utilisateur s'est reconnecté.

Lorsque vous utilisez le suivi des conversions au niveau de l'utilisateur en fonction de l'architecture de votre système, vous pouvez implémenter l'événement de conversion une seule fois côté serveur et le réutiliser sur tous les appareils compatibles.

Remarque : Vous pouvez choisir où stocker rwg_token en fonction de vos besoins.

Actualiser le jeton

Lorsque Google redirige un utilisateur vers le même marchand, le jeton existant déjà stocké est remplacé par le nouveau jeton de la dernière redirection. Une fois le jeton remplacé, la période d'attribution de 30 jours du stockage de jetons est réinitialisée et toutes les nouvelles conversions pour ce marchand sont attribuées au dernier jeton.

Pour en savoir plus, consultez Exigences concernant l'attribution des conversions.

Analyser et stocker les informations sur le marchand

Lorsqu'un utilisateur est redirigé vers votre page de réservation, vous devez implémenter la logique permettant de trouver et de capturer les informations sur le marchand. En règle générale, les partenaires ajoutent des métadonnées de marchand ou merchant_id à leurs liens d'action et les utilisent pour identifier et stocker les informations sur le marchand.

Nous vous recommandons de stocker le merchant_id ou l'identifiant sélectionné avec le rwg_token. Lorsqu'un utilisateur confirme une réservation, vous pouvez vous référer au marchand avant d'envoyer la demande de conversion complète. Comme pour le stockage des jetons, vous devez enregistrer les informations sur le marchand avec le jeton pendant 30 jours après la recommandation initiale.

L'exemple suivant modifie le rwg_token stocké précédemment. Il suppose que vous avez analysé les informations sur le marchand à partir des métadonnées de l'URL fournie et que vous les avez enregistrées en tant que merchant_id ou que vous les avez associées à un merchant_id existant.

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

Renvoie les valeurs rwg_token et merchant_changed

Lorsqu'un utilisateur effectue une réservation à partir d'une recommandation action_link, vous devez envoyer une requête HTTP POST au point de terminaison de conversion. Il existe deux points de terminaison :

• Environnement de production : https://www.google.com/maps/conversion/collect
• Environnement de bac à sable : https://www.google.com/maps/conversion/debug/collect

Lorsque vous envoyez un événement de conversion, vous devez inclure le rwg_token stocké et une valeur merchant_changed de 1 ou 2. Pour en savoir plus sur merchant_changed, consultez Renvoyer la valeur de modification du marchand.

Le corps de la requête POST doit être un objet encodé au format JSON, comme suit :

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

L'exemple suivant inclut le suivi des conversions au niveau de l'appareil avec un cookie sur l'appareil de l'utilisateur, écrit en 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
    })
  });
}

Attention : La seule valeur MIME Content-Type acceptée est text/plain. Ne définissez pas d'autres Content-Type dans l'en-tête, car cela générerait une erreur CORS.

Avertissement : Vérifiez qu'aucune information permettant d'identifier personnellement l'utilisateur (PII) n'est envoyée à Google dans les données de conversion.

Remarque : En production, vous ne devez pas envoyer d'événements de conversion qui ne sont pas attribués à cette intégration. Nous vous recommandons de vérifier que la valeur rwg_token est valide et n'a pas expiré avant d'envoyer l'événement.

Renvoyer la valeur de modification du marchand

La valeur merchant_changed permet de déterminer si le marchand a changé par rapport au marchand de redirection initial. Il est courant que les marchands changent si votre page de destination se trouve sur une plate-forme qui inclut d'autres marchands. Dans ce cas, si un utilisateur est redirigé vers votre plate-forme par Google et décide d'accéder à un autre marchand pour effectuer une réservation, vous devez savoir qu'une conversion a eu lieu avec un autre marchand. Vous pouvez utiliser un booléen pour identifier la modification du marchand, mais pas ses informations.

Lorsque vous décidez de la valeur à attribuer à merchant_changed, vous devez tenir compte du marchand d'origine enregistré dans Analyser et stocker les informations sur le marchand. Vérifiez si le marchand a changé et attribuez la valeur selon vos besoins.

• Exigence : lorsqu'un utilisateur quitte le site Web du marchand d'origine et effectue un achat sur votre plate-forme auprès d'un autre marchand.
  • Valeur de la modification du marchand : 1
• Exigence : lorsque l'utilisateur effectue une transaction auprès du marchand d'origine.
  • Valeur de la modification du marchand : 2

Remarque : Si votre page de réservation ne se trouve pas sur une plate-forme ou si les utilisateurs ne peuvent pas accéder à un autre marchand, vous pouvez coder en dur la valeur de ces requêtes sur 2. C'est courant pour les partenaires qui intègrent leurs pages de réservation au site Web de leur marchand ou qui disposent de pages de destination personnalisées pour traiter une réservation.

Tester et valider le suivi des conversions

Les cas de test suivants utilisent des jetons de test fournis dans la section Jetons de test. Ils sont destinés à vous guider à travers les différents scénarios pouvant entraîner un événement de conversion. Cela permet de s'assurer que le jeton est stocké de manière appropriée, que la valeur merchant_changed est correctement définie et que l'événement de conversion est envoyé le cas échéant.

Utilisez les URL de liens d'action ou de pages de réservation fournies dans vos flux, puis exécutez chaque cas de test en ajoutant les jetons de test à la fin de l'URL. Veillez à utiliser une fenêtre de navigation privée ou incognito. Cela effacera tous les jetons existants associés à l'utilisateur actuel et vous permettra de repartir de zéro.

Scénario de test	Description du test	Parcours utilisateur	Résultat attendu
1	Un utilisateur effectue une réservation qui n'a pas été initiée sur Google.	Un utilisateur accède directement à la page de réservation sans être redirigé par Google ni disposer d'une redirection existante. Aucun événement de conversion ne devrait être généré.	Aucun événement de conversion, car l'utilisateur n'a pas consulté la page de réservation auparavant ou n'a pas été redirigé par Google.
2	Un utilisateur effectue une réservation qui a été lancée sur Google.	Un utilisateur trouve votre marchand sur Google, est redirigé vers votre page de réservation et effectue une réservation.	Un événement de conversion sera envoyé avec le jeton A et la valeur 2 pour merchant changed, car l'utilisateur a été redirigé vers la page de réservation par Google.
3	Un utilisateur (provenant de Google) commence le processus de réservation, mais abandonne la session avant qu'une réservation ne soit effectuée. Remarque : Gardez cette session ouverte pour les tests 4 et 5.	Un utilisateur est redirigé vers votre page de réservation, mais la session se termine et il ne finalise pas la réservation.	Aucune conversion, car l'utilisateur n'a pas effectué de réservation, mais le jeton B doit être stocké pendant 30 jours.
4	Un utilisateur revient sur la page de réservation, sans provenir de Google, et effectue une réservation. Remarque : L'URL du parcours de réservation ne doit pas inclure de rwg_token.	Un utilisateur revient sur la page de réservation après le test 4. Le jeton B doit être stocké pendant 30 jours. Toute conversion effectuée pendant cette période doit générer un événement de conversion.	Un événement de conversion sera envoyé avec le jeton B et la valeur 2 pour marchand modifié, car l'utilisateur revient sur la page de réservation après avoir été précédemment redirigé depuis Google.
5	Un utilisateur effectue une nouvelle réservation provenant de Google après le test 4.	Si un utilisateur revient sur votre page de réservation à l'aide d'un lien de parrainage Google après un précédent lien de parrainage Google, sa période de stockage de 30 jours est réinitialisée et un nouveau jeton Jeton C remplace l'ancien jeton Jeton B. Toutes les futures conversions seront alors attribuées au jeton C.	Un événement de conversion sera envoyé avec le jeton C et la valeur 2 pour merchant changed, car l'utilisateur a effectué la réservation et le nouveau jeton a remplacé celui stocké précédemment.

Si votre plate-forme permet aux utilisateurs de passer à la caisse avec un autre marchand, testez les éléments suivants.

Important : Comme indiqué dans la section Renvoyer la valeur de modification du marchand, vous pouvez coder en dur la valeur de ces requêtes sur 2 si vos pages de réservation ou vos liens d'action ne permettent pas à l'utilisateur de changer de marchand. Cette méthode est courante pour les partenaires qui intègrent leurs pages de réservation au site Web de leur marchand ou qui disposent de pages de destination personnalisées pour traiter une réservation. Si vous faites partie de ces partenaires, vous pouvez ignorer les cas de test suivants.

Scénario de test	Description du test	Parcours utilisateur	Résultat attendu
6	Un utilisateur est redirigé vers votre page de réservation par Google et effectue une réservation auprès d'un autre marchand.	Un utilisateur est redirigé vers votre page de réservation par Google. Le jeton A est utilisé, mais avant de finaliser une réservation, l'utilisateur accède à une autre page et effectue la réservation auprès d'un marchand différent de celui de la redirection initiale.	Un événement de conversion est envoyé, car l'utilisateur a effectué une réservation qui provenait d'une recommandation de Google avec le jeton A et la valeur marchand modifié définie sur 1, car l'utilisateur a effectué la réservation auprès d'un marchand différent de celui de la recommandation.

Pendant que vous testez, envoyez la requête HTTP POST au point de terminaison de conversion. Il existe deux points de terminaison :

• Environnement de production : https://www.google.com/maps/conversion/collect
• Environnement de bac à sable : https://www.google.com/maps/conversion/debug/collect

Jetons de test

Pour tester le suivi des conversions, ajoutez l'un des jetons de test suivants à la fin des URL des liens d'action ou des pages de réservation que vous fournissez dans vos flux.

Jeton A :

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

Jeton B :

rwg_token=AJKvS9U2QfiQanHFQrlJxBjD0AyFany3qpaJVEWOcY4nHqY_UkLYFFDj6RIa-EXS1iEmV8gtFPG6v1cU1jnusJK66ijXXnaqkQ%3D%3D

Jeton C :

rwg_token=AJKvS9VwInjZ_hGZPvBz0COVWJ5oFDzocFt9hGi7TMurlo2l71uiXP48PspPUMmRnqCUDE1mF_A5H_dMV78cBTF8jIfSQK6lEA%3D%3D

Lorsque vous envoyez les événements de conversion réussis, vous pouvez les voir agrégés dans le Centre d'actions, sous le tableau de bord de suivi des conversions.

Remarque : Un délai d'une heure peut être nécessaire pour que les conversions s'affichent dans le tableau de bord.

Conditions requises pour l'attribution des conversions

La norme requise par Google pour l'attribution des conversions est une période d'attribution de 30 jours pour toute interaction avec un lien d'action pour un lieu, dans n'importe quel magasin.

Cette période de suivi de l'attribution signifie que Google peut s'attendre à ce qu'un événement de conversion soit envoyé dans l'un des scénarios suivants :

• Un utilisateur suit un lien d'action "Suivre un lieu" et passe une commande auprès du même marchand au cours de la même session. La valeur de modification du marchand est définie sur 2.
• Un utilisateur suit un lien d'action liée à un lieu, puis revient depuis un autre canal au cours de la période d'attribution de 30 jours pour passer une commande auprès du même marchand. La valeur de modification du marchand est définie sur 2.
• Un utilisateur clique sur un lien d'action "Suivre un lieu", puis passe une commande dans un autre magasin, au cours de la même session ou d'une autre session dans une période d'attribution de 30 jours. La valeur de modification du marchand est égale à 1.

De plus, Google s'attend à ce que les événements de conversion soient envoyés depuis n'importe quel appareil auquel un utilisateur peut accéder via un lien d'action sur un lieu. Voici quelques exemples d'appareils concernés :

• Applications Web pour ordinateur ou mobile
• Applications mobiles, soit via un lien profond vers l'application, soit via un intent d'application enregistré pour votre domaine.

Si le jeton est stocké au niveau de l'utilisateur, vous devez fournir l'attribution multi-appareils. Pour en savoir plus, consultez Stocker au niveau de l'utilisateur. Dans ce cas, un utilisateur qui suit un lien d'action depuis un ordinateur, puis effectue la transaction sur mobile avec le même compte utilisateur, doit déclencher un événement de conversion.

Si le jeton est stocké exclusivement au niveau de l'appareil, par exemple dans les cookies du navigateur, vous n'êtes pas censé fournir d'attribution cross-device. Dans ce cas, chaque appareil peut avoir un jeton distinct conservé si l'utilisateur suit un lien d'action sur cet appareil, et chaque appareil peut suivre les règles d'attribution séparément.

Remarque : Ce framework d'attribution peut être différent de la façon dont votre système d'analyse attribue les conversions. Ce système est conçu pour fonctionner indépendamment du suivi des conversions que vous effectuez dans vos systèmes. Il ne devrait pas affecter vos analyses internes.