Conversions en double dans Adgora : solutions

Conversions en double dans une campagne Adgora après un postback : comparaison des solutions

Une conversion peut apparaître deux fois alors que le visiteur n’a effectué l’action qu’une seule fois. Le doublon peut être dû à un postback envoyé plusieurs fois, à un point de terminaison qui accepte plusieurs fois le même événement ou à un rapport qui comptabilise un même événement à deux endroits. Pour identifier un doublon de conversion, retracez l’ensemble du parcours afin de déterminer à quel moment il apparaît, avant de modifier les paramètres de la campagne.

Cette comparaison porte sur trois méthodes pour éviter les doublons : la déduplication par identifiant d’événement, la vérification de l’identifiant de transaction et les règles basées sur une fenêtre temporelle. La bonne méthode dépend des identifiants fournis par votre intégration et de la possibilité pour les clients de convertir plusieurs fois de manière légitime. Une règle de déduplication trop large risque de supprimer de vraies ventes ou inscriptions. Pour comment éviter les conversions en double dans Adgora, commencez par repérer où les événements se répètent, puis choisissez une méthode adaptée à votre intégration.

Définir des critères avant de comparer les solutions

Évaluez chaque solution selon trois critères : bloque-t-elle les événements répétés, préserve-t-elle les conversions répétées légitimes et pouvez-vous la tester sans perturber les campagnes en cours ? Notez ces critères avant de modifier le flux de postback. Sinon, une baisse du nombre de conversions peut sembler positive alors que la règle a supprimé des activités légitimes.

Définissez ce qui constitue un doublon pour l’action mesurée. Pour un achat ponctuel, une même commande comptabilisée deux fois est probablement un doublon. Pour le renouvellement d’un abonnement, deux achats du même client à des moments différents peuvent être tous deux légitimes. La définition doit être propre à l’événement, et non simplement à la campagne.

Conservez les données nécessaires pour comparer les résultats : l’événement source, tout identifiant d’événement ou de transaction, les tentatives de postback, les réponses du point de terminaison et le rapport des conversions d’Adgora. Si un champ n’est pas disponible, consignez cette lacune au lieu de supposer que deux enregistrements correspondent à la même action. Un petit journal de test est plus utile qu’une vague impression selon laquelle les conversions « semblent gonflées ».

Retracer une conversion dans le flux de postback

Choisissez une conversion signalée et suivez-la depuis l’action initiale jusqu’au rapport. Commencez par l’événement source, par exemple une confirmation de commande, l’envoi d’un formulaire ou une action dans une application. Notez son horodatage et tout identifiant associé à ce stade. Retrouvez ensuite le postback correspondant et l’enregistrement au point de terminaison de réception.

Comparez les identifiants et les horodatages à chaque étape. Si la source ne contient qu’un événement, mais que le point de terminaison en compte deux identiques, le doublon est apparu entre l’envoi du postback et son enregistrement au point de terminaison. Si le point de terminaison ne contient qu’un enregistrement, mais qu’Adgora affiche deux conversions, examinez plutôt le processus de création du rapport ou d’importation au lieu de modifier la déduplication du point de terminaison.

Repérez précisément le point où les données divergent. Par exemple, un événement déclenché dans le navigateur et un autre côté serveur peuvent tous deux signaler le même achat, ou une nouvelle tentative peut atteindre un point de terminaison qui enregistre chaque requête comme un nouvel événement. Ces deux situations correspondent à des problèmes différents et nécessitent des solutions distinctes. Si les deux flux utilisent un identifiant d’événement commun, il sera plus facile de les rapprocher ; sinon, vous devrez peut-être en ajouter un à la source.

Consignez les étapes dans l’ordre : événement source, génération du postback, tentative d’envoi, réponse du point de terminaison, enregistrement stocké et rapport Adgora. Vous obtenez ainsi une séquence concrète à tester. Cela évite aussi un détour fréquent : accuser la campagne avant de vérifier si le point de terminaison a déjà créé deux enregistrements.

Comparer les stratégies de déduplication côte à côte

La déduplication des conversions par postback repose généralement sur un identifiant d’événement lorsqu’une même conversion peut être associée à un identifiant unique et stable, de la source jusqu’au destinataire. Le point de terminaison enregistre le premier événement, puis considère toute requête ultérieure portant le même identifiant comme déjà traitée. Vérifiez que l’identifiant reste inchangé lors des nouvelles tentatives et dans tous les flux — navigateur ou serveur — susceptibles de signaler la même action.

La vérification de l’identifiant de transaction peut être efficace pour les achats si chaque commande possède une référence stable. Elle convient moins aux formulaires de prospection, aux démarrages d’essai ou aux autres événements qui ne génèrent pas naturellement d’identifiant de transaction. Vérifiez également la portée de l’identifiant : une référence de transaction peut n’être unique qu’au sein d’un compte ou d’une boutique. La clé de déduplication devra peut-être inclure ce contexte.

Les règles basées sur une fenêtre temporelle constituent une solution de repli lorsque l’intégration ne dispose d’aucun identifiant d’événement ou de transaction stable. Elles peuvent regrouper des conversions similaires survenues à peu d’intervalle, mais « à peu d’intervalle » ne signifie pas « le même événement ». Un client peut effectuer deux actions légitimes pendant l’intervalle choisi. Optez pour l’intervalle le plus court qui permet de corriger le problème de doublons observé, puis testez les répétitions légitimes avant de généraliser la règle.

