Stratégie de configuration des canaux
Important: Familiarisez-vous avec les ressources suivantes avant de passer à cet article :
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 qui puisse convenir à toutes les situations. Cependant, vous devriez pouvoir parvenir à une solution qui s'adapte 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 conçu pour être adapté au mieux à vos circonstances spécifiques.
Ce document renforcera les connaissances fondamentales et fonctionnelles nécessaires pour concevoir les Rules To Identify optimales pour votre programme.
Petit rappel
Une cible de règle est le « où » où la règle cherchera à appliquer la logique de règle et à trouver la ou les valeurs de règle.
La logique de règle est le « comment » par lequel la règle tentera d'identifier le trafic.
Les valeurs de règle sont les entrées que vous fournissez à la règle pour servir de base.
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 plusieurs ensembles de composants peuvent fonctionner dans un scénario donné. Consultez les sections suivantes pour des exemples de cela.
Choisissez une cible de règle
Les cibles de règle peuvent être évaluées en termes de précision et de fiabilité. Le graphique suivant place 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 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 choix. Voici deux cas d'exemple pour 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. De ce fait, la Paramètre de la page de destination devrait être la cible de règle. La Rule To Identify commencera à ressembler à ceci :
URL de la page de destination
utm_medium
*
*
Consultez le Logique de règle - Exemple 1 section pour voir quoi renseigner pour la Logique de la règle et Valeur 2 de la règle.
Exemple 2 : Recherche organique
Le canal suivant, la recherche organique, ne comportera aucun paramètre UTM et la page d'atterrissage est imprévisible. Ces conditions excluent toutes les cibles de règle visant 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 la Domaine référent. La Rule To Identify commencera à ressembler à ceci :
Domaine référent
--
*
*
Consultez le Logique de règle - Exemple 2 section pour voir quoi renseigner pour la Logique de la règle et Valeur 2 de la règle.
Choisissez 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 place 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 sur le graphique que si vous n'avez pas d'autre choix. Voici deux cas d'exemple pour choisir l'option de logique de règle à 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 logique de règle possible serait Correspond exactement.
URL de la page de destination
utm_medium
Correspond exactement
search
Correspond exactement fonctionne le mieux ici parce que 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, n'importe quel utm_medium valeur contenant search 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 encore. Contient ne serait cependant pas un mauvais choix ici ; Correspond exactement c'est simplement le meilleur choix.
Exemple 2 : Recherche organique
La cible de règle Domaine référent ayant été établie plus tôt comme le meilleur choix, une option de logique de règle possible pourrait être la suivante :
Domaine référent
--
Contient
.bing.
Contient est un bon choix ici, car la recherche organique de Bing peut provenir de plusieurs URL référentes différentes, telles que :
https://cn.bing.comhttps://www4.bing.com/searchhttps://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 d'URL peuvent être très différents, le simple fait de s'assurer que le domaine référent contient le domaine de deuxième niveau de .bing. permettra de considérer tout le trafic de recherche organique provenant de Bing comme faisant partie de ce canal.
C'est aussi pour ces raisons qu'aucune option de logique de règle 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 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 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 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 quelle valeur
Ces deux options de logique de règle fonctionnent exactement de la même manière, mais avec une légère distinction. Correspond exactement recherchera uniquement la valeur de règle 2 exacte telle qu'elle est écrite dans le RTI. Correspond à au moins une recherchera toutes les valeurs de règle 2 telles qu'elles sont écrites exactement dans la règle.
Si vous vous retrouvez à utiliser Correspond exactement plus d'une fois avec l' ET opérateur, envisagez d'utiliser Correspond à au moins une. Il en va de même pour Contient et Contient au moins une.
Identifiants de clic courants
Les identifiants de clic sont de plus en plus courants dans les médias payants. Voici une liste d'identifiants de clic courants que vous pouvez utiliser pour identifier le trafic.
Google Ads
GCLID
Bing Ads/Recherche Yahoo
MSCLKID
Facebook Ads
FBCLID
EPIK
Disqualification du trafic
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.
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
search
Cette règle disqualifie déjà beaucoup de trafic. En ajoutant une autre Rule To Identify et en utilisant l' OU opérateur, la règle 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
search
OU
Paramètre de la page de destination
GCLID
Est présent
--
Désormais, si l'une ou l'autre règle est vraie, le trafic sera identifié comme faisant partie de ce canal.
Voici l'exemple créé ci-dessus :
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' ET opérateur, la règle peut commencer à disqualifier le trafic référé par Bing :
Domaine référent
--
Contient
.bing.
ET
Paramètre de la page de destination
MSCLIKID
N’est pas présent
--
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 toujours configurer votre règle comme suit :
URL de la page de destination
utm_medium
Correspond exactement
search
Et ensuite ?
Consultez quelques scénarios de configuration d'Optimize. Vous y trouverez des recommandations pour les scénarios courants d'Optimize.
Mis à jour
Ce contenu vous a-t-il été utile ?