Stratégie de configuration des canaux

Important: Familiarisez-vous avec les ressources suivantes avant de poursuivre cet article :

• Guide de démarrage Optimize

• Qu’est-ce qu’une règle d’identification ?

• Qu’est-ce qu’un groupe de crédit ?

Cet article couvre les fonctionnalités et les fonctions 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 adaptée à toutes les situations. Cependant, vous devriez pouvoir parvenir à une solution qui correspond le 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 destiné à être façonné pour s’adapter au mieux à votre situation spécifique.

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

Concentrez-vous sur des configurations de canaux ciblées: N’oubliez pas qu’Optimize vise à faire ressortir des informations au niveau du canal ; lorsque vous créez votre RTI, vous devez déterminer comment identifier le trafic provenant d’un canal particulier. Garder cela à l’esprit vous aidera à garder votre RTI simple, ciblé et efficace.

Petit rappel

• Une cible de règle est le « où » de la règle : l’endroit où elle cherchera à appliquer la logique de règle et à trouver la ou les valeurs de règle.

• La logique de règle est le « comment » : la manière dont la règle tentera d’identifier le trafic.

• Les valeurs de règle sont les données que vous fournissez à la règle pour lui permettre d’agir.

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 l’option de cible de règle et de logique de règle dans une règle ne doivent pas être considérés comme interchangeables, même si plusieurs ensembles de composants peuvent fonctionner pour un scénario donné. Consultez les sections suivantes pour des exemples à ce sujet.

Choisir une cible de règle

Les cibles de règle peuvent être évaluées en fonction de leur précision et de leur fiabilité. Le graphique suivant représente les différentes cibles de règle en termes de précision et de fiabilité respectives. Plus une cible de règle 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).

Vous devriez 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. Vous trouverez ci-dessous deux exemples de choix de 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, Paramètre de la page de destination doit être la cible de règle. La règle d’identification commencera à ressembler à ceci :

Cible de la règle	Valeur de la règle 1	Logique de la règle
URL de la page de destination	utm_medium	*	*

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

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 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 d’atterrissage. Vous pouvez voir sur le graphique ci-dessus que la meilleure option compte tenu de tous ces facteurs est alors Domaine référent. La règle d’identification commencera à ressembler à ceci :

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

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

Choisir une option de logique de règle

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

Vous devriez 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. Vous trouverez ci-dessous deux exemples de choix de 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 de logique de règle possible serait Correspond exactement à.

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

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

Si, par exemple, l’option de logique de règle Contient était utilisée à la place, toute utm_medium valeur contenant recherche serait considérée comme faisant partie de ce canal, ce qui peut entraîner des actions mal attribuées, des ajustements commerciaux et potentiellement davantage. Contient ne serait toutefois pas un mauvais choix ici ; Correspond exactement à il se trouve simplement que c’est le meilleur choix.

Exemple 2 : Recherche organique

La cible de règle Domaine de référence ayant été établie comme le meilleur choix précédemment, une option de logique de règle possible pourrait être la suivante :

Cible de la règle	Valeur de la règle 1	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 exemple, www, cn), les domaines de premier niveau (par exemple, com, net), et les chemins URL, le simple fait de s’assurer que le domaine référent contient le domaine de second niveau de .bing. permettra à tout le trafic de recherche organique provenant de Bing d’être considéré comme faisant partie de ce canal.

Ces raisons expliquent aussi pourquoi toute option de logique de règle plus précise ne peut pas être choisie, car elle exclurait 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 des solutions regex, impact.com ne fournit pas de conseils généraux ni d’orientation sur la manière d’implémenter des expressions régulières dans Optimize. Si vous pensez que votre situation serait mieux gérée avec une option de logique de règle regex, consultez votre CSM pour savoir comment commencer à la mettre en œuvre.

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 à recherchera uniquement la valeur de règle 2 exacte telle qu’elle est écrite dans le RTI. Correspond à l’un quelconque recherchera toutes les valeurs de règle 2 telles qu’elles sont exactement écrites dans la règle.

Si vous vous retrouvez à 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.

ID de clic courants

Les ID de clic deviennent de plus en plus courants dans les médias payants. Voici une liste d’ID 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

Trafic disqualifiant

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

Exemple 1 : Recherche payante

Voici l’exemple créé ci-dessus :

Cible de la règle	Valeur de la règle 1	Logique de la règle	Valeur de la règle 2
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 règle peut être élargie pour qualifier davantage de trafic :

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

À présent, si l’une ou l’autre règle est vraie, le trafic sera identifié comme faisant partie de ce canal.

Exemple 2 : Recherche organique

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 Rules To Identify ne sont pas sensibles à la casse. Par exemple, si vous avez un paramètre où utm_medium=SEARCH, vous pouvez tout de même configurer votre règle comme suit :

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

Et ensuite ?

Passez en revue quelques scénarios de configuration d’Optimize. Ici, vous trouverez des recommandations pour les scénarios Optimize courants.