# Stratégie de configuration des canaux

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

* [Guide de démarrage Optimize](https://help.impact.com/brand/fr/platform-features/cross-channel-performance-insights/optimize-startup-guide)
* [Qu'est-ce qu'une règle d'identification ?](https://help.impact.com/brand/fr/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic)
* [Qu'est-ce qu'un groupe de crédits ?](https://help.impact.com/brand/fr/platform-features/actions-and-payouts/credit-groups-explained)
  {% endhint %}

Cet article couvre les fonctionnalités et les fonctions des règles d'identification (RTI) d'Optimize. Vous apprendrez comment élaborer une stratégie pour configurer les règles d'identification (RTI) pour de nouveaux canaux ou modifier les canaux existants dans votre programme.

Il n'existe pas de solution universelle adaptée à toutes les circonstances. Cependant, vous devriez pouvoir parvenir à une solution qui convient le mieux à vos circonstances uniques. Des arguments contre la configuration d'une certaine RTI peuvent toujours exister, mais **le but d'une RTI n'est pas de fonctionner dans toutes les circonstances**. **Une RTI est destinée à être façonnée pour s'adapter au mieux à vos circonstances spécifiques**.

Ce document développera les connaissances fondamentales et fonctionnelles nécessaires pour concevoir les règles d'identification optimales pour votre programme.

{% hint style="info" %}
**Concentrez les configurations de canal**: Rappelez-vous qu'Optimize vise à mettre en évidence des informations au niveau des canaux ; lors de la création de votre RTI, vous devez réfléchir à la façon d'identifier le trafic provenant d'un canal particulier. Garder cela à l'esprit vous aidera à maintenir votre RTI simple, ciblée et efficace.
{% endhint %}

**Un petit rappel**

* Une cible de règle est « où » la règle cherchera à appliquer la logique de règle et à trouver les valeurs de règle.
* La logique de règle est « comment » la règle tentera d'identifier le trafic.
* Les valeurs de règle sont des entrées que vous fournissez à la règle pour les exploiter.

#### 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 de la cible de règle et de l'option de logique de règle dans une règle 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é. Voir les sections suivantes pour des exemples.

<details>

<summary>Choisir une cible de règle</summary>

Les cibles de règle peuvent être évaluées en termes de précision et de fiabilité. Le tableau suivant représente les différentes cibles de règle en fonction de leur précision et de leur fiabilité respectives. Plus une cible de règle est éloignée de l'origine du graphique, plus elle est précise (sur l'axe x) et fiable (sur l'axe y).

<div data-with-frame="true"><figure><img src="https://57104473-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwMLlMoFBtKJa8ptd3zaw%2Fuploads%2Fgit-blob-489f6f57993cbcf93749f93b54b796fd3f2f0095%2Fc19fe1a665f9b3e512fe5afb73ca76dfe2ae37fcda9f0873ae316bebaf1fb02c.png?alt=media" alt=""><figcaption></figcaption></figure></div>

Vous devez toujours essayer d'utiliser la cible de règle 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. Voici deux cas d'exemple pour savoir comment choisir la cible de règle à 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`. En raison de cela, le **paramètre de page de destination** devrait être la cible de règle. La règle d'identification commencera à ressembler à ceci :

<table><thead><tr><th width="128">Cible de règle</th><th>Valeur de règle 1</th><th>Logique de 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>

Voir le *Logique de règle - Exemple 1* section pour voir quoi remplir pour la *Logique de règle* et *Valeur de règle 2*.

**Exemple 2 : Recherche organique**

Le canal suivant, Recherche organique, n'aura aucun paramètre UTM et la page de destination est imprévisible. Ces conditions excluent toutes les cibles de règle qui ciblent les paramètres et les chaînes de requête ainsi que toutes les cibles de règle de page de destination. Vous pouvez voir dans le graphique ci-dessus que la meilleure option en tenant compte de tous ces facteurs est alors le **domaine référent**. La règle d'identification commencera à ressembler à ceci :

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

Voir le *Logique de règle - Exemple 2* section pour voir quoi remplir pour la *Logique de règle* et *Valeur de règle 2*.

</details>

<details>

<summary>Choisir une option de logique de règle</summary>

La logique de règle ne peut être évaluée que pour la précision. Le graphique suivant représente les différentes options de logique de règle en termes de leur précision relative.

<div data-with-frame="true"><figure><img src="https://57104473-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwMLlMoFBtKJa8ptd3zaw%2Fuploads%2Fgit-blob-c917a70e8cfa00de3db2c1855ae9276f687da113%2F5a7fdeb96314eec55916b1fb0357483ee17dd3aec317357e20bbf514232c2ab0.png?alt=media" alt=""><figcaption></figcaption></figure></div>

Vous devez toujours essayer d'utiliser l'option de logique de règle la plus précise possible, et ne descendre dans le graphique que si vous n'avez pas d'autre option. Voici deux cas d'exemple pour choisir l'option de logique de règle à utiliser.

**Exemple 1 : Recherche payante**

Puisque toute la recherche payante est balisée avec le paramètre UTM de Google `utm_medium=search`, la meilleure option possible de logique de règle serait **Correspond exactement**.

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

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

Si, par exemple, l'option de logique de règle **Contient** avait été utilisée à la place, toute `utm_medium` valeur contenant `search` à l'intérieur serait considérée comme faisant partie de ce canal, ce qui peut entraîner des actions mal attribuées, des compensations et potentiellement plus. **Contient** ne serait cependant pas un mauvais choix ici ; **Correspond exactement** c'est juste le meilleur choix.

**Exemple 2 : Recherche organique**

Avec la cible de domaine référent établie comme le meilleur choix précédemment, une option potentielle de logique de règle pourrait être la suivante :

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

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

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

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

</details>

Ces raisons expliquent également pourquoi des options de logique de règle plus précises ne peuvent pas être choisies, car elles excluraient des domaines référents qui devraient être considérés comme faisant partie de ce canal.

**Options de logique de règle Regex**

En raison de la complexité de la mise en œuvre de solutions regex, impact.com ne fournit pas de conseils généraux ou d'orientations sur la façon d'implémenter des expressions régulières dans Optimize. Si vous pensez que vos circonstances sont mieux gérées avec une option de logique de règle regex, consultez votre CSM pour savoir comment commencer à l'implémenter.

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

Ces deux options de logique de règle fonctionnent exactement de la même manière, mais avec une petite distinction. *Correspond exactement* ne recherchera que la Valeur de règle 2 exacte telle qu'elle est écrite dans la RTI. *Correspond à n'importe lequel* recherchera toutes les Valeurs de règle 2 telles qu'elles sont exactement écrites dans la règle.

Si vous vous surprenez à utiliser **Correspond exactement** plus d'une fois avec le **ET** opérateur, envisagez d'utiliser **Correspond à n'importe lequel**. Il en va de même pour **Contient** et **Contient n'importe lequel**.

#### Identifiants de clic courants

Les identifiants de clic deviennent de plus en plus courants pour les médias payants. Voici une liste d'identifiants de clic 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`     |

#### Disqualifier le trafic

Parfois, créer des règles d'identification qui *disqualifient* le trafic peut être tout aussi utile pour identifier le trafic comme faisant partie d'un canal. Voir les sous-sections ci-dessous pour voir comment les exemples créés ci-dessus peuvent être configurés pour disqualifier du trafic.

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

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

Cette règle disqualifie déjà beaucoup de trafic. En ajoutant une autre règle d'identification et en utilisant le **OU** opérateur, la règle peut être élargie pour qualifier plus de trafic :

|                                  |                       |                       |                       |
| -------------------------------- | --------------------- | --------------------- | --------------------- |
| **Cible de règle**               | **Valeur de règle 1** | **Logique de règle**  | **Valeur de règle 2** |
| URL de la page de destination    | `utm_medium`          | Correspond exactement | `search`              |
| **OU**                           |                       |                       |                       |
| paramètre de page de destination | `GCLID`               | Est présent           | --                    |

Désormais, si l'une ou l'autre des règles est vraie, le trafic sera identifié comme faisant partie de ce canal.
{% endtab %}

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

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

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

| Cible de règle                   | Valeur de règle 1 | Logique de règle  | Valeur de règle 2 |
| -------------------------------- | ----------------- | ----------------- | ----------------- |
| domaine référent                 | `--`              | Contient          | .bing.            |
| **ET**                           |                   |                   |                   |
| paramètre de page de destination | `MSCLIKID`        | N'est pas présent | --                |
| {% endtab %}                     |                   |                   |                   |
| {% endtabs %}                    |                   |                   |                   |

Désormais, les deux règles doivent être vraies pour que le trafic soit identifié comme faisant partie de ce canal.

#### Sensibilité à la casse

Les règles d'identification ne sont pas sensibles à la casse. Par exemple, si vous avez un paramètre où `utm_medium=SEARCH`, vous pouvez toujours configurer votre règle comme :

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

#### Et après ?

Consultez quelques [scénarios de configuration Optimize](https://help.impact.com/brand/fr/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples). Ici, vous trouverez des recommandations pour des scénarios Optimize courants.
