GA4 et les KPI qui comptent vraiment en COD

Pourquoi GA4 ment sur une boutique COD

GA4 n'est pas défectueux : il fait exactement ce pour quoi il a été conçu — compter des événements dans le navigateur. Le problème, c'est qu'en e-commerce à l'international il a été pensé pour un monde où « commander » égale « payer » : la carte est débitée à l'instant du clic, la conversion est une vente. En Algérie, en paiement à la livraison, le clic « commander » n'est que le début d'un long parcours : appel de confirmation, expédition, livraison, encaissement en cash à la porte. GA4 s'arrête au premier maillon et déclare victoire.

Concrètement, GA4 enregistre une « conversion » et ajoute le montant du panier au « revenu » dès que le formulaire part. Mais une part notable de ces commandes ne se transforme jamais en argent : numéros injoignables, clients qui changent d'avis, colis refusés à la réception. Une fois ces pertes retirées, le chiffre et le ROAS affichés dans GA4 sont souvent surévalués de l'ordre de 30 à 50%. Si vous pilotez votre budget publicitaire sur ces chiffres bruts, vous investissez sur des ventes qui n'existent pas encore — et parfois n'existeront jamais.

Les KPI qui comptent vraiment (et leurs ordres de grandeur)

Oubliez le tableau de bord par défaut de GA4. Une boutique COD se pilote avec six chiffres, et un seul est le juge de paix : le coût par commande livrée. Les fourchettes ci-dessous sont des ordres de grandeur observés chez des marchands algériens — votre niche, votre wilaya de livraison et la qualité de votre trafic les font varier fortement. Prenez-les comme des repères, pas comme des promesses.

Les trois événements à suivre absolument

Pour rendre la mesure honnête, il faut suivre le parcours au-delà du clic « commander ». Trois événements forment le squelette d'un entonnoir COD ; on y ajoute des étapes amont pour diagnostiquer les abandons. Chaque événement doit porter le même identifiant de commande, sinon impossible de recoller la livraison à sa source de trafic.

Remonter les commandes livrées : le chaînon manquant

Tout ce qui précède ne sert à rien si l'information « ce colis a été livré et payé » ne revient jamais dans votre mesure. C'est le chaînon que la plupart des boutiques algériennes oublient. La donnée existe pourtant : elle est dans le statut de vos transporteurs (Yalidine, ZR Express, Noest, Maystro), souvent centralisé via Ecotrack ou accessible par API. Il faut la capter et la renvoyer à GA4 et à vos régies avec le bon identifiant de commande.

Trois voies existent, de la plus artisanale à la plus solide. L'import de conversions hors ligne : vous téléversez périodiquement dans GA4 la liste des commandes livrées. Le Measurement Protocol : votre serveur envoie l'événement « livré » à GA4 dès que le statut transporteur bascule, en temps quasi réel. Le tag côté serveur (server-side GTM) : une couche centrale qui reçoit vos événements et les rejoue proprement vers GA4, Meta et Google Ads. Plus on monte en robustesse, plus la mesure devient fiable — et plus les algorithmes des régies apprennent à chercher des acheteurs qui réceptionnent, pas des curieux qui remplissent un formulaire.

Un tableau de bord simple à tenir chaque semaine

Le meilleur tableau de bord n'est pas le plus riche, c'est celui que vous regardez vraiment. Un seul écran, mis à jour chaque lundi, qui répond à une question : où en est mon coût par commande livrée, et quelle source le tire vers le haut ou vers le bas ? Voici la marche à suivre.

1. 01

   Fixez vos définitions avant tout

   Décidez noir sur blanc ce qu'est une commande « confirmée » et « livrée » chez vous, et sur quelle fenêtre vous les comptez. Sans définition partagée, chaque chiffre devient discutable et le tableau de bord perd toute valeur. Écrivez ces règles une fois, appliquez-les partout.

2. 02

   Posez le suivi web + serveur

   Installez GA4 côté client pour le trafic et les commandes passées, et un suivi côté serveur pour la confirmation et la livraison. Assurez-vous qu'un identifiant de commande unique circule du clic web jusqu'au statut du transporteur, sinon rien ne se recolle en aval.

