Expertise · Automatisations marketing
Un environnement de travail dans lequel l’agent qui s’occupe de vos campagnes Google Ads et Meta lit les rapports, propose le changement avec le motif écrit et n’exécute que dans les limites que vous lui avez données.
Le service est une offre, pas une réalisation, et nous le disons en premier : nous n’avons pas aujourd’hui un système qui change des budgets ou des enchères dans Google Ads ou Meta. Nous avons construit et exécuté les pièces à partir desquelles on en fait un — l’envoi du signal de conversion réelle vers Google, un moteur qui achète de la promotion payante avec le dry-run activé par défaut, un registre qui écrit chaque action qui coûte, et un interrupteur qui arrête un orchestrateur sans voie de contournement.
Offre, avec conditions« offer », pas « delivered », et la raison se vérifie en quelques secondes. Nous avons recherché dans plus de 150 dépôts internes les champs par lesquels les API publicitaires déplacent de l’argent — `budget_micros`, `campaignBudget`, `target_cpa`, `target_roas`, `bid_strategy` — et ils n’apparaissent nulle part, ni chez Google, ni chez Meta. Nous ne gérons pas aujourd’hui de budgets publicitaires. Ce qui apparaît, et que l’on peut ouvrir fichier par fichier, ce sont les pièces qui séparent une automatisation d’un accident : l’envoi des conversions hors ligne vers Google via Data Manager API, 264 lignes dans un de nos projets de production ; un moteur de promotion payante qui achète des boosters, des étiquettes et des forfaits avec `dry-run` activé par défaut ; un testeur A/B bayésien qui refuse de déclarer un gagnant en dessous de 100 affichages par variante, et l’orchestrateur de campagnes dans MEGA CRM avec un interrupteur sans `--force`. Le service est décrit à partir de ces pièces. Pas à partir d’un panneau qui n’existe pas.
Un agent qui s’occupe des campagnes n’est pas un bouton sur lequel il est écrit « optimise ». C’est un programme qui a le droit de lire certains rapports, le droit d’écrire certains champs, et aucun autre droit. La partie difficile n’est pas de proposer un changement — les modèles le font bien et vite. La partie difficile est d’écrire où cela s’arrête, comment il prouve ce qu’il a fait, et ce qui se passe quand il se trompe. C’est de cela qu’il s’agit dans le travail, et c’est là que commence la discussion.
Nous disons dès le début ce que nous n’avons pas, pour que vous ne l’appreniez pas de quelqu’un d’autre. Chez nous, aujourd’hui, il n’exécute pas un système qui augmente un budget dans Google Ads ou qui modifie une enchère dans Meta. Ce qui s’exécute, et peut être montré ligne par ligne, ce sont les mécanismes de sécurité que nous avons écrits pour d’autres automatisations qui dépensent de l’argent réel : dry-run activé par défaut, compteur sur chaque action payante, temporisation en cas d’erreur pour que l’erreur ne se répète pas en boucle, seuil de preuve avant une décision, et un interrupteur qui refuse de démarrer l’orchestrateur.
La pièce que nous avons déjà construite n’est pas un changement de budget, mais un signal — et c’est celle par laquelle nous proposons de commencer. Google apprend de ce que vous lui dites être une conversion. Si vous lui dites « formulaire envoyé », il cherchera des personnes qui envoient des formulaires. Nous avons écrit l’intégration qui lui dit « demande réellement arrivée dans le système du client », avec l’identifiant du clic et des identifiants utilisateur passés par SHA-256, via Data Manager API. Cela peut commencer immédiatement, car c’est du code existant, pas une promesse.
Le reste de l’environnement de travail — la couche qui lit les rapports, la couche qui propose, la couche qui exécute — se construit selon le même schéma que celui que nous avons déjà utilisé là où nous avons déjà dépensé de l’argent par le code. On commence strictement par la lecture, on passe aux propositions sans exécution, et seulement à la fin on ouvre l’exécution, champ par champ, avec une limite écrite sur chacun.