Pourquoi les événements navigateur et serveur se complètent
Le suivi dans le navigateur décrit l’activité pendant une visite : la page de destination, les produits consultés, les actions sur le panier et le paiement. Le suivi côté serveur peut confirmer qu’une commande a été enregistrée, même lorsqu’un événement d’achat du navigateur est incomplet.
Les deux sources répondent à des questions différentes. Un achat côté back-end peut confirmer la transaction sans disposer des identifiants du navigateur nécessaires pour le relier à une publicité. WeProfit les réunit lorsque les données disponibles permettent une correspondance.
Le chemin de votre boutique à un réseau publicitaire
Pour Shopify, les webhooks de la plateforme fournissent les informations de commande. Pour WooCommerce, le plugin WeProfit envoie des événements de commande signés côté serveur. WeProfit traite les événements de la boutique et transmet les événements de conversion pris en charge aux destinations que vous connectez.
- Collecter le parcours d’achat et les identifiants disponibles.
- Recevoir la confirmation de commande de la plateforme e-commerce.
- Associer l’achat aux éléments disponibles sur le parcours.
- Acheminer les événements pris en charge vers la destination publicitaire prévue.
- Examiner le statut d’envoi et les diagnostics de la destination.
Un même achat peut arriver par plusieurs chemins
L’achat d’un client peut être observé dans le navigateur et confirmé par la boutique. Les identifiants d’événements aident à distinguer les envois répétés des commandes distinctes. WeProfit utilise des identifiants d’achat déterministes et la déduplication dans son traitement.
Vérifiez tout pixel navigateur, application de canal ou intégration serveur indépendants déjà installés. Faire correspondre vos propres sources ne réconcilie pas automatiquement un émetteur tiers qui utilise d’autres identifiants d’événements.
Ce que le suivi côté serveur ne résout pas
L’envoi côté serveur ne garantit ni un suivi complet, ni des rapports identiques, ni l’attribution de chaque commande par les plateformes publicitaires. Les choix de consentement, les identifiants indisponibles, les erreurs de connexion et les règles de traitement de chaque réseau influencent toujours le résultat.
Traitez la collecte, l’envoi et l’attribution comme des vérifications distinctes. Confirmez que la commande existe, vérifiez que l’événement a été envoyé, puis examinez comment chaque rapport attribue la vente. Il est ainsi plus facile de trouver un problème de configuration sans supposer que chaque écart de reporting est un achat perdu.
Vérifiez séparément la collecte, le consentement et l’acceptation par la destination
Une connexion serveur ne dispense ni du contexte du navigateur, ni d’une configuration de destination valide, ni d’une gestion appropriée du consentement. Des identifiants de clic manquants peuvent toujours limiter la correspondance côté réseau. Une nouvelle tentative doit réutiliser l’identifiant d’événement d’origine, alors que des intégrations indépendantes peuvent utiliser des identifiants incompatibles.
| Observation | Interprétation |
|---|---|
| Une commande serveur arrive | La commande a atteint WeProfit ; l’identification de la campagne peut encore être incomplète. |
| Une destination accepte la requête | La transmission a réussi ; l’attribution et les rapports dépendent toujours de la destination. |
| Une commande a un niveau de confiance « exact » | Un lien direct existe ; cela ne prouve pas que la publicité a provoqué la vente. |
| La bannière de consentement de la vitrine s’affiche | La bannière est visible ; testez que ses choix atteignent réellement le suivi navigateur et serveur. |