For the complete documentation index, see llms.txt. This page is also available as Markdown.

Estrategia de configuración de canales

Este artículo cubre las características y funciones de las Reglas para identificar (RTI) de Optimize. Aprenderás a desarrollar una estrategia para configurar las Reglas para identificar (RTI) para nuevos canales o modificar los canales existentes en tu programa.

No existe una solución universal que encaje en todas las circunstancias. Sin embargo, deberías poder llegar a una solución que se adapte mejor a tus circunstancias únicas. Siempre pueden existir argumentos en contra de la configuración de una determinada RTI, pero el propósito de una RTI no es funcionar en todas las circunstancias. Una RTI está pensada para adaptarse de la mejor manera a tus circunstancias específicas.

Este documento ampliará los conocimientos fundamentales y funcionales necesarios para diseñar las Reglas para identificar óptimas para tu programa.

Mantén las configuraciones de canales enfocadas: Recuerda que Optimize trata de sacar a la luz información a nivel de canal; al crear tu RTI, debes considerar cómo identificar el tráfico que proviene de un canal concreto. Tener esto en cuenta te ayudará a mantener tu RTI simple, enfocada y efectiva.

Un recordatorio rápido

  • Un Rule Target es el "dónde" al que la regla recurrirá para aplicar la lógica de la regla y encontrar el/los valor(es) de la regla.

  • La lógica de la regla es el "cómo" con el que la regla intentará identificar el tráfico.

  • Los valores de la regla son los datos de entrada que proporcionas a la regla para que los utilice.

Precisión y fiabilidad

Al diseñar tu RTI, los conceptos clave que debes tener en cuenta son la precisión y la fiabilidad. Las opciones de Rule Target y Rule Logic de una regla no deben considerarse intercambiables, aunque más de un conjunto de componentes funcione para un escenario determinado. Consulta las siguientes secciones para ver ejemplos de esto.

Elige un Rule Target

Los Rule Targets pueden evaluarse en cuanto a precisión y fiabilidad. El siguiente gráfico sitúa los distintos Rule Targets en términos de su precisión y fiabilidad respectivas. Cuanto más lejos esté un Rule Target del origen del gráfico, más preciso (a lo largo del eje x) y más fiable (a lo largo del eje y) será un Rule Target.

Siempre deberías intentar usar el Rule Target más fiable y preciso que puedas, y solo desplazarte a la izquierda o hacia abajo en el gráfico si no tienes otra opción. A continuación se muestran dos casos de ejemplo para escoger qué Rule Target usar.

Ejemplo 1: Búsqueda de pago

En este escenario, todo el tráfico de búsqueda de pago está etiquetado con el parámetro UTM de Google utm_medium=search. Debido a esto, el Parámetro de la página de destino debería ser el Rule Target. La regla para identificar comenzará a parecerse a esto:

Rule Target
Valor de la regla 1
Lógica de la regla

URL de la página de destino

utm_medium

*

*

Consulte la Lógica de la regla - Ejemplo 1 sección para ver qué debes completar en el Lógica de la regla y Valor de la regla 2.

Ejemplo 2: Búsqueda orgánica

El siguiente canal, Búsqueda orgánica, no tendrá parámetros UTM y la página de destino es impredecible. Estas condiciones descartan todos los Rule Targets que apuntan a parámetros y cadenas de consulta, así como todos los Rule Targets de página de destino. Puedes ver en el gráfico anterior que la mejor opción, considerando todos estos factores, es entonces la Dominio de referencia. La regla para identificar comenzará a parecerse a esto:

Rule Target
Valor de la regla 1
Lógica de la regla

Dominio de referencia

--

*

*

Consulte la Lógica de la regla - Ejemplo 2 sección para ver qué debes completar en el Lógica de la regla y Valor de la regla 2.

Elige una opción de lógica de la regla

La lógica de la regla solo puede evaluarse en cuanto a precisión. El siguiente gráfico sitúa las distintas opciones de lógica de la regla en términos de su precisión relativa.

Siempre deberías intentar usar la opción de lógica de la regla más precisa que puedas, y solo desplazarte hacia abajo en el gráfico si no tienes otra opción. A continuación se muestran dos casos de ejemplo para escoger qué opción de lógica de la regla usar.

Ejemplo 1: Búsqueda de pago

Dado que toda la búsqueda de pago está etiquetada con el parámetro UTM de Google utm_medium=search, la mejor opción posible de lógica de la regla sería Coincide exactamente.

Rule Target
Valor de la regla 1
Lógica de la regla

URL de la página de destino

utm_medium

Coincide exactamente

search

Coincide exactamente funciona mejor aquí porque solo el tráfico con el par clave-valor exacto del parámetro de utm_medium=search debería considerarse parte de este canal.

Si, por ejemplo, se utilizara la opción de lógica de la regla Contiene en su lugar, cualquier utm_medium valor con search que lo contenga se consideraría parte de este canal, lo que puede dar lugar a acciones mal atribuidas, compensaciones y potencialmente más. Contiene no sería, sin embargo, una elección incorrecta aquí; Coincide exactamente simplemente resulta ser la mejor opción.

Ejemplo 2: Búsqueda orgánica

Como el Rule Target Dominio de referencia se estableció antes como la mejor opción, una posible opción de lógica de la regla podría ser la siguiente:

Rule Target
Valor de la regla 1
Lógica de la regla

Dominio de referencia

--

Contiene

.bing.

Contiene es una buena opción aquí porque la búsqueda orgánica de Bing puede provenir de múltiples URL de referencia diferentes, como:

  • https://cn.bing.com

  • https://www4.bing.com/search

  • https://www2.bing.com/search

Debido a lo diferentes que pueden ser los dominios de tercer nivel (p. ej., www, cn), los dominios de nivel superior (p. ej., com, net), y las rutas de URL pueden serlo, simplemente asegurarse de que el dominio de referencia contenga el dominio de segundo nivel de .bing. permitirá que todo el tráfico de búsqueda orgánica procedente de Bing se considere parte de este canal.

Estas razones también explican por qué no pueden elegirse opciones de lógica de la regla más precisas, ya que excluirían dominios de referencia que deberían considerarse parte de este canal.

Opciones de lógica de la regla con expresiones regulares

Debido a la complejidad de implementar soluciones con expresiones regulares, impact.com no ofrece consejos generales ni orientación sobre cómo implementar expresiones regulares en Optimize. Si crees que tus circunstancias se manejan mejor con una opción de lógica de la regla basada en expresiones regulares, consulta con tu CSM cómo empezar a implementarla.

Coincide exactamente frente a Coincide con cualquiera

Estas dos opciones de lógica de la regla funcionan exactamente igual, pero con una pequeña diferencia. Coincide exactamente solo buscará el Valor de la regla 2 exacto tal como está escrito en la RTI. Coincide con cualquiera buscará todos los Valores de la regla 2 tal como están escritos exactamente en la regla.

Si te encuentras usando Coincide exactamente más de una vez con el AND operador, considera usar Coincide con cualquiera. Lo mismo ocurre con Contiene y Contiene cualquiera.

Click IDs comunes

Los Click IDs se están volviendo cada vez más comunes en los medios de pago. A continuación, se muestra una lista de Click IDs comunes que puedes usar para identificar tráfico.

Fuente de medios
ID del clic

Google Ads

GCLID

Bing Ads/Yahoo Search

MSCLKID

Facebook Ads

FBCLID

Pinterest

EPIK

Descalificación del tráfico

A veces, crear reglas para identificar que descalifican el tráfico puede ser tan útil para identificar el tráfico como parte de un canal. Consulta las subsecciones siguientes para ver cómo se pueden configurar los ejemplos creados arriba para descalificar tráfico.

Aquí está el ejemplo creado arriba:

Rule Target

Valor de la regla 1

Lógica de la regla

Valor de la regla 2

URL de la página de destino

utm_medium

Coincide exactamente

search

Esta regla ya descalifica mucho tráfico. Al añadir otra regla para identificar y usar el O operador, la regla puede ampliarse para calificar más tráfico:

Rule Target

Valor de la regla 1

Lógica de la regla

Valor de la regla 2

URL de la página de destino

utm_medium

Coincide exactamente

search

O

Parámetro de la página de destino

GCLID

Está presente

--

Ahora, si cualquiera de las dos reglas es verdadera, el tráfico se identificará como parte de este canal.

Aquí está el ejemplo creado arriba:

Rule Target
Valor de la regla 1
Lógica de la regla
Valor de la regla 2

Dominio de referencia

--

Contiene

.bing.

Esta regla identificará todo el tráfico remitido por Bing. Al añadir otra regla y usar el AND operador, la regla puede empezar a descalificar el tráfico remitido por Bing:

Rule Target
Valor de la regla 1
Lógica de la regla
Valor de la regla 2

Dominio de referencia

--

Contiene

.bing.

AND

Parámetro de la página de destino

MSCLIKID

No está presente

--

Ahora, ambas reglas deben ser verdaderas para que el tráfico se identifique como parte de este canal.

Distinción entre mayúsculas y minúsculas

Las Rules To Identify no distinguen entre mayúsculas y minúsculas. Por ejemplo, si tienes un parámetro en el que utm_medium=SEARCH, aún puedes configurar tu regla así:

Rule Target
Valor de la regla 1
Lógica de la regla
Valor de la regla 2

URL de la página de destino

utm_medium

Coincide exactamente

search

¿Qué sigue?

Revisa algunos escenarios de configuración de Optimize. Aquí encontrarás recomendaciones para escenarios comunes de Optimize.

Última actualización

¿Te fue útil?