Mode d'emploi – Envoyer une valeur de profit protégée via Meta (Facebook CAPI)

🎯 Objectif

« Value Optimization for Profit » de Meta permet aux campagnes d’optimiser en fonction de la rentabilité au niveau de la commande plutôt que de la valeur d’achat.

C’est particulièrement pertinent lorsque les marges produit varient fortement et ne sont pas directement corrélées au prix de vente.

Value Optimization for Profit est actuellement disponible via le programme de partenaires gérés de Meta et n’est pas encore généralement accessible à tous les annonceurs.

Si vous souhaitez activer cette fonctionnalité, veuillez contacter votre interlocuteur Meta.

Meta vous permet d’optimiser les campagnes à l’aide d’une valeur métier via le paramètre :

👉 net_revenue

Cependant, de nombreux annonceurs préfèrent ne pas envoyer leur marge brute, car il s’agit de données hautement stratégiques.

👉 L’objectif est de :

• éviter d’exposer votre marge réelle

• tout en envoyant quand même un signal que Meta peut utiliser pour l’optimisation

Pour cela, nous allons créer une propriété dérivée :

👉 protected_profit_value

Cette valeur sera utilisée à la place de votre marge brute dans Meta CAPI.

Cette approche doit être considérée comme une indexation de la valeur de profit, et non comme une anonymisation irréversible.

Elle empêche l’envoi direct de la marge brute à Meta, mais si quelqu’un a accès à la fois à la marge d’origine et à la valeur indexée pour le même événement, la logique de transformation peut théoriquement être déduite.

---

⚠️ Prérequis

Avant d’implémenter la transformation, assurez-vous que les éléments suivants sont en place :

1. Disponibilité de la marge dans vos données

Vous devez avoir accès à votre marge, ou à votre net revenue, dans vos données.

👉 Cela se fait généralement via un import de catalogue produits, où la marge est incluse comme attribut produit.

2. Enrichissement des événements, événements Purchase

Votre purchase les événements doivent être enrichis avec ces informations de marge.

👉 Cela se fait généralement via une configuration d’enrichissement des événements, en faisant correspondre l’ID produit dans l’événement avec les données de votre catalogue.

📖 Documentation : https://doc.commandersact.com/features/data-quality/enrichment

3. Profit au niveau de la commande

Le modèle d’optimisation de Meta est conçu pour fonctionner avec le profit au niveau de la commande.

Si votre marge n’est disponible qu’au niveau produit, par exemple via le catalogue, vous devez vous assurer qu’un profit cohérent au niveau de la commande est disponible dans vos événements Purchase.

Cela peut être fait en utilisant Nettoyage des données en combinaison avec l’enrichissement des événements.

Une configuration courante est :

• importer la marge au niveau produit via un catalogue produits

• enrichir le purchase événement en faisant correspondre les ID d’articles d’événement avec les ID produits du catalogue

• utiliser une formule Data Cleansing pour agréger les marges au niveau des articles en une valeur de profit cohérente au niveau de la commande

• utiliser cette valeur de profit au niveau de la commande comme source pour protected_profit_value

👉 La valeur utilisée dans la transformation doit représenter le profit total de l’événement d’achat.

---

🧩 Étape 1 – Créer une transformation Data Cleansing, recommandé

👉 Il est fortement recommandé de définir la transformation dans Nettoyage des données, afin que :

• la logique soit centralisée

• elle puisse être réutilisée sur plusieurs destinations, autres CAPIs, analytics, etc.

• elle soit plus simple à maintenir

Étapes

1. Rendez-vous sur Data Quality > Data Cleansing

2. Créer une nouvelle transformation

3. Définir une nouvelle propriété :

👉 protected_profit_value

---

⚙️ Approches de transformation suggérées

Meta recommande d’envoyer des valeurs transformées en proportion de leur ratio exact et d’éviter autant que possible les approximations.

C’est important, car le modèle Value Optimization de Meta repose sur un modèle de régression qui prédit la valeur attendue. Par conséquent, l’amplitude compte, pas seulement le classement.

Autrement dit :

• préserver l’ordre signifie : profit plus élevé → valeur plus élevée

• préserver les ratios signifie : si un achat est deux fois plus rentable, la valeur envoyée à Meta doit aussi être deux fois plus élevée

👉 Meta recommande de préserver les ratios exacts entre les valeurs de profit.

C’est pourquoi une transformation proportionnelle est l’approche la plus sûre pour des performances optimales.

Plus la transformation s’écarte d’un index proportionnel, plus l’obfuscation peut devenir forte, mais plus elle peut aussi fausser le signal d’optimisation de Meta.

Voici trois approches possibles.

---

🟢 Option 1 – Index de profit proportionnel, recommandé par Meta

C’est l’approche recommandée lorsque la qualité de l’optimisation est la priorité.

IF(NUMBER(net_revenue) > 0, NUMBER(net_revenue) * K, NULL)

Où :

• net_revenue est le profit ou la marge brute au niveau de la commande.

• K est un facteur d’indexation secret propre au client.