Pour les équipes qui examinent plus largement la mesure des campagnes, la même rigueur s’applique aux sources de trafic et aux définitions des conversions. Le guide des options de ciblage des réseaux publicitaires crypto d’Adgora peut aider à définir vos choix de ciblage, mais modifier le ciblage ne corrigera pas un doublon créé après l’arrivée du postback au point de terminaison.

Vérifier le comportement des nouvelles tentatives et des réponses

Un délai d’attente ne prouve pas qu’un postback a échoué. Le point de terminaison peut avoir enregistré l’événement sans renvoyer de confirmation claire, ce qui incite l’expéditeur à réessayer. Vérifiez la manière dont l’expéditeur gère les délais d’attente, les codes de réponse qui déclenchent de nouvelles tentatives et le fait que le point de terminaison renvoie une réponse uniquement après avoir enregistré l’événement.

Examinez les journaux réels des requêtes et des réponses avant d’attribuer les doublons aux nouvelles tentatives. Vérifiez le nombre de tentatives, les horodatages, les codes de réponse et si chaque tentative utilisait le même identifiant d’événement. Confirmez ensuite le comportement documenté du point de terminaison dans l’environnement utilisé.

Il y a ici une distinction importante. Si chaque requête répétée utilise le même identifiant et que le point de terminaison les enregistre toutes, le système de réception devra peut-être traiter les requêtes de façon idempotente. Si les requêtes répétées utilisent des identifiants différents pour une seule action source, cherchez où ces identifiants sont générés. La seule politique de nouvelle tentative ne peut pas expliquer cette différence.

Tester les solutions sur des cas de doublons et d’événements répétés

Avant de déployer une règle, testez deux cas contrôlés. Envoyez d’abord deux fois le postback d’une même conversion avec le même identifiant. Le résultat attendu est une seule conversion enregistrée. Ensuite, créez deux conversions légitimes avec des identifiants distincts, par exemple pour deux commandes séparées, et vérifiez qu’elles apparaissent toutes les deux.

Pour ces deux cas, comparez le journal source, le journal de transmission, les enregistrements au point de terminaison et le rapport Adgora. La solution n’est validée que si elle élimine l’événement répété sans supprimer le deuxième événement légitime. Si vous utilisez une règle basée sur une fenêtre temporelle, testez le cas de répétition à l’intérieur de l’intervalle proposé ; un test effectué au-delà ne permettra pas de voir si la règle est trop large.

Dans la mesure du possible, isolez le test pour qu’il n’influe pas sur l’optimisation en cours. Utilisez une campagne de test, un point de terminaison de préproduction ou un événement de test clairement identifié. Si un test en production est inévitable, convenez de l’événement et de la période d’observation avec les personnes responsables des rapports avant de l’envoyer.

Si les campagnes suivent également des actions dans une application, assurez-vous que le test reflète la manière dont ces événements sont envoyés. La présentation de la publicité crypto pour les campagnes d’installation d’applications peut donner des éléments de contexte sur la campagne, mais la vérification des doublons doit toujours suivre l’installation ou l’événement intégré à l’application concerné dans son propre flux de postback.

Déployer progressivement avec un plan de retour arrière

Commencez par un déploiement limité : un type d’événement, un point de terminaison ou une campagne de test. Avant de modifier la règle, enregistrez la configuration actuelle et notez les volumes de référence pour les événements source, les postbacks transmis, les enregistrements au point de terminaison et les conversions rapportées. Sans ces chiffres de référence, il sera difficile d’interpréter une baisse ultérieure.

Surveillez les deux aspects du problème. Une baisse du nombre de doublons n’est positive que si les conversions légitimes sont préservées. Surveillez les enregistrements manquants, les baisses inattendues des achats répétés, l’augmentation des erreurs de transmission ou les écarts entre les données stockées au point de terminaison et les rapports Adgora. Si vous observez l’un de ces signes, interrompez le changement et comparez les identifiants d’événement ou les références de transaction concernés.

Définissez clairement les conditions de retour arrière avant le lancement. Par exemple, annulez le changement si une conversion de test connue est supprimée ou si des événements répétés légitimes disparaissent du journal du point de terminaison. Conservez l’ancienne règle jusqu’à ce que la nouvelle ait été vérifiée à partir de données réelles de campagne.

Consignez les changements effectués, leur date et les types d’événements concernés. Cela permet de distinguer une correction du postback des modifications apportées à la campagne. La personne qui vous succédera pourra également rétablir facilement le comportement précédent si le nombre de conversions évolue de façon inattendue.

Conclusion : privilégier un identifiant propre à chaque événement

Utilisez un identifiant d’événement unique et stable lorsque l’intégration le permet et que le même identifiant peut être transmis de l’événement source au point de terminaison de réception. Le système destinataire peut ainsi reconnaître directement une requête répétée, sans considérer toutes les conversions rapprochées dans le temps comme des doublons.

Si aucun identifiant d’événement approprié n’est disponible, utilisez un identifiant de transaction pour les achats lorsque la référence est fiable. Pour les autres événements, une règle basée sur une fenêtre temporelle peut constituer la solution de repli la plus ciblée, mais vérifiez-la sur des conversions répétées légitimes avant son déploiement. En cas de conversions en double dans une campagne Adgora après un postback, la meilleure solution est celle qui supprime l’enregistrement répété tout en préservant la deuxième action réelle — et non celle qui se contente de réduire le total.