3. 03

   Remontez les commandes livrées

   Reliez le statut de vos transporteurs (souvent via Ecotrack ou l'API du transporteur) pour renvoyer l'événement « livré » à GA4 par import de conversions ou Measurement Protocol. C'est ce branchement qui transforme des données d'intention en données de vente.

4. 04

   Un tableau simple, tenu chaque semaine

   Une seule vue : sessions, commandes passées, confirmées, livrées, coût par commande livrée et panier moyen — le tout ventilé par source de trafic. Pas dix rapports : un seul, lisible en trente secondes, mis à jour chaque lundi.

5. 05

   Décidez sur le coût par commande livrée

   Coupez ce que vous voulez sur une base saine : une source au coût par commande livrée trop élevé, une landing qui convertit mais dont les colis reviennent. Ne jugez jamais un canal sur son CPC ou son taux de conversion GA4 seul — attendez le verdict du colis livré.

Questions fréquentes sur GA4 et le COD en Algérie

• Q01Pourquoi dit-on que GA4 « ment » sur une boutique en paiement à la livraison ?

  Parce que GA4 mesure une intention, pas une vente encaissée. Quand un visiteur soumet le formulaire de commande, GA4 enregistre une « conversion » et ajoute le montant au « chiffre » — mais en COD, cette commande n'est ni confirmée par téléphone, ni livrée, ni payée. Une part importante des commandes passées se volatilise ensuite : numéros injoignables, clients qui se rétractent, colis refusés à la porte. Résultat, le revenu et le ROAS affichés dans GA4 sont souvent gonflés de 30 à 50% par rapport à ce qui rentre réellement en caisse. GA4 n'est pas cassé : il fait ce pour quoi il est conçu (compter des événements web), mais il ignore tout ce qui se passe après le clic « commander », là où se joue justement la rentabilité en Algérie.

• Q02Quels sont les vrais KPI à suivre pour une boutique COD algérienne ?

  Six chiffres pilotent réellement une boutique en paiement à la livraison. Le taux de confirmation (commandes validées par téléphone ÷ commandes passées), souvent 60 à 85% selon la qualité du trafic. Le taux de livraison (colis réceptionnés et payés ÷ commandes confirmées), souvent 70 à 90% selon la wilaya et le produit. Le coût par commande LIVRÉE, qui est votre seul vrai coût d'acquisition. Le panier moyen des commandes livrées, pour vérifier la marge. Le taux de conversion de la landing (commandes passées ÷ sessions), souvent 1 à 4% en COD. Et enfin la source de trafic qui LIVRE le mieux, pas celle qui clique le plus — Google, Meta et TikTok n'ont pas du tout les mêmes taux de livraison en aval.

• Q03Comment mesurer le taux de confirmation et le taux de livraison dans GA4 ?

  GA4 seul ne les connaît pas, car ces deux étapes se passent hors du navigateur : la confirmation est un appel téléphonique, la livraison un événement du transporteur (Yalidine, ZR Express, Noest, Maystro). La méthode fiable consiste à renvoyer ces étapes à GA4 comme événements serveur : un événement order_confirmed quand votre équipe valide l'appel, et un événement order_delivered quand le statut « livré » remonte du transporteur ou d'Ecotrack. Vous pouvez aussi tenir ces taux dans un simple tableur relié à votre back-office, puis ne servir de GA4 que pour la partie web (trafic, sessions, commandes passées par source). L'important est que chaque commande porte un identifiant unique du clic web jusqu'au statut du colis, sinon vous ne pourrez jamais rattacher une livraison à sa source de trafic.

• Q04Qu'est-ce que le coût par commande livrée et pourquoi est-il roi ?

  Le coût par commande livrée, c'est votre dépense publicitaire divisée par le nombre de colis réellement réceptionnés et payés — pas par le nombre de commandes passées. C'est le seul chiffre qui reflète ce que vous coûte vraiment un client. Prenez un exemple d'ordre de grandeur : GA4 affiche un « coût par conversion » de 300 DA, mais si seulement 75% des commandes sont confirmées et 80% des confirmées livrées, votre vrai coût par colis livré est 300 ÷ (0,75 × 0,80), soit environ 500 DA. Deux canaux au même coût par conversion GA4 peuvent avoir un coût par commande livrée du simple au double selon leur taux de livraison. Tant que vous ne pilotez pas ce chiffre, vous optimisez sur une illusion.

• Q05Quels événements faut-il configurer dans GA4 pour une boutique COD ?

  Trois événements forment le squelette minimal d'un entonnoir COD. D'abord « formulaire soumis » (la commande passée), l'équivalent d'un purchase côté web, à déclencher à l'envoi du formulaire de commande. Ensuite « commande confirmée », un événement personnalisé envoyé côté serveur quand un opérateur valide la commande au téléphone. Enfin « commande livrée », l'événement le plus important, envoyé quand le transporteur marque le colis comme livré et payé. On y ajoute souvent des étapes en amont (vue produit, début de formulaire) pour mesurer le taux d'abandon. La règle : chaque événement doit porter un identifiant de commande et, idéalement, une valeur, pour que vous puissiez comparer le chiffre passé au chiffre réellement livré.

• Q06Comment remonter les commandes réellement livrées dans GA4 ?

  Il y a trois voies, de la plus simple à la plus robuste. La première : un import manuel ou par tableur des conversions hors ligne, où vous téléversez périodiquement la liste des commandes livrées rattachées à leur identifiant. La deuxième : le Measurement Protocol de GA4, qui permet à votre serveur d'envoyer directement l'événement order_delivered à GA4 dès que le statut du transporteur bascule. La troisième, la plus fiable : un tag côté serveur (server-side GTM) qui centralise les événements et les rejoue vers GA4, Meta et Google Ads avec le bon identifiant. Quelle que soit la voie, le prérequis est le même : conserver l'identifiant de commande de bout en bout et connecter le statut de vos transporteurs (souvent via Ecotrack ou l'API du transporteur). Sans cette remontée, GA4 et les régies optimisent sur des commandes passées — donc sur du vent.

