Tracking V2 : événements et dépannage

Tracking V2 distingue les actions du navigateur et les événements métier d’edoobox. Un clic sur « Réserver » n’est pas encore un achat confirmé ; un encaissement n’est pas automatiquement un second achat. Utilisez cette distinction pour les rapports et les objectifs de conversion.

Événements du navigateur dans le parcours de réservation

Événement	Déclencheur
view_item_list	Une consultation réelle d’une offre ou d’une liste.
view_item	Une consultation réelle du détail d’une offre.
select_item	Un clic sur un lien de détail d’offre.
add_to_cart	Une augmentation réelle d’une quantité de prix ou de prestation complémentaire. Les quantités inchangées ou réduites ne produisent pas ce déclencheur.
begin_checkout	La première étape de réservation affichée, une fois par opération et par session de navigateur.
add_payment_info	Le choix d’un mode de paiement ou l’envoi du mode présélectionné.
waitlist_join	Point d’intégration autorisé ; la confirmation métier de l’inscription en liste d’attente est déterminée côté serveur.

Dans le dataLayer, les déclencheurs V2 se nomment edoobox_v2_<ereignis>. edoobox_event_name et edoobox_analytics_version: 2 sont également disponibles. Le conteneur exporté transmet les noms standard autorisés. En mode iFrame, ces événements arrivent dans le dataLayer du site parent via le canal vérifié.

Les noms, adresses e-mail et valeurs libres des formulaires ne sont pas repris comme paramètres généraux du parcours.

Achat, paiement et annulation des opérations

Événement	Signification
purchase	Réservation finalisée et confirmée, sans statut de liste d’attente, MustPay ou annulation.
payment	Un paiement réel dans l’opération correspondante.
booking_cancelled	Annulation de la réservation.
refund	Remboursement enregistré ou annulation métier de l’opération.

Une finalisation MustPay ou une inscription en liste d’attente ne doit pas déjà être analysée comme achat définitif. Si le statut change ultérieurement, l’analyse doit tenir compte de l’état réel.

Les valeurs d’achat Google distinguent la valeur nette (value), la taxe (tax) et la valeur brute (booking_gross_value). L’identifiant de transaction associe la référence publique de réservation à la devise. Une réservation comportant plusieurs devises ne doit donc pas être regroupée en une somme unique arbitraire à partir d’un simple clic dans le navigateur.

Différences entre les prestataires

Google Analytics : reçoit les événements autorisés à cet effet avec le contexte analytique recueilli.
Microsoft Ads : reçoit l’achat, le paiement, l’annulation, le remboursement et la liste d’attente sous forme d’événements personnalisés distincts.
ChatGPT / OpenAI Ads : reçoit l’achat comme order_created et les autres états comme événements personnalisés.

Chez Microsoft et OpenAI, les événements d’annulation ou de remboursement ne retirent pas automatiquement une conversion d’achat initiale. Configurez vos objectifs de sorte que les événements de paiement supplémentaires ne comptent pas comme de nouveaux achats.

Derniers événements et contrôle de connexion

Ouvrez Paramètres → Google & e-commerce → Suivi côté serveur V2.
Sous Derniers événements, vérifiez le prestataire, le nom de l’événement, la réservation associée, le statut, le code d’erreur et la date.
Après avoir modifié les identifiants d’accès, vérifiez d’abord la connexion ou la configuration enregistrée.
Comparez ensuite une opération contrôlée au rapport réel du système cible.

La portée d’un contrôle réussi diffère selon le prestataire : Google vérifie l’appel de validation et ses retours ; Microsoft vérifie localement que la configuration est complète ; OpenAI valide sans enregistrer d’événement de conversion. Aucun de ces affichages ne garantit à lui seul une attribution ultérieure dans un rapport.

Même l’acceptation HTTP par un prestataire ne prouve pas encore un traitement complet. Si une transmission est incertaine, une nouvelle réservation ne doit pas servir de répétition technique.

Cerner les erreurs fréquentes

Observation	Vérifiez
Aucun événement de navigateur	Configuration V2 active, balise Google pour le même identifiant de mesure, consentement, conteneur web V2 et assistant du site web.
L’iFrame n’envoie aucun contexte	Identifiant exact de l’iFrame, bookingOrigin, identifiant de mesure, choix des prestataires et paramètre de référent. Actualisez l’assistant après une modification de la CMP.
Parcours présent, achat absent	Statut définitif de réservation, configuration cible enregistrée, contexte autorisé et liste des événements côté serveur. La liste d’attente et MustPay ne constituent pas un achat définitif.
Achat compté deux fois	Vérifiez les anciennes balises d’achat edoobox, les autres pixels de navigateur et les objectifs de conversion pour payment/refund.
Événement publicitaire absent	Prestataire actif, son accès, option du prestataire sur le site web et autorisations séparées pour ad_storage et ad_user_data.
La destination reste incorrecte après modification	Enregistrement dans edoobox et configuration appropriée de l’assistant sur le site web ; chaque instance intégrée doit appartenir au compte prévu.

Pour une demande de support, le compte, le prestataire, la référence de réservation, la date et le code d’erreur visible suffisent. N’envoyez pas de secrets API ni de contenus de requête non expurgés contenant des données de participants.

Exemple : analyser séparément liste d’attente et paiement

Un séminaire complet génère d’abord une inscription en liste d’attente. L’équipe la compte comme intérêt, et non comme achat. Un achat n’est attendu qu’après sa transformation en réservation confirmée. Un paiement bancaire ultérieur est un encaissement. Le rapport ne compte donc pas de nouveau la personne comme nouvel achat à chaque changement d’état.

Suite : Configurer Tracking V2 · Relier iFrame et consentement

Éviter les transmissions incertaines et les conversions en double

Un délai d’attente peut expirer après l’acceptation d’un événement. N’utilisez ni une nouvelle réservation ni une conversion artificiellement redatée pour répéter un envoi incertain. Faites vérifier l’identifiant de l’événement, la date, la destination et le statut visible à partir de la même opération.

Si un pixel de navigateur Microsoft ou OpenAI supplémentaire signale la même conversion, la déduplication prévue nécessite des identifiants et noms d’événement correspondants. Sans mise en œuvre délibérément coordonnée, désactivez l’envoi parallèle de conversion pour la même finalisation. Un objectif payment considéré comme autre achat génère également un comptage multiple erroné.