ConnectWiz + Meta Conversions API

Intégration en production

La publicité qui a lancé la conversation apprend comment elle s’est terminée

Les publicités de messagerie optimisent à l’aveugle tant que personne ne dit à Meta ce qui a converti. ConnectWiz remonte les affaires gagnées sous forme d’événements Purchase — avec leur vraie valeur et l’identifiant propre à chaque canal — vers votre propre jeu de données Events Manager, derrière quatre verrous, chaque refus étant consigné.

Votre jeu de données, votre token Quatre verrous — le consentement d’abord Les refus consignés avec leur motif
Meta Conversions API × ConnectWiz
Pas de correspondance ? Abandonné, pas deviné
Verrou : le consentement autorise l’usage publicitaire
Identité rapprochée canal par canal
Purchase + valeur → votre jeu de données
13
Noms d’événements standard — un vocabulaire fixe, parce que la liste de noms d’un jeu de données est définitive
4
Verrous avant qu’un événement ne parte — activé, consentement, bien formé, pas déjà envoyé
100%
Des refus consignés avec un motif nommé — « nous n’avons pas envoyé » est un fait visible
24 h
Garde-fou local de dédoublonnage — volontairement plus court que la fenêtre de 48 heures de Meta

Publicité

Ce qu’il fait — précisément

Les affaires deviennent des signaux

Gagner une affaire remonte un Purchase avec sa vraie valeur ; passer dans une étape associée déclenche l’événement que vous avez choisi — quel que soit le chemin : écran, automatisation ou import.

L’identité, faite correctement

WhatsApp utilise le click ID, Messenger l’identifiant à portée de Page, Instagram le sien — la clé de rapprochement propre à chaque canal, hachée comme Meta le spécifie.

Quatre verrous, une seule porte

Le locataire est-il activé ? Le consentement autorise-t-il le ciblage publicitaire ? L’événement est-il bien formé et rapprochable ? N’a-t-il pas déjà été envoyé ? Chaque refus est consigné avec son motif — auditable, pas mystérieux.

Un panneau de santé

Voyez ce qui est parti, ce qui a été refusé et pourquoi — une tuyauterie de conversion que vous pouvez réellement inspecter.

Les événements de Meta, renvoyés comme il faut

Les achats que Meta détecte dans le fil sont renvoyés avec la valeur décodée depuis la propre échelle de Meta et l’identifiant d’événement dérivé du message — si bien qu’une reprise de webhook se replie au lieu de compter une deuxième vente. Un montant inconnu n’envoie aucune valeur du tout : un faux zéro dirait à Meta que la conversion ne valait rien.

La bonne forme, nommée

Les événements sont validés avant l’envoi — longueur du nom, horodatages futurs ou périmés, budget de paramètres, rapprochabilité — et chaque manquement devient un refus nommé dans le journal, pas un mystère.

Côté technique

La tuyauterie de conversion, faite avec soin

Pourquoi les noms d’événements sont figés

Un jeu de données Meta accepte 1 000 noms d’événements distincts, définitivement — ils ne peuvent pas être supprimés, et une fois le plafond atteint, plus rien de nouveau n’est enregistré. Les noms d’événements viennent donc d’un vocabulaire fixe, et la variation vit dans les paramètres, là où est sa place.

Des identifiants d’événement déterministes

L’identifiant de chaque événement dérive de ce qu’il décrit, pas du hasard — une reprise produit donc le même identifiant et se dédoublonne, au lieu de compter deux fois la même vente. Le hasard ruinerait tout le mécanisme.

Marqué envoyé seulement après l’acceptation de Meta

L’enregistrement local de dédoublonnage est écrit après l’acceptation de Meta, jamais avant — une panne réseau donne lieu à une reprise ; elle ne peut pas s’auto-supprimer en conversion perdue.

Une normalisation identique à celle de Meta

Les e-mails passent en minuscules, mais les points Gmail et les étiquettes en +tag sont conservés — parce que c’est ce que fait Meta. Un numéro de téléphone doit se résoudre en 8 à 15 chiffres avec un pays ; un numéro local sans indicatif est abandonné, pas deviné. Une clé abandonnée coûte un rapprochement ; une mauvaise clé coûte une mauvaise personne.

L’identité canal par canal, précisément

Les événements WhatsApp portent le click ID et le numéro — le click ID est légitimement absent sur certains emplacements, et le numéro y survit. L’identité Messenger ne compte que si la Page et l’utilisateur à portée de Page sont présents ensemble ; Instagram utilise son propre identifiant à portée limitée ; les événements de prospect portent l’identifiant de prospect de la plateforme, réservé aux prospects d’origine Meta.

