Une publicité Meta envoie l'utilisateur vers un canal ou un compte Telegram. À partir de ce clic, le pixel ne voit plus rien : ni l'adhésion, ni la conversation avec le closer, ni l'inscription chez le broker, ni le dépôt. Une campagne optimisée sur ce que le pixel mesure apprend donc à trouver des gens qui cliquent, pas des gens qui vont jusqu'au bout du parcours.
Pourquoi le pixel ne suffit pas
Le pixel est un script qui s'exécute dans un navigateur, sur une page que vous contrôlez. Telegram n'est pas cette page. L'adhésion à un canal, un message privé ou un dépôt chez le broker se produisent dans des environnements où aucun script Meta ne tourne.
La Conversions API contourne ce problème sans toucher au navigateur : l'événement est transmis de serveur à serveur, depuis l'outil qui connaît réellement l'adhésion, le lead ou le dépôt. ScaleGram envoie ces événements à Meta par la Conversions API (Graph API v23.0), côté serveur. Meta reçoit un événement accompagné d'identifiants qu'il peut rapprocher de ses propres utilisateurs et, lorsque le clic d'origine est connu, d'une publicité précise.
Cela ne règle pas tout. Ce qui est envoyé, à quel moment et avec quelles données change ce que Meta peut attribuer. C'est l'objet des sections suivantes.
La correspondance par défaut entre le CRM et Meta
Chaque étape suivie dans le CRM correspond à un événement standard de Meta. La configuration par défaut est la suivante :
- Adhésion au canal : Subscribe, activé.
- Demande d'adhésion : Subscribe, désactivé.
- Démarrage du bot : Lead, désactivé.
- Premier message privé : Contact, désactivé.
- Lead : Lead, activé.
- Inscription chez le broker : CompleteRegistration, désactivé.
- Dépôt : Purchase avec valeur, activé.
Chaque règle se modifie par pixel. Vous pouvez donc garder un pixel qui ne reçoit que les dépôts et un autre qui reçoit tout le parcours, selon l'usage que vous en faites dans le gestionnaire de publicités.
Deux paires méritent attention. La demande d'adhésion et l'adhésion envoient toutes deux Subscribe ; les activer ensemble revient à signaler deux étapes différentes sous le même nom. Le démarrage du bot et le lead envoient tous deux Lead, avec le même effet. Choisissez, pour chaque événement Meta, l'étape qui représente réellement le signal que vous voulez voir optimisé.
Le choix de l'objectif de campagne relève ensuite d'un arbitrage. Subscribe arrive tôt et souvent, mais il mesure une adhésion, pas une intention de déposer. Purchase est l'événement le plus proche de ce qui vous rémunère, mais il arrive plus tard et plus rarement. Aucun réglage ne supprime ce compromis.
Le dépôt ne part que lorsqu'il est confirmé
L'événement Purchase n'est envoyé que pour un dépôt confirmé. Trois situations le déclenchent : la création d'un dépôt directement au statut confirmé, le passage d'un dépôt de « en attente » à « confirmé », ou la remontée par la synchronisation CellXpert d'un dépôt net qui n'était pas déjà saisi dans le CRM. Un dépôt en attente ne produit rien côté Meta tant qu'il n'a pas été confirmé.
Le dépôt part avec sa valeur et une devise. La devise par défaut est celle des commissions de l'espace de travail, sinon USD. La valeur n'est transmise que si la règle du pixel le prévoit. Sans valeur, Meta reçoit un Purchase qui compte comme une conversion mais ne permet pas d'optimiser sur un montant.
Le cas CellXpert couvre un écart fréquent : un dépôt que le closer n'a pas saisi mais que la plateforme d'affiliation du broker enregistre. S'il est déjà présent dans le CRM, il n'est pas envoyé une seconde fois.
L'inscription dépend d'une étape que vous désignez
CompleteRegistration est désactivé par défaut, et aucune étape du pipeline n'est désignée comme étape d'inscription. Pour que l'inscription chez le broker parte vers Meta, il faut donc activer la règle sur le pixel et choisir, dans l'écran Tracking, l'étape du pipeline qui signifie que le lead s'est inscrit.
L'événement est alors envoyé lorsque le lead entre dans cette étape, ou lorsqu'une inscription est rapprochée par la synchronisation CellXpert. Il n'est envoyé qu'une fois par lead. Un lead qui quitte l'étape puis y revient ne génère pas de second CompleteRegistration.
Le choix de l'étape a des conséquences. Si votre pipeline mélange « lien d'inscription envoyé » et « compte ouvert », Meta recevra une inscription au moment où le lead n'a encore rien fait. L'étape désignée doit correspondre à une inscription effective chez le broker, pas à une intention.
Ce qui est envoyé à Meta pour chaque événement
L'email, le téléphone, le prénom, le nom et l'identifiant externe sont hachés en SHA-256 avant l'envoi. Les paramètres fbc et fbp, qui proviennent du clic publicitaire et des cookies Meta, sont transmis en clair, comme Meta l'attend. L'adresse IP et le user agent du clic sont également joints.
Un événement qui n'a ni fbc, ni fbp, ni email, ni téléphone n'est pas envoyé. Il est écarté avec la raison no_identifier. Meta ne pourrait de toute façon le rattacher à personne. En pratique, un membre arrivé sans clic identifié et qui n'a jamais communiqué d'email ni de téléphone ne produira aucun événement, quelle que soit l'étape qu'il franchit.
La qualité de l'appariement dépend donc de ce que vous collectez dans la conversation. Un lead dont le closer a obtenu l'email ou le téléphone donne à Meta davantage de moyens de le reconnaître qu'un lead dont on ne connaît que le pseudonyme Telegram.
Destination des événements et relances en cas d'échec
Les événements partent vers les pixels de la campagne d'origine du lead. Si aucune campagne n'est associée, ils partent vers les pixels par défaut de l'espace de travail. Un lead mal rattaché à sa campagne enverra donc ses événements au pixel par défaut, ce qui peut fausser la lecture si plusieurs comptes publicitaires coexistent.
Les envois échoués sont journalisés, puis relancés à 1, 5, 30, 120 et 720 minutes. Au-delà, ils sont abandonnés. Un jeton d'accès expiré ou un pixel mal configuré pendant plus d'une demi-journée fait perdre les événements de cette période. Consulter le journal des envois après toute modification de configuration évite de découvrir le problème une semaine plus tard dans le gestionnaire de publicités.
Vérifier avant de changer l'objectif de campagne
Un code d'événement de test peut être renseigné par pixel. Les événements apparaissent alors dans l'outil de test de Meta, ce qui permet de vérifier qu'une adhésion, un lead ou un dépôt arrivent avec le bon nom, la bonne valeur et la bonne devise avant de basculer une campagne sur cet objectif.
Chaque événement porte un event_id unique, utilisé par Meta pour la déduplication. Si le même événement lui parvient deux fois, Meta peut écarter le doublon au lieu de compter deux conversions.
Pensez à retirer le code de test une fois la vérification faite. Tant qu'il est renseigné, les événements de ce pixel sont traités comme des événements de test.
Ce que Meta ne pourra pas attribuer
La Conversions API transmet ce qui s'est passé. Elle ne recrée pas un clic qui n'a jamais été enregistré. Lorsqu'un utilisateur rejoint le canal par son lien public, après l'avoir vu partagé ailleurs ou recopié d'une publicité, il n'existe aucun clic d'origine. Meta peut recevoir l'événement si un email ou un téléphone l'accompagne, mais il ne peut pas le rattacher à une publicité.
Les chiffres de Meta et ceux du CRM ne coïncideront donc jamais tout à fait. Meta ignore les conversions sans clic attribuable et conserve les dépôts refusés après leur envoi. Le CRM enregistre l'un et l'autre. Pour décider de couper ou de maintenir une campagne, les dépôts confirmés et les commissions suivies dans le CRM restent la référence ; les rapports Meta indiquent sur quoi l'algorithme apprend, pas ce que la campagne a réellement produit.