> For the complete documentation index, see [llms.txt](https://help.impact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.impact.com/brand/fr/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md).

# Stratégie de configuration des canaux

{% hint style="warning" %}
**Important** : Familiarisez-vous avec les ressources suivantes avant de passer à cet article :

* [Guide de démarrage Optimize](/brand/fr/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [Qu’est-ce qu’un Rule To Identify ?](/brand/fr/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [Qu’est-ce qu’un Credit Group ?](/brand/fr/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
  {% endhint %}

Cet article couvre les fonctionnalités des Rules To Identify (RTI) d’Optimize. Vous apprendrez à élaborer une stratégie pour configurer les Rules To Identify (RTI) pour de nouveaux canaux ou modifier les canaux existants dans votre programme.

Il n’existe pas de solution universelle pouvant convenir à toutes les situations. Cependant, vous devriez être en mesure de parvenir à une solution qui corresponde au mieux à votre situation particulière. Des arguments contre la configuration d’un certain RTI peuvent toujours exister, mais **le but d’un RTI n’est pas de fonctionner dans toutes les situations**. **un RTI est conçu pour être adapté afin de mieux répondre à votre situation spécifique**.

Ce document renforcera les connaissances fondamentales et fonctionnelles nécessaires pour concevoir les Rules To Identify optimales pour votre programme.

{% hint style="info" %}
**Gardez des configurations de canaux ciblées** : N’oubliez pas qu’Optimize vise à faire ressortir des insights au niveau des canaux ; lors de la création de votre RTI, vous devez prendre en compte la façon d’identifier le trafic provenant d’un canal particulier. Garder cela à l’esprit vous aidera à maintenir votre RTI simple, ciblé et efficace.
{% endhint %}

**Petit rappel**

* Une Rule Target correspond au « où » la règle cherchera à appliquer la Rule Logic et à trouver la ou les Rule Value(s).
* La Rule Logic correspond au « comment » la règle tentera d’identifier le trafic.
* Les Rule Values sont les entrées que vous fournissez à la règle pour lui servir de levier.

#### Précision et fiabilité

Lors de la conception de votre RTI, les concepts clés à garder à l’esprit sont la précision et la fiabilité. Les choix concernant la Rule Target et l’option Rule Logic d’une Rule ne doivent pas être considérés comme interchangeables, même si plus d’un ensemble de composants peut fonctionner pour un scénario donné. Consultez les sections suivantes pour des exemples à ce sujet.

<details>

<summary>Choisir une Rule Target</summary>

Les Rule Targets peuvent être évaluées selon leur précision et leur fiabilité. Le graphique suivant place les différentes Rule targets en fonction de leur précision et de leur fiabilité respectives. Plus une Rule Target est éloignée de l’origine du graphique, plus elle est précise (sur l’axe des x) et plus elle est fiable (sur l’axe des y).

<div data-with-frame="true"><figure><img src="/files/9880f5970d25be4c930a5531ee94b321f38570d1" alt=""><figcaption></figcaption></figure></div>

Vous devriez toujours essayer d’utiliser la Rule Target la plus fiable et la plus précise possible, et ne vous déplacer vers la gauche ou vers le bas du graphique que si vous n’avez pas d’autre option. Ci-dessous se trouvent deux cas d’exemple pour choisir la Rule Target à utiliser.

**Exemple 1 : Recherche payante**

Dans ce scénario, tout le trafic de recherche payante est balisé avec le paramètre UTM de Google `utm_medium=search`. À cause de cela, la **Paramètre de la page d’atterrissage** devrait être la Rule Target. Le Rule To Identify commencera à ressembler à ceci :

<table><thead><tr><th width="128">Cible de la règle</th><th>Valeur 1 de la règle</th><th>Logique de la règle</th><th></th></tr></thead><tbody><tr><td>URL de la page de destination</td><td><code>utm_medium</code></td><td>*</td><td>*</td></tr></tbody></table>

Consultez *Rule Logic - Exemple 1* section pour voir quoi renseigner dans le *Logique de la règle* et *Valeur 2 de la règle*.

**Exemple 2 : Recherche organique**

Le canal suivant, la recherche organique, n’aura aucun paramètre UTM et la page d’atterrissage est imprévisible. Ces conditions excluent toutes les Rule Targets qui ciblent les paramètres et les chaînes de requête ainsi que toutes les Rule Targets de page d’atterrissage. Vous pouvez voir sur le graphique ci-dessus que la meilleure option, compte tenu de tous ces facteurs, est alors la **Domaine référent**. Le Rule To Identify commencera à ressembler à ceci :

| Cible de la règle | Valeur 1 de la règle | Logique de la règle |    |
| ----------------- | -------------------- | ------------------- | -- |
| Domaine référent  | `--`                 | \*                  | \* |

Consultez *Rule Logic - Exemple 2* section pour voir quoi renseigner dans le *Logique de la règle* et *Valeur 2 de la règle*.

</details>

<details>

<summary>Choisir une option de Rule Logic</summary>

La Rule Logic ne peut être évaluée qu’en termes de précision. Le graphique suivant place les différentes options de Rule Logic en fonction de leur précision relative.

<div data-with-frame="true"><figure><img src="/files/ec7f487a1d6b757cf9f0f2ea38a5ab5fa420afd3" alt=""><figcaption></figcaption></figure></div>

Vous devriez toujours essayer d’utiliser l’option de Rule Logic la plus précise possible, et ne descendre dans le graphique que si vous n’avez pas d’autre option. Ci-dessous se trouvent deux cas d’exemple pour choisir l’option de Rule Logic à utiliser.

**Exemple 1 : Recherche payante**

Comme toute la recherche payante est balisée avec le paramètre UTM de Google `utm_medium=search`, la meilleure option de Rule Logic possible serait **Correspond exactement à**.

| Cible de la règle             | Valeur 1 de la règle | Logique de la règle     |             |
| ----------------------------- | -------------------- | ----------------------- | ----------- |
| URL de la page de destination | `utm_medium`         | Correspond exactement à | `recherche` |

**Correspond exactement à** fonctionne ici le mieux, car seul le trafic ayant la paire clé-valeur de paramètre exacte de `utm_medium=search` devrait être considéré comme faisant partie de ce canal.

Si, par exemple, l’option de Rule Logic **Contient** était utilisée à la place, toute `utm_medium` valeur avec `recherche` à l’intérieur serait considérée comme faisant partie de ce canal, ce qui peut entraîner des actions mal attribuées, des make-goods et potentiellement davantage. **Contient** ne serait toutefois pas un mauvais choix ici ; **Correspond exactement à** se trouve simplement être le meilleur choix.

**Exemple 2 : Recherche organique**

Le Referring Domain Rule Target ayant été établi plus tôt comme le meilleur choix, une option potentielle de Rule Logic pourrait être la suivante :

| Cible de la règle | Valeur 1 de la règle | Logique de la règle |        |
| ----------------- | -------------------- | ------------------- | ------ |
| Domaine référent  | `--`                 | Contient            | .bing. |

**Contient** est un bon choix ici, car la recherche organique de Bing peut provenir de plusieurs URL de référence différentes, telles que :

* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`

En raison des différences entre les domaines de troisième niveau (par ex., *www, cn*), les domaines de premier niveau (par ex., *com, net*), et les chemins d’URL, il suffit de s’assurer que le domaine référent contient le domaine de second niveau de **.bing.** pour permettre à tout le trafic de recherche organique provenant de Bing d’être considéré comme faisant partie de ce canal.

</details>

C’est également pour ces raisons qu’aucune option de Rule Logic plus précise ne peut être choisie, car elle exclurait des domaines référents qui devraient être considérés comme faisant partie de ce canal.

**Options de Rule Logic regex**

En raison de la complexité de la mise en œuvre des solutions regex, impact.com ne fournit pas de conseils généraux ni d’orientation sur la façon d’implémenter des expressions régulières dans Optimize. Si vous pensez que votre situation est mieux traitée avec une option de Rule Logic regex, consultez votre CSM pour savoir comment commencer à la mettre en œuvre.

#### Correspond exactement vs. Correspond à n’importe lequel

Ces deux options de Rule Logic fonctionnent exactement de la même manière, avec toutefois une petite distinction. *Correspond exactement à* ne recherchera que la Rule Value 2 exacte telle qu’elle est écrite dans le RTI. *Correspond à l’un quelconque* recherchera toutes les Rule Value 2 telles qu’elles sont exactement écrites dans la Rule.

Si vous vous surprenez à utiliser **Correspond exactement à** plus d’une fois avec l’opérateur **ET** , envisagez d’utiliser **Correspond à l’un quelconque**. Il en va de même pour **Contient** et **Contient l’un quelconque**.

#### Click IDs courants

Les Click IDs deviennent de plus en plus courants dans les médias payants. Voici une liste de Click IDs courants que vous pouvez utiliser pour identifier le trafic.

| Source média          | ID de clic |
| --------------------- | ---------- |
| Google Ads            | `GCLID`    |
| Bing Ads/Yahoo Search | `MSCLKID`  |
| Facebook Ads          | `FBCLID`   |
| Pinterest             | `EPIK`     |

#### Trafic disqualifiant

Parfois, créer des Rules To Identify qui *disqualifient* le trafic peut être tout aussi utile pour identifier le trafic en tant que partie d’un canal. Consultez les sous-sections ci-dessous pour voir comment les exemples créés ci-dessus peuvent être configurés afin de disqualifier le trafic.

{% tabs %}
{% tab title="Exemple 1 : Recherche payante" %}
Voici l’exemple créé ci-dessus :

|                               |                          |                         |                          |
| ----------------------------- | ------------------------ | ----------------------- | ------------------------ |
| **Cible de la règle**         | **Valeur 1 de la règle** | **Logique de la règle** | **Valeur 2 de la règle** |
| URL de la page de destination | `utm_medium`             | Correspond exactement à | `recherche`              |

Cette règle disqualifie déjà beaucoup de trafic. En ajoutant une autre Rule To Identify et en utilisant l’opérateur **OU** , la Rule peut être élargie pour qualifier davantage de trafic :

|                                     |                          |                         |                          |
| ----------------------------------- | ------------------------ | ----------------------- | ------------------------ |
| **Cible de la règle**               | **Valeur 1 de la règle** | **Logique de la règle** | **Valeur 2 de la règle** |
| URL de la page de destination       | `utm_medium`             | Correspond exactement à | `recherche`              |
| **OU**                              |                          |                         |                          |
| Paramètre de la page d’atterrissage | `GCLID`                  | Est présent             | --                       |

Maintenant, si l’une ou l’autre des Rules est vraie, le trafic sera identifié comme faisant partie de ce canal.
{% endtab %}

{% tab title="Exemple 2 : Recherche organique" %}
Voici l’exemple créé ci-dessus :

| Cible de la règle | Valeur 1 de la règle | Logique de la règle | Valeur 2 de la règle |
| ----------------- | -------------------- | ------------------- | -------------------- |
| Domaine référent  | `--`                 | Contient            | .bing.               |

Cette rule identifiera tout le trafic référé par Bing. En ajoutant une autre Rule et en utilisant l’opérateur **ET** , la Rule peut commencer à disqualifier le trafic référé par Bing :

| Cible de la règle                   | Valeur 1 de la règle | Logique de la règle | Valeur 2 de la règle |
| ----------------------------------- | -------------------- | ------------------- | -------------------- |
| Domaine référent                    | `--`                 | Contient            | .bing.               |
| **ET**                              |                      |                     |                      |
| Paramètre de la page d’atterrissage | `MSCLIKID`           | N’est pas présent   | --                   |
| {% endtab %}                        |                      |                     |                      |
| {% endtabs %}                       |                      |                     |                      |

Maintenant, les deux Rules doivent être vraies pour que le trafic soit identifié comme faisant partie de ce canal.

#### Sensibilité à la casse

Les Rules To Identify ne sont pas sensibles à la casse. Par exemple, si vous avez un paramètre où `utm_medium=SEARCH`, vous pouvez quand même configurer votre règle comme suit :

| Cible de la règle             | Valeur 1 de la règle | Logique de la règle     | Valeur 2 de la règle |
| ----------------------------- | -------------------- | ----------------------- | -------------------- |
| URL de la page de destination | `utm_medium`         | Correspond exactement à | `recherche`          |

#### Et ensuite ?

Consultez quelques [scénarios de configuration d’Optimize](/brand/fr/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md). Ici, vous trouverez des recommandations pour des scénarios courants d’Optimize.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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://help.impact.com/brand/fr/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.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.