> 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/pt-br/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md).
# Estratégia de configuração de canais
{% hint style="warning" %}
**Importante**: Familiarize-se com os recursos a seguir antes de prosseguir para este artigo:
* [Guia de início do Optimize](/brand/pt-br/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [O que é uma Regra para Identificar?](/brand/pt-br/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [O que é um Grupo de Crédito?](/brand/pt-br/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
{% endhint %}
Este artigo aborda os recursos e as funções das Regras para Identificar (RTI) do Optimize. Você aprenderá como desenvolver uma estratégia para configurar as Regras para Identificar (RTI) para novos canais ou modificar canais existentes no seu programa.
Não existe uma solução única que sirva para todas as situações. No entanto, você deve conseguir chegar a uma solução que melhor se adapte às suas circunstâncias específicas. Sempre podem existir argumentos contra a configuração de uma determinada RTI, mas **o objetivo de uma RTI não é funcionar em todas as situações**. **Uma RTI deve ser moldada para se adequar da melhor forma às suas circunstâncias específicas**.
Este documento avançará o conhecimento fundamental e funcional necessário para projetar as Regras para Identificar ideais para o seu programa.
{% hint style="info" %}
**Mantenha as configurações do canal focadas**: Lembre-se de que o Optimize trata de destacar insights no nível do canal; ao criar sua RTI, você deve considerar como identificar o tráfego proveniente de um canal específico. Ter isso em mente ajudará a manter sua RTI simples, focada e eficaz.
{% endhint %}
**Um lembrete rápido**
* Um Alvo da Regra é o "onde" a regra buscará aplicar a Lógica da Regra e encontrar o(s) Valor(es) da Regra.
* A Lógica da Regra é o "como" a Regra tentará identificar o tráfego.
* Os Valores da Regra são as entradas que você fornece à regra para serem aproveitadas.
#### Precisão e Confiabilidade
Ao projetar sua RTI, os conceitos-chave a serem lembrados são precisão e confiabilidade. As escolhas para a opção de Alvo da Regra e Lógica da Regra em uma Regra não devem ser vistas como intercambiáveis, mesmo que mais de um conjunto de componentes funcione para um determinado cenário. Veja as seções a seguir para exemplos disso.
Escolha um Alvo da Regra
Os Alvos da Regra podem ser avaliados quanto à precisão e confiabilidade. O gráfico a seguir mostra os vários Alvos da Regra em termos de sua respectiva precisão e confiabilidade. Quanto mais distante da origem do gráfico estiver um Alvo da Regra, mais preciso (ao longo do eixo x) e mais confiável (ao longo do eixo y) ele é.
Você deve sempre tentar usar o Alvo da Regra mais confiável e preciso possível e só mover para a esquerda ou para baixo no gráfico se não tiver outra opção. Abaixo estão dois casos de exemplo de como escolher qual Alvo da Regra usar.
**Exemplo 1: Pesquisa paga**
Neste cenário, todo o tráfego de pesquisa paga é marcado com o parâmetro UTM do Google `utm_medium=search`. Por isso, o **Parâmetro da landing page** Parâmetro da query string
| Destino da regra | Valor 1 da regra | Lógica da regra | |
|---|
| URL da página de destino | utm_medium | * | * |
Consulte a *deve ser o Alvo da Regra. A Regra para Identificar começará a ficar assim:* Valores da Regra *Lógica da regra* e *Valor 2 da regra*.
**Exemplo 2: Pesquisa orgânica**
O próximo canal, Pesquisa orgânica, não terá parâmetros UTM e a página de destino é imprevisível. Essas condições eliminam todos os Alvos da Regra que têm como alvo Parâmetros e Strings de Consulta, bem como todos os Alvos da Regra de Página de Destino. Você pode ver pelo gráfico acima que a melhor opção considerando todos esses fatores é então o **Domínio de Referência**Domínio de referência
| Destino da regra | Valor 1 da regra | Lógica da regra | |
| --------------------- | ---------------- | --------------- | -- |
| Domínio de Referência | `--` | \* | \* |
Consulte a *. A Regra para Identificar começará a ficar assim:* Valores da Regra *Lógica da regra* e *Valor 2 da regra*.
Escolha uma opção de Lógica da Regra
A Lógica da Regra só pode ser avaliada quanto à precisão. O gráfico a seguir mostra as várias opções de Lógica da Regra em termos de sua precisão relativa.
Você deve sempre tentar usar a opção de Lógica da Regra mais precisa possível e só descer no gráfico se não tiver outra opção. Abaixo estão dois casos de exemplo de como escolher qual opção de Lógica da Regra usar.
**Exemplo 1: Pesquisa paga**
Como toda a pesquisa paga é marcada com o parâmetro UTM do Google `utm_medium=search`, a melhor opção possível de Lógica da Regra seria **Corresponde exatamente a**.
| Destino da regra | Valor 1 da regra | Lógica da regra | |
| ------------------------ | ---------------- | ------------------------ | ------- |
| URL da página de destino | `utm_medium` | Corresponde exatamente a | `busca` |
**Corresponde exatamente a** Corresponde exatamente `utm_medium=search` utm\_medium=search
funciona melhor aqui porque apenas o tráfego com o par chave-valor exato de parâmetro **Contém** Corresponde a qualquer um `utm_medium` valor do parâmetro `busca` search **Contém** Corresponde a qualquer um **Corresponde exatamente a** Corresponde exatamente
**Exemplo 2: Pesquisa orgânica**
Com o Alvo da Regra de Domínio de referência estabelecido como a melhor escolha anteriormente, uma possível opção de Lógica da Regra poderia ser a seguinte:
| Destino da regra | Valor 1 da regra | Lógica da regra | |
| --------------------- | ---------------- | --------------- | ------ |
| Domínio de Referência | `--` | Contém | .bing. |
**Contém** é uma boa escolha aqui porque a pesquisa orgânica do Bing pode vir de várias URLs de referência diferentes, como:
* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`
Devido ao quanto os domínios de terceiro nível (ex.: *www, cn*), os domínios de nível superior (ex.: *com, net*), e os caminhos de URL podem variar, simplesmente garantir que o domínio de referência contenha o domínio de segundo nível de **.bing.** bing
permitirá que todo o tráfego de pesquisa orgânica proveniente do Bing seja considerado parte deste canal.
**Opções de Lógica da Regra com Regex**
Devido à complexidade de implementar soluções com regex, a impact.com não oferece orientação geral sobre como implementar expressões regulares no Optimize. Se você acha que suas circunstâncias são melhor tratadas com uma opção de Lógica da Regra com regex, consulte seu CSM sobre como começar a implementá-la.
#### Corresponde exatamente vs. Corresponde a qualquer um
Essas duas opções de Lógica da Regra funcionam exatamente da mesma forma, mas com uma pequena distinção. *Corresponde exatamente a* só pesquisará o Valor 2 da Regra exato, como ele está escrito na RTI. *Corresponde a qualquer um* pesquisará todos os Valores 2 da Regra exatamente como eles estão escritos na Regra.
Se você perceber que está usando **Corresponde exatamente a** mais de uma vez com o **E** operador, considere usar **Corresponde a qualquer um**. O mesmo vale para **Contém** e **Contém qualquer um**.
#### IDs de clique comuns
Os IDs de clique estão se tornando cada vez mais comuns para mídia paga. A seguir está uma lista de IDs de clique comuns que você pode usar para identificar o tráfego.
| Fonte de mídia | ID de clique |
| -------------------------- | ------------ |
| Google Ads | `GCLID` |
| Bing Ads/Pesquisa do Yahoo | `MSCLKID` |
| Facebook Ads | `FBCLID` |
| Pinterest | `EPIK` |
#### Tráfego desqualificado
Às vezes, criar Regras para Identificar que *desqualificam* tráfego pode ser tão útil para identificar o tráfego como parte de um canal quanto as regras de qualificação. Veja as subseções abaixo para entender como os exemplos criados acima podem ser configurados para desqualificar o tráfego.
{% tabs %}
{% tab title="Exemplo 1: Pesquisa paga" %}
Aqui está o exemplo criado acima:
| | | | |
| ------------------------ | -------------------- | ------------------------ | -------------------- |
| **Destino da regra** | **Valor 1 da regra** | **Lógica da regra** | **Valor 2 da regra** |
| URL da página de destino | `utm_medium` | Corresponde exatamente a | `busca` |
Esta regra já desqualifica muito tráfego. Ao adicionar outra Regra para Identificar e usar o **OR** operador OU, a Regra pode ser expandida para qualificar mais tráfego:
| | | | |
| ------------------------- | -------------------- | ------------------------ | -------------------- |
| **Destino da regra** | **Valor 1 da regra** | **Lógica da regra** | **Valor 2 da regra** |
| URL da página de destino | `utm_medium` | Corresponde exatamente a | `busca` |
| **OR** | | | |
| Parâmetro da landing page | `GCLID` | Estiver presente | -- |
Agora, se qualquer uma das Regras for verdadeira, o tráfego será identificado como parte deste canal.
{% endtab %}
{% tab title="Exemplo 2: Pesquisa orgânica" %}
Aqui está o exemplo criado acima:
| Destino da regra | Valor 1 da regra | Lógica da regra | Valor 2 da regra |
| --------------------- | ---------------- | --------------- | ---------------- |
| Domínio de Referência | `--` | Contém | .bing. |
Esta regra identificará todo o tráfego que foi referido pelo Bing. Ao adicionar outra Regra e usar o **E** operador E, a Regra pode começar a desqualificar o tráfego referido pelo Bing:
| Destino da regra | Valor 1 da regra | Lógica da regra | Valor 2 da regra |
| ------------------------- | ---------------- | -------------------- | ---------------- |
| Domínio de Referência | `--` | Contém | .bing. |
| **E** | | | |
| Parâmetro da landing page | `MSCLIKID` | Não estiver presente | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
Agora, ambas as Regras devem ser verdadeiras para que o tráfego seja identificado como parte deste canal.
#### Sensibilidade a maiúsculas e minúsculas
As Regras para Identificar não diferenciam maiúsculas de minúsculas. Por exemplo, se você tiver um parâmetro em que `utm_medium=SEARCH`, você ainda pode configurar sua regra assim:
| Destino da regra | Valor 1 da regra | Lógica da regra | Valor 2 da regra |
| ------------------------ | ---------------- | ------------------------ | ---------------- |
| URL da página de destino | `utm_medium` | Corresponde exatamente a | `busca` |
#### E agora?
Revise alguns [cenários de configuração do Optimize](/brand/pt-br/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md). Aqui, você encontrará recomendações para cenários comuns do 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.impact.com/brand/pt-br/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.