Suivi des conversions

Figure 1. Présentation du suivi des conversions

Présentation

Le suivi des conversions permet de suivre les conversions initiées par Google via l'une de nos intégrations du Centre d'actions. Il permet de maintenir l'intégrité et le bon fonctionnement de votre intégration, car il 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 effectuer 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 le rwg_token et les valeurs merchant_changed.
4. Testez et vérifiez le suivi des conversions.

Remarque : La procédure d'intégration standard exige que les partenaires 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 des besoins de l'entreprise.

Analyser et stocker le rwg_token

Pour effectuer l'intégration, vous devez collecter et stocker le rwg_token pendant 30 jours au maximum à compter de la première redirection 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é cet action_link.

**Important** : Aucune information permettant d'identifier personnellement l'utilisateur 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 le 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 la première redirection.

L'exemple suivant montre le suivi des conversions au niveau de l'appareil. Vous pouvez stocker les valeurs de jeton 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 via 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 le cadre de l'événement de conversion.

Stocker au niveau de l'appareil

Le niveau de l'appareil 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 :

• change d'appareil ;
• vide le stockage local ou supprime 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

Le niveau de l'utilisateur conserve le jeton 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. Par conséquent, l'événement de conversion est toujours attribué correctement après 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 le 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 du jeton est réinitialisée et toutes les nouvelles conversions pour ce marchand sont attribuées au dernier jeton.

Pour en savoir plus, consultez Conditions requises pour l'attribution des conversions pour plus de détails.

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 sur le marchand ou un merchant_id à leurs liens d'action, puis 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 du jeton, vous devez enregistrer les informations sur le marchand avec le jeton pendant 30 jours après la première redirection.

L'exemple suivant modifie le rwg_token précédemment stocké. 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 mises en correspondance avec 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=/";
}

Renvoyer le rwg_token et les valeurs merchant_changed

Lorsqu'un utilisateur effectue une réservation à partir d'une redirection 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 :

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

{
  "conversion_partner_id": "XXXXXXX",
  "rwg_token": "AFd1xnHrJWKcjtriCyB5j3QL0bzbmLdcg1N1f5cJuSNVhteYjuOJz18Au6GIAT0tjHkw6fkUJKcarafV45b3c_gl7uT_o8HMcg==",
  "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 : Le seul MIME Content-Type accepté est text/plain. Ne définissez pas d'autre Content-Type dans l'en-tête, car cela entraînerait une erreur CORS.

Avertissement : Vérifiez que les informations permettant d'identifier personnellement l'utilisateur ne sont pas envoyées à Google dans le cadre des 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. Il est recommandé de vérifier si 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 été modifié par rapport au marchand de la redirection initiale. Il est courant de changer de marchand 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 une valeur booléenne pour identifier le changement de marchand, mais pas les informations sur le marchand.

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

• Exigence : lorsqu'un utilisateur quitte le site Web du marchand d'origine et effectue un achat via votre plate-forme auprès d'un autre marchand.
  • Valeur de modification du marchand : 1
• Exigence : lorsque l'utilisateur effectue une transaction auprès du marchand d'origine.
  • Valeur de 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. Cela 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 vérifier le suivi des conversions

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

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

Cas de test	Description du test	User flow	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 sans redirection existante. Cela ne devrait pas entraîner d'événement de conversion.	Aucun événement de conversion , car l'utilisateur n'a pas visité la page de réservation auparavant ou n'a pas été redirigé par Google.
2	Un utilisateur effectue une réservation qui a été initiée sur Google.	Un utilisateur trouve votre marchand via Google, est redirigé vers votre page de réservation et effectue une réservation.	Un événement de conversion est envoyé avec le jeton A et la valeur merchant changed de 2 , 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 : Laissez 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 n'effectue pas de 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 flux 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 et toute conversion effectuée pendant cette période doit renvoyer un événement de conversion.	Un événement de conversion est envoyé avec le jeton B et la valeur merchant changed de 2 , car l'utilisateur revient sur la page de réservation après une redirection précédente de 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'une redirection Google après une redirection Google précédente, sa période de stockage de 30 jours est réinitialisée et un nouveau jeton C remplace l'ancien B. Toutes les conversions futures seront ensuite attribuées au jeton C.	Un événement de conversion est envoyé avec le jeton C et la valeur merchant changed de 2 , car l'utilisateur a effectué la réservation et le nouveau jeton a remplacé le jeton précédemment stocké.

Si votre plate-forme permet aux utilisateurs de payer auprès d'un autre marchand, effectuez le test suivant.

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 à un utilisateur de changer de marchand. Cela 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. Si vous êtes l'un de ces partenaires, vous pouvez ignorer les cas de test suivants.

Cas de test	Description du test	User flow	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 d'effectuer une réservation, il accède à une autre page et effectue la réservation auprès d'un marchand différent de celui de la redirection d'origine.	Un événement de conversion est envoyé , car l'utilisateur a effectué une réservation provenant d'une redirection de Google avec le jeton A et la valeur merchant changed de 1 , car l'utilisateur a effectué la réservation auprès d'un marchand différent de celui de la redirection.

Pendant le test, 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 liens d'action ou des URL de page de réservation que vous fournissez dans vos flux.

Jeton A :

rwg_token=AFd1xnHrJWKcjtriCyB5j3QL0bzbmLdcg1N1f5cJuSNVhteYjuOJz18Au6GIAT0tjHkw6fkUJKcarafV45b3c_gl7uT_o8HMcg%3D%3D

Jeton B :

rwg_token=AE37R_gte8WCEaytMalsIr9agWQRLuN8199RsVhU2WoRKRvcZ0eBTD8cFvnfUZh-GY0IvY-zjS3W9KWAmy3WDiWXbVvQRZyzMQ%3D%3D

Jeton C :

rwg_token=AE37R_jmAP-UgWNApkxwdlX5M2z1UBGuUzHZ63YWmRWeTjRJKxfSD1mzJ4joLnB11MHrBULuisjP-9I64LnBJDXyCc_CIJSCPg%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 : Les conversions peuvent mettre jusqu'à une heure à s'afficher 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 d'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 pour un lieu et passe une commande auprès du même marchand au cours de la même session. Valeur de modification du marchand = 2.
• Un utilisateur suit un lien d'action pour un lieu, puis revient d'un autre canal dans la période d'attribution de 30 jours pour passer une commande auprès du même marchand. Valeur de modification du marchand = 2.
• Un utilisateur suit un lien d'action pour 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. Valeur de modification du marchand = 1.

De plus, Google s'attend à envoyer des événements de conversion depuis n'importe quel appareil auquel un utilisateur peut accéder via un lien d'action pour un lieu. Appareils concernés :

• Applications Web pour ordinateur ou mobile.
• Applications mobiles, via un lien profond d'application ou une intention d'application enregistrée pour votre domaine.

Si le jeton est stocké au niveau de l'utilisateur, vous devez fournir une 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 un 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 de navigateur, vous n'avez pas besoin de fournir une attribution multi-appareils. 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 manière dont votre système d'analyse attribue les conversions. Ce système est conçu pour fonctionner indépendamment de tout suivi des conversions que vous effectuez dans vos systèmes et n'a pas besoin d'affecter votre analyse interne.