• Q07GA4 suffit-il, ou faut-il vraiment un suivi côté serveur en COD ?

  GA4 seul suffit pour la moitié web du parcours : d'où vient le trafic, combien de sessions, quel taux de conversion vers la commande passée. Il ne suffit pas pour la moitié qui compte en Algérie — confirmation, livraison, encaissement — car ces étapes se produisent hors navigateur, au téléphone et chez le transporteur. Le suivi côté serveur comble ce trou : il capte l'événement là où il a réellement lieu (votre back-office, l'API transporteur) et le renvoie à GA4 avec le bon identifiant. C'est aussi plus fiable face aux bloqueurs de publicité et aux limites des navigateurs, qui font perdre une part des événements purement web. En pratique, une mesure COD sérieuse combine toujours les deux : GA4 côté client pour le trafic, le serveur pour la vérité du colis livré.

• Q08Dzecom peut-il configurer GA4 et le tracking COD pour ma boutique ?

  Oui, c'est un chantier que nous mettons en place régulièrement pour les marchands algériens. Nous posons GA4 proprement, configurons les trois événements clés du COD (formulaire soumis, commande confirmée, commande livrée), branchons le suivi côté serveur et remontons les commandes réellement livrées depuis votre back-office et vos transporteurs (Yalidine, ZR Express, Noest, Maystro via Ecotrack). Nous construisons ensuite un tableau de bord simple qui affiche vos vrais KPI — taux de confirmation, taux de livraison, coût par commande livrée, meilleure source — au lieu des chiffres gonflés par défaut. La configuration démarre à partir de 40 000 DA HT selon votre stack, et nous vous formons à lire ce tableau chaque semaine. Nous vous dirons aussi honnêtement quand un tableur bien tenu suffit et quand le serveur devient indispensable.