# Comment faire – Envoyer une Protected Profit Value via Meta (Facebook CAPI)

### 🎯 Objectif

« Value Optimization for Profit » de Meta permet aux campagnes d’optimiser sur la base de la rentabilité au niveau de la commande plutôt que sur 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.

{% hint style="info" %}
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 représentant Meta.
{% endhint %}

Meta vous permet d’optimiser les campagnes en utilisant une valeur business via le paramètre :

👉 **`net_revenue`**

Cependant, de nombreux annonceurs préfèrent **ne pas envoyer leur marge brute**, car il s’agit d’une donnée hautement stratégique.

👉 L’objectif est de :

* **éviter d’exposer votre vraie marge**
* tout en envoyant un **signal que Meta peut utiliser pour l’optimisation**

Pour y parvenir, 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.

{% hint style="warning" %}
Cette approche doit être considérée comme **l’indexation de la valeur du 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.
{% endhint %}

***

### ⚠️ 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 au revenu net, dans vos données.

👉 Cela se fait généralement via un **import de catalogue produit**, 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 catalog, 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 **Data Cleansing** en combinaison avec **l’enrichissement des événements**.

Une configuration courante est la suivante :

* importer la marge au niveau produit via un product catalog
* enrichir le `purchase` événement en faisant correspondre les IDs des items de l’événement avec les IDs produit du catalog
* utiliser une formule Data Cleansing pour agréger les marges au niveau item 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ée

👉 Il est fortement recommandé de définir la transformation dans **Data Cleansing**, afin que :

* la logique soit centralisée
* elle peut être réutilisée sur plusieurs destinations, autres CAPIs, analytics, etc.
* elle soit plus facile à maintenir

#### Étapes

1. Allez dans **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 les valeurs transformées dans la proportion exacte de leur ratio et d’éviter les approximations lorsque c’est possible.

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

Autrement dit :

* préserver le classement signifie : plus de profit → valeur plus élevée
* préserver les ratios signifie : si un achat est deux fois plus rentable, la valeur envoyée à Meta devrait 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 une performance optimale.

Plus la transformation s’éloigne d’un index proportionnel, plus l’obfuscation peut devenir forte, mais plus elle peut aussi déformer 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é.

```sql
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 spécifique au client
* `NULL` signifie qu’aucune `net_revenue` valeur ne doit être envoyée pour les marges non positives

Exemple avec `K = 37.48291`:

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

#### Comment ça marche

La marge est multipliée par un facteur d’indexation spécifique 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 de value optimization propre
* la marge brute n’est pas envoyée directement
* Le reporting 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

👉 Ceci est entièrement conforme à la recommandation de Meta.

{% hint style="info" %}
Cette approche fournit un index confidentiel, et non 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.
{% endhint %}

***

### 🟠 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.

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

Où :

* `K` est un facteur d’indexation secret spécifique au client
* `C` est un petit offset spécifique au client
* `C` doit rester faible par rapport à la plus petite marge positive significative

Exemple :

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

#### Comment ça marche

La marge est d’abord augmentée d’un petit offset, puis multipliée par un facteur d’indexation spécifique 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’avec 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

L’ajout de `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 marge que dans la réalité.

Cela peut réduire la qualité de l’optimisation, en particulier lorsque `C` est important par rapport aux faibles marges positives.

#### Règle recommandée pour C

À titre indicatif :