• NULL signifie qu’aucune net_revenue valeur ne doit être envoyée pour les marges non positives.

Exemple avec K = 37.48291:

IF(NUMBER(net_revenue) > 0, NUMBER(net_revenue) * 37.48291, NULL)

Fonctionnement

La marge est multipliée par un facteur d’indexation propre au client.

Exemple :

• $10 → 374.8291

• $20 → 749.6582

• $40 → 1499.3164

👉 Résultat :

• les ratios exacts sont préservés

• Meta reçoit un signal d’optimisation de valeur propre

• la marge brute n’est pas envoyée directement

• Le reporting d’Ads Manager reste pertinent si vous connaissez le facteur d’indexation

Pourquoi cette approche est recommandée

Cette approche préserve les distances relatives exactes entre les valeurs de profit.

Exemple :

• $20 = 2× $10

• $40 = 4× $10

Après transformation :

• 749.6582 = 2× 374.8291

• 1499.3164 = 4× 374.8291

👉 C’est pleinement conforme à la recommandation de Meta.

Cette approche fournit une indexation confidentielle, pas une anonymisation irréversible.

Si quelqu’un a accès à la fois à la marge d’origine et à la valeur indexée pour le même événement, le facteur K peut théoriquement être déduit.

---

🟠 Option 2 – Index de profit avec offset, obfuscation avancée

Cette approche peut être utilisée lorsque l’annonceur souhaite une obfuscation plus forte et accepte une distorsion contrôlée du signal d’optimisation.

IF(NUMBER(net_revenue) > 0, (NUMBER(net_revenue) + C) * K, NULL)

Où :

• K est un facteur d’indexation secret propre au client

• C est un petit offset propre au client

• C doit rester faible par rapport à la plus petite marge positive significative

Exemple :

IF(NUMBER(net_revenue) > 0, (NUMBER(net_revenue) + 0.75) * 37.48291, NULL)

Fonctionnement

La marge est d’abord augmentée d’un petit offset, puis multipliée par un facteur d’indexation propre au client.

Exemple avec C = 0.75 et K = 37.48291:

• $10 → 402.9418

• $20 → 777.7709

• $40 → 1527.4286

👉 Résultat :

• les valeurs sont plus difficiles à interpréter qu’un simple facteur proportionnel

• le signal reste proche de la proportionnalité si C est faible

• cependant, les ratios exacts ne sont plus parfaitement préservés

Limitation importante

Ajouter C déforme les ratios.

Exemple avec C = 5:

• ratio réel : $100 / $10 = 10

• ratio transformé : ($100 + 5) / ($10 + 5) = 7

👉 Meta reçoit un contraste plus faible entre les achats à forte et à faible rentabilité que le contraste réel.

Cela peut réduire la qualité de l’optimisation, surtout lorsque C est grand par rapport aux faibles marges positives.

Règle recommandée pour C

À titre indicatif :

C ne doit pas dépasser 5 % à 10 % de la plus petite marge positive significative.

Exemple :

Si la plus petite marge positive significative est de 10 $ :

• conservateur C: $0.50

• borne supérieure C: $1.00

Cette option n’est pas l’approche recommandée par Meta pour des performances optimales, car elle ne préserve pas les ratios exacts.

Ne l’utilisez que lorsque l’annonceur accepte explicitement un compromis entre une obfuscation plus forte et un impact potentiel sur l’optimisation.

---

🔴 Option 3 – Score de profit par tranches, obfuscation maximale, non recommandé par Meta

Cette approche utilise des bandes de valeur plus larges pour rendre l’interprétation inverse plus difficile.

Elle ne doit être utilisée que lorsque les contraintes de confidentialité sont plus fortes que les exigences de performance.

IF(NUMBER(net_revenue) <= 0, NULL,
  IF(NUMBER(net_revenue) < 5, 40,
    IF(NUMBER(net_revenue) < 15, 120,
      IF(NUMBER(net_revenue) < 30, 220, 320)
    )
  )
)

Fonctionnement

La marge est transformée en bandes de valeur plus larges.

Exemple :

• 3 $ → 40

• 10 $ → 120

• 25 $ → 220

• 40 $+ → 320

👉 Résultat :

• la marge d’origine est beaucoup plus difficile à reconstruire

• les valeurs ne sont plus proportionnelles

• de nombreuses marges différentes reçoivent la même valeur

• le signal d’optimisation est remodelé

Pourquoi cette approche n’est pas recommandée par Meta

Cette approche préserve l’ordre, mais pas les ratios exacts.

Exemple :

• 10 $ et 14 $ deviennent tous deux 120

• 15 $ et 29 $ deviennent tous deux 220

• 40 $ et 400 $ deviennent tous deux 320

Cela crée plusieurs problèmes :

• les différences à l’intérieur d’une tranche sont perdues

• des sauts artificiels sont créés entre les tranches

• les achats à forte marge peuvent être sous-représentés

• les achats à faible marge peuvent être sur-représentés

• le modèle de régression de Meta reçoit un signal de valeur faussé

Meta recommande d’éviter les couches de transformation telles que le plafonnement, la compression, le bucketing ou le scoring basé sur des seuils lorsque l’objectif est d’obtenir des performances optimales de Value Optimization.

Cette option est disponible comme stratégie d’obfuscation maximale, mais elle peut réduire significativement la qualité de l’optimisation.

---

📊 Résumé des trois options

Option	Formule	Alignement avec Meta	Niveau d’obfuscation	Risque pour les performances
Option 1 – Index de profit proportionnel	marge × K	Excellent	Moyen	Faible
Option 2 – Index de profit avec offset	(marge + C) × K	Partiel	Moyen+	Faible à moyen
Option 3 – Score de profit par tranches	plage de marge → score	Faible	Élevé	Moyen à élevé

👉 Par défaut recommandé :

IF(NUMBER(net_revenue) > 0, NUMBER(net_revenue) * K, NULL)

👉 Utilisez l’Option 2 uniquement lorsque l’annonceur souhaite une obfuscation supplémentaire et accepte une distorsion contrôlée.

👉 Utilisez l’Option 3 uniquement lorsque la confidentialité est plus importante que les performances optimales.

---

⚠️ Gestion des marges nulles ou négatives

Pour des valeurs de marge nulles ou négatives, Meta n’a pas encore fourni de directives finales pour les valeurs négatives.

Jusqu’à ce que des directives finales soient disponibles, l’approche la plus sûre consiste à omettre net_revenue pour les marges non positives.

Logique recommandée :

IF(NUMBER(net_revenue) > 0, NUMBER(net_revenue) * K, NULL)

Lorsque net_revenue est omis :

• l’événement est toujours suivi comme conversion d’achat

• l’événement n’est pas utilisé pour l’optimisation du profit

• l’événement n’est pas comptabilisé dans le seuil d’éligibilité des 200 conversions

Assurez-vous que le retour de NULL dans votre transformation empêche effectivement l’envoi du net_revenue champ.

Si votre implémentation envoie encore le champ avec une valeur nulle ou vide, adaptez la logique de mapping afin que net_revenue soit omis pour les marges non positives.

---

📈 Impact sur le reporting d’Ads Manager

Ads Manager indiquera les valeurs indexées envoyées à Meta, et non les marges de profit d’origine.

Exemple :

Si vous envoyez :

protected_profit_value = profit_margin × 10

Alors le reporting dans Ads Manager reflétera des valeurs multipliées par 10.

Cela signifie que le reporting reste pertinent tant que l’annonceur connaît le facteur d’indexation.

Le reporting ROAS ou lié à la marge dans Ads Manager doit être interprété comme un reporting indexé, et non comme un reporting du profit brut.

---

🔗 Étape 2 – Mapper la valeur dans Meta CAPI

Dans votre destination Facebook Conversions API:

1. Ouvrez la configuration de votre destination

2. Accédez à la Mappage intelligent section

3. Associez les éléments suivants :

👉 net_revenue → protected_profit_value

1. Assurez-vous aussi que :

• currency est correctement associé

---

⚙️ Alternative – Transformation dans la destination

👉 Vous pouvez aussi définir la transformation directement dans :

Paramètres de destination → Transformation des propriétés

Cependant, c’est moins recommandé parce que :

• la logique n’est pas réutilisable

• elle est dupliquée pour chaque destination

👉 Utilisez cette approche uniquement pour des tests rapides ou des cas spécifiques.

---

✅ Résultat

Vous envoyez à Meta :

• a signal d’optimisation basé sur le profit

• sans exposer directement votre marge brute

👉 Meta peut :

• optimiser les campagnes en fonction de la valeur de profit attendue

• utiliser la valeur indexée comme signal d’optimisation de valeur

👉 Mais vos données stratégiques :

• ne sont pas envoyées sous leur forme d’origine

• sont protégées par une transformation propre au client

• ne sont pas directement lisibles comme une marge brute

La valeur envoyée via net_revenue sera utilisée par Meta à la fois pour l’optimisation et pour le reporting.

La valeur reportée dans Ads Manager est la valeur indexée envoyée à Meta, et non la marge brute d’origine.

---

💡 Bonnes pratiques

• Utilisez l’Option 1 par défaut

• Conservez la transformation stable dans le temps

• Utilisez un facteur K

• Évitez les facteurs ronds tels que 10, 100 ou 1000 lorsque c’est possible

• Évitez le plafonnement, la compression, le bucketing ou le scoring basé sur des seuils si la qualité de l’optimisation est la priorité

• Si vous utilisez l’Option 2, gardez C très faible par rapport à la plus petite marge positive significative

• Si vous utilisez l’Option 3, vérifiez clairement que l’annonceur accepte le compromis potentiel sur les performances

• Omettez net_revenue pour les marges non positives jusqu’à ce que Meta fournisse des directives finales

• Réutilisez cette transformation pour :

  • d’autres CAPIs, TikTok, Snap, etc.

  • les plateformes d’analyse

  • les proxies de reporting internes