Un panneau de santé qui assume ses calculs

Fraîcheur, fréquence des événements, couverture des clés de rapprochement fortes, valeurs d’achat et motifs de refus — mesurés sur une fenêtre de 28 jours et présentés comme nos mesures, parce que faire passer nos calculs pour le score de Meta nous inventerait une autorité que nous n’avons pas.

Mise en place

Comment ça se connecte

01

Collez votre jeu de données

L’identifiant et le token de votre jeu de données Events Manager — chiffrés, à vous, révocables.

02

Associez vos étapes

Choisissez quelles étapes de pipeline déclenchent quels événements de conversion.

03

Gagnez des affaires

La remontée se fait toute seule — sous verrou, dédoublonnée, consignée.

Mieux ensemble

Avec quoi il se combine

Les pipelines du CRM

Les affaires gagnées et les étapes de pipeline que vous avez associées sont ce qui déclenche les événements — l’entonnoir que vous faites déjà tourner est la source du signal.

Les publicités click-to-message

Les campagnes qui atterrissent sur WhatsApp, Messenger ou Instagram savent enfin quelles conversations sont devenues du chiffre d’affaires.

Les publicités à formulaire

Les formulaires de prospects Meta arrivent déjà dans le CRM — cette intégration boucle la boucle en renvoyant la qualité des prospects vers le compte publicitaire.

Sécurité et garanties

Les garanties ennuyeuses

Votre jeu de données, votre token

Les événements partent vers le jeu de données que vous collez depuis votre propre Events Manager — le token d’accès est chiffré au repos et n’est jamais réaffiché. La relation sur les données est entre votre entreprise et Meta.

Le consentement est un verrou, pas un réglage

Un événement ne part que si le consentement du contact autorise le ciblage publicitaire — un double opt-in encore en attente ne compte pas, et le refus est consigné par son nom.

Le mode test se voit

Un code d’événement de test oublié empêcherait en silence les vraies conversions d’être comptées — le mode test apparaît donc comme un indicateur à part entière dans le panneau, impossible à oublier sans le voir.

La question du double comptage, posée

Si vous faites déjà tourner une CAPI ou un Signals Gateway, envoyer d’ici aussi compterait deux fois — le dédoublonnage ne peut rien face à deux identifiants différents pour une même vente. Le panneau pose la question ; sans réponse, il avertit plutôt que de supposer.

Les petits caractères, en clair

Les limites, annoncées

Aucune identité devinée

Un numéro de téléphone sans indicatif pays est abandonné, pas deviné — un mauvais rapprochement dépense la vie privée de quelqu’un d’autre. Et une affaire sans valeur n’envoie rien, jamais un faux zéro.

« Désactivé » est un état valide

L’intégration est livrée désactivée ; désactivée n’est pas un mode dégradé. Vos données publicitaires ne partent que lorsque vous décidez qu’elles doivent partir.

FAQ Meta Conversions API

Des réponses directes

Tout le reste est dans la FAQ, ou écrivez-nous directement.

Des événements Purchase pour les affaires gagnées (avec leur vraie valeur et l’identité propre au canal), les événements de conversion que vous associez aux étapes de pipeline, et des signaux de qualité de prospect issus de votre entonnoir CRM — le tout vers votre propre jeu de données, dédoublonné face à la détection de Meta.

C’est l’un des quatre verrous : un événement ne part que si le consentement du contact autorise l’usage publicitaire. Les événements refusés sont consignés avec leur motif, si bien que « nous n’avons pas envoyé » est un fait visible.

Non — vous collez l’identifiant et le token d’accès de votre propre jeu de données Events Manager. La relation sur les données est entre votre entreprise et Meta ; nous sommes la tuyauterie, avec ses verrous.

E-mails, numéros de téléphone, noms, ville, région, code postal, dates de naissance et identifiants externes sont hachés en SHA-256 après une normalisation identique à celle de Meta. Les click IDs, les identifiants de navigateur, les identifiants à portée de Page et les identifiants de prospect partent tels quels — ils sont déjà opaques, et Meta les recherche à la lettre ; les hacher les détruirait.

Oui — c’est précisément pour cela que l’intégration pose la question. Deux expéditeurs avec des identifiants d’événement différents, pour Meta, ce sont deux ventes. Si vous déclarez un autre expéditeur, vous choisissez lequel possède quels événements ; sans réponse, le panneau avertit plutôt que de supposer.

Mieux vaut une intégration honnête qu’une intégration tapageuse.

Chaque intégration est décrite par ce qu’elle fait vraiment — sens de la synchronisation, propriété des données et limites comprises.