> 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/es/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md).

# Estrategia de configuración de canales

{% hint style="warning" %}
**Importante**: Familiarícese con los siguientes recursos antes de continuar con este artículo:

* [Guía de inicio de Optimize](/brand/es/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [¿Qué es una regla para identificar?](/brand/es/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [¿Qué es un grupo de crédito?](/brand/es/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
  {% endhint %}

Este artículo cubre las características y funciones de las Rules To Identify (RTI) de Optimize. Aprenderá cómo desarrollar una estrategia para configurar las Rules To Identify (RTI) para nuevos canales o modificar los canales existentes en su programa.

No existe una solución única que sirva para todas las circunstancias. Sin embargo, debería poder llegar a una solución que se adapte mejor a sus circunstancias particulares. Siempre pueden existir argumentos en contra de una determinada configuración de RTI, pero **el propósito de una RTI no es funcionar en todas las circunstancias**. **una RTI está pensada para adaptarse y ajustarse de la mejor manera a sus circunstancias específicas**.

Este documento ampliará los conocimientos fundamentales y funcionales necesarios para diseñar las Rules To Identify óptimas para su programa.

{% hint style="info" %}
**Mantenga las configuraciones de los canales enfocadas**: Recuerde que Optimize trata de sacar a la luz información a nivel de canal; al crear su RTI, debe considerar cómo identificar el tráfico procedente de un canal concreto. Tener esto presente le ayudará a mantener su RTI simple, enfocada y eficaz.
{% endhint %}

**Un recordatorio rápido**

* Un objetivo de la regla es "dónde" la regla buscará para aplicar la lógica de la regla y encontrar los valores de la regla.
* La lógica de la regla es "cómo" intentará la regla identificar el tráfico.
* Los valores de la regla son la información de entrada que usted proporciona a la regla.

#### Precisión y fiabilidad

Al diseñar su RTI, los conceptos clave que debe tener en cuenta son la precisión y la fiabilidad. Las opciones de Objetivo de la regla y Lógica de la regla en una regla no deben considerarse intercambiables, incluso si más de un conjunto de componentes funcionará para un escenario dado. Consulte las siguientes secciones para ver ejemplos de esto.

<details>

<summary>Elija un objetivo de la regla</summary>

Los objetivos de la regla pueden evaluarse en términos de precisión y fiabilidad. El siguiente gráfico muestra los distintos objetivos de la regla en términos de su precisión y fiabilidad respectivas. Cuanto más lejos del origen del gráfico esté un objetivo de la regla, más preciso (a lo largo del eje x) y más fiable (a lo largo del eje y) será un objetivo de la regla.

<div data-with-frame="true"><figure><img src="https://3147719151-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>

Siempre debe intentar usar el objetivo de la regla más fiable y preciso que pueda, y solo moverlo hacia la izquierda o hacia abajo en el gráfico si no tiene otra opción. A continuación, se presentan dos casos de ejemplo sobre cómo elegir qué objetivo de la regla 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`. Por este motivo, el **Parámetro de la página de destino** debería ser el objetivo de la regla. La regla para identificar comenzará a verse así:

<table><thead><tr><th width="128">Objetivo de la regla</th><th>Valor de la regla 1</th><th>Lógica de la regla</th><th></th></tr></thead><tbody><tr><td>URL de la página de destino</td><td><code>utm_medium</code></td><td>*</td><td>*</td></tr></tbody></table>

Consulte la *Lógica de la regla - Ejemplo 1* sección para ver qué 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 objetivos de la regla que apuntan a parámetros y cadenas de consulta, así como todos los objetivos de la regla de página de destino. Puede ver en el gráfico anterior que la mejor opción teniendo en cuenta todos estos factores es entonces el **Dominio de referencia**. La regla para identificar comenzará a verse así:

| Objetivo de la regla  | 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é completar en el *Lógica de la regla* y *Valor de la regla 2*.

</details>

<details>

<summary>Elija una opción de lógica de la regla</summary>

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

<div data-with-frame="true"><figure><img src="https://3147719151-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>

Siempre debe intentar usar la opción de lógica de la regla más precisa que pueda, y solo moverla hacia abajo en el gráfico si no tiene otra opción. A continuación, se presentan dos casos de ejemplo sobre cómo elegir 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**.

| Objetivo de la regla        | Valor de la regla 1 | Lógica de la regla   |            |
| --------------------------- | ------------------- | -------------------- | ---------- |
| URL de la página de destino | `utm_medium`        | Coincide exactamente | `búsqueda` |

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

Si, por ejemplo, se usara la opción de lógica de la regla **Contiene** en su lugar, cualquier `utm_medium` valor con `búsqueda` en él se consideraría parte de este canal, lo que puede dar lugar a acciones mal atribuidas, compensaciones y posiblemente más. **Contiene** no obstante, no sería una mala elección aquí; **Coincide exactamente** simplemente resulta ser la mejor opción.

**Ejemplo 2: Búsqueda orgánica**

Con el objetivo de la regla de dominio de referencia establecido anteriormente como la mejor opción, una posible opción de lógica de la regla podría ser la siguiente:

| Objetivo de la regla  | 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, simplemente asegurar 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.

</details>

Estas razones también explican por qué no se pueden elegir 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 regex, impact.com no ofrece consejos ni orientación generales sobre cómo implementar expresiones regulares en Optimize. Si cree que sus circunstancias se gestionan mejor con una opción de lógica de la regla con regex, consulte con su CSM sobre cómo comenzar 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 distinción. *Coincide exactamente* solo buscará el valor exacto de la regla 2 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 se encuentra usando **Coincide exactamente** más de una vez con el **Y** operador, considere usar **Coincide con cualquiera**. Lo mismo ocurre con **Contiene** y **Contiene cualquiera**.

#### IDs de clic comunes

Los IDs de clic son cada vez más comunes en los medios de pago. La siguiente es una lista de IDs de clic comunes que puede 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 Rules To Identify que *descalifican* el tráfico puede ser tan útil para identificar tráfico como parte de un canal. Consulte las siguientes subsecciones para ver cómo los ejemplos creados arriba se pueden configurar para descalificar tráfico.

{% tabs %}
{% tab title="Ejemplo 1: Búsqueda de pago" %}
Aquí está el ejemplo que se creó arriba:

|                             |                         |                        |                         |
| --------------------------- | ----------------------- | ---------------------- | ----------------------- |
| **Objetivo de la regla**    | **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   | `búsqueda`              |

Esta regla ya descalifica mucho tráfico. Al agregar otra Rule To Identify y usar el **O** operador, la regla puede ampliarse para calificar más tráfico:

|                                   |                         |                        |                         |
| --------------------------------- | ----------------------- | ---------------------- | ----------------------- |
| **Objetivo de la regla**          | **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   | `búsqueda`              |
| **O**                             |                         |                        |                         |
| Parámetro de la página de destino | `GCLID`                 | Está presente          | --                      |

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

{% tab title="Ejemplo 2: Búsqueda orgánica" %}
Aquí está el ejemplo que se creó arriba:

| Objetivo de la regla  | 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 referido por Bing. Al agregar otra regla y usar el **Y** operador, la regla puede empezar a descalificar el tráfico referido por Bing:

| Objetivo de la regla              | Valor de la regla 1 | Lógica de la regla | Valor de la regla 2 |
| --------------------------------- | ------------------- | ------------------ | ------------------- |
| Dominio de referencia             | `--`                | Contiene           | .bing.              |
| **Y**                             |                     |                    |                     |
| Parámetro de la página de destino | `MSCLIKID`          | No está presente   | --                  |
| {% endtab %}                      |                     |                    |                     |
| {% endtabs %}                     |                     |                    |                     |

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 tiene un parámetro donde `utm_medium=SEARCH`, aún puede configurar su regla como:

| Objetivo de la regla        | 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 | `búsqueda`          |

#### ¿Qué sigue?

Revise algunos [escenarios de configuración de Optimize](/brand/es/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md). Aquí encontrará recomendaciones para escenarios comunes de 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.impact.com/brand/es/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.