```
C ne devrait 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

{% hint style="warning" %}
Cette option n’est pas l’approche recommandée par Meta pour une performance optimale, car elle ne préserve pas les ratios exacts.

Utilisez-la uniquement lorsque l’annonceur accepte explicitement un compromis entre une obfuscation plus forte et un impact potentiel sur l’optimisation.
{% endhint %}

***

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

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

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

```sql
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)
    )
  )
)
```

#### Comment ça marche

La marge est transformée en plages de valeurs plus larges.

Exemple :

* 3 $ → 40
* 10 $ → 120
* 25 $ → 220
* 40 $+ → 320

👉 Résultat :

* la marge d’origine est beaucoup plus difficile à reconstituer
* les valeurs ne sont plus proportionnelles
* de nombreuses marges différentes reçoivent la même valeur
* le signal d’optimisation est restructuré

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

Cette approche préserve le classement, mais elle ne préserve 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’un palier sont perdues
* des sauts artificiels sont créés entre les paliers
* les achats à forte marge peuvent être sous-représentés
* les achats à faible marge peuvent être surreprésentés
* Le modèle de régression de Meta reçoit un signal de valeur déformé

{% hint style="danger" %}
Meta recommande d’éviter les couches de shaping telles que le plafonnement, la compression, le bucketing ou le scoring basé sur des seuils lorsque l’objectif est une performance optimale de Value Optimization.

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

***

### 📊 Résumé des trois options

| Option                                   | Formule                  | Alignement avec Meta | Niveau d’obfuscation | Risque pour la performance |
| ---------------------------------------- | ------------------------ | -------------------: | -------------------: | -------------------------: |
| Option 1 – Index de profit proportionnel | `marge × K`              |           Excellente |                Moyen |                     Faible |
| Option 2 – Index de profit avec offset   | `(marge + C) × K`        |              Partiel |               Moyen+ |             Faible à moyen |
| Option 3 – Score de profit par paliers   | `plage de marge → score` |               Faible |                Élevé |              Moyen à élevé |

👉 Valeur par défaut recommandée :

```sql
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 la performance optimale.

***

### ⚠️ Gestion des marges nulles ou négatives

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

Jusqu’à ce que les consignes finales soient disponibles, l’approche la plus sûre est d’omettre `net_revenue` pour les marges non positives.

Logique recommandée :

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

Lorsque `net_revenue` est omis :

* l’événement est toujours suivi comme conversion Purchase
* l’événement n’est pas utilisé pour l’optimisation du profit
* l’événement n’entre pas dans le seuil d’éligibilité des 200 conversions

{% hint style="warning" %}
Assurez-vous que le fait de renvoyer `NULL` dans votre transformation empêche effectivement l’envoi du `net_revenue` champ.

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

***

### 📈 Impact sur le reporting Ads Manager

Ads Manager affichera 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 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.

{% hint style="info" %}
Le reporting du ROAS ou lié à la marge dans Ads Manager doit être interprété comme un reporting indexé, et non comme un reporting du profit brut.
{% endhint %}

***

### 🔗 Étape 2 – Mapper la valeur dans Meta CAPI

Dans votre **destination Facebook Conversions API**:

1. Ouvrez la configuration de votre destination
2. Rendez-vous dans la section **Smart Mapping** section
3. Mappez les éléments suivants :

👉 **`net_revenue` → `protected_profit_value`**

4. Assurez-vous également que :

* `currency` est correctement mappé

***

### ⚙️ Alternative – Transformation dans la destination

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

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

Cependant, c’est moins recommandé car :

* la logique n’est pas réutilisable
* elle est dupliquée pour chaque destination

👉 N’utilisez cette approche que pour des tests rapides ou des cas spécifiques.

***

### ✅ Résultat

Vous envoyez à Meta :

* a **un signal d’optimisation basé sur le profit**
* sans exposer directement votre marge brute

👉 Meta peut :

* optimiser les campagnes sur la base de la valeur de profit attendue
* utiliser la valeur indexée comme signal de value optimization

👉 Mais vos données stratégiques :

* ne sont pas envoyées sous leur forme originale
* est protégé via une transformation spécifique au client
* n’est pas directement lisible comme une marge brute

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

{% hint style="warning" %}
La valeur affichée dans Ads Manager est la valeur indexée envoyée à Meta, et non la marge brute d’origine.
{% endhint %}

***

### 💡 Bonnes pratiques

* Utilisez l’Option 1 par défaut
* Conservez la transformation stable dans le temps
* Utilisez un `K`
* Évitez les facteurs ronds tels que `10`, `100` ou `1000` si 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 la performance
* Omettez `net_revenue` pour les marges non positives jusqu’à ce que Meta fournisse des consignes finales
* Réutilisez cette transformation pour :
  * autres CAPIs, TikTok, Snap, etc.
  * les plateformes analytics
  * les proxies de reporting interne


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.commandersact.com/fr/fonctionnalites/destinations/destinations-catalog/facebook/facebook-conversions-api/how-to-send-a-protected-profit-value-via-meta-facebook-capi.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.