> 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/it/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md).
# Strategia di configurazione dei canali
{% hint style="warning" %}
**Importante**: Acquisisci familiarità con le seguenti risorse prima di proseguire con questo articolo:
* [Guida introduttiva di Optimize](/brand/it/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [Che cos'è una regola da identificare?](/brand/it/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [Che cos'è un gruppo di credito?](/brand/it/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
{% endhint %}
Questo articolo tratta le funzionalità e i meccanismi delle Regole da identificare (RTI) di Optimize. Imparerai come sviluppare una strategia per configurare le Regole da identificare (RTI) per nuovi canali o modificare i canali esistenti nel tuo programma.
Non esiste una soluzione universale che si adatti a tutte le circostanze. Tuttavia, dovresti essere in grado di arrivare a una soluzione che si adatti al meglio alle tue circostanze specifiche. Possono sempre esistere argomenti contro la configurazione di un certo RTI, ma **lo scopo di un RTI non è funzionare in tutte le circostanze**. **Un RTI è pensato per essere modellato in modo da adattarsi al meglio alle tue circostanze specifiche**.
Questo documento approfondirà le conoscenze di base e funzionali necessarie per progettare le Regole da identificare ottimali per il tuo programma.
{% hint style="info" %}
**Mantieni concentrate le configurazioni dei canali**: Ricorda che Optimize serve a mettere in evidenza insight a livello di canale; quando crei il tuo RTI, devi considerare come identificare il traffico proveniente da un canale specifico. Tenere presente questo ti aiuterà a mantenere il tuo RTI semplice, mirato ed efficace.
{% endhint %}
**Un rapido promemoria**
* Un Rule Target è il "dove" in cui la regola cercherà di applicare la logica della regola e trovare il/i Valore/i della regola.
* La Rule Logic è il "come" con cui la regola tenterà di identificare il traffico.
* I Rule Values sono gli input che fornisci alla regola come supporto.
#### Precisione e affidabilità
Quando progetti il tuo RTI, i concetti chiave da tenere a mente sono precisione e affidabilità. Le scelte per l'opzione Rule Target e l'opzione Rule Logic in una regola non devono essere considerate intercambiabili, anche se più di un insieme di componenti funziona per un determinato scenario. Consulta le sezioni seguenti per esempi di questo.
Scegli un Rule Target
I Rule Target possono essere valutati in termini di precisione e affidabilità. Il seguente grafico rappresenta i vari Rule Target in base alla loro precisione e affidabilità rispettive. Più un Rule Target è lontano dall'origine del grafico, più è preciso (lungo l'asse x) e più è affidabile (lungo l'asse y).
Dovresti sempre cercare di usare il Rule Target più affidabile e preciso possibile, e spostarti a sinistra o in basso nel grafico solo se non hai altre opzioni. Di seguito sono riportati due casi di esempio su come scegliere quale Rule Target usare.
**Esempio 1: Ricerca a pagamento**
In questo scenario, tutto il traffico di ricerca a pagamento è contrassegnato dal parametro UTM di Google `utm_medium=search`. Per questo, il **Parametro della landing page** dovrebbe essere il Rule Target. La regola da identificare inizierà ad apparire così:
| Rule Target | Valore della regola 1 | Logica della regola | |
|---|
| URL della landing page | utm_medium | * | * |
Visualizza il *Logica della regola - Esempio 1* sezione per vedere cosa inserire per il *Logica della regola* e *Valore della regola 2*.
**Esempio 2: Ricerca organica**
Il canale successivo, la Ricerca organica, non avrà parametri UTM e la landing page è imprevedibile. Queste condizioni escludono tutti i Rule Target che hanno come obiettivo Parametri e stringhe di query, così come tutti i Rule Target della landing page. Puoi vedere dal grafico sopra che, considerando tutti questi fattori, l'opzione migliore è allora il **Dominio di riferimento**. La regola da identificare inizierà ad apparire così:
| Rule Target | Valore della regola 1 | Logica della regola | |
| ---------------------- | --------------------- | ------------------- | -- |
| Dominio di riferimento | `--` | \* | \* |
Visualizza il *Logica della regola - Esempio 2* sezione per vedere cosa inserire per il *Logica della regola* e *Valore della regola 2*.
Scegli un'opzione di Rule Logic
La Rule Logic può essere valutata solo in termini di precisione. Il seguente grafico rappresenta le varie opzioni di Rule Logic in base alla loro precisione relativa.
Dovresti sempre cercare di usare l'opzione di Rule Logic più precisa possibile, e scendere nel grafico solo se non hai altre opzioni. Di seguito sono riportati due casi di esempio su come scegliere quale opzione di Rule Logic usare.
**Esempio 1: Ricerca a pagamento**
Poiché tutta la ricerca a pagamento è contrassegnata dal parametro UTM di Google `utm_medium=search`, l'opzione di Rule Logic migliore possibile sarebbe **Corrisponde esattamente**.
| Rule Target | Valore della regola 1 | Logica della regola | |
| ---------------------- | --------------------- | ----------------------- | -------- |
| URL della landing page | `utm_medium` | Corrisponde esattamente | `search` |
**Corrisponde esattamente** funziona meglio qui perché solo il traffico con l'esatta coppia chiave-valore del parametro di `utm_medium=search` dovrebbe essere considerato parte di questo canale.
Se, per esempio, l'opzione di Rule Logic **Contiene** fosse usata invece, qualsiasi `utm_medium` valore con `search` in esso sarebbe considerato parte di questo canale, il che può portare ad azioni attribuite in modo errato, compensazioni e potenzialmente altro. **Contiene** non sarebbe comunque una scelta sbagliata qui; **Corrisponde esattamente** semplicemente è la scelta migliore.
**Esempio 2: Ricerca organica**
Con il Rule Target del dominio di riferimento stabilito in precedenza come scelta migliore, una possibile opzione di Rule Logic potrebbe essere la seguente:
| Rule Target | Valore della regola 1 | Logica della regola | |
| ---------------------- | --------------------- | ------------------- | ------ |
| Dominio di riferimento | `--` | Contiene | .bing. |
**Contiene** è una buona scelta qui perché la ricerca organica di Bing può provenire da più URL di riferimento diversi, come ad esempio:
* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`
A causa di quanto possano essere diversi i domini di terzo livello (ad es., *www, cn*), i domini di primo livello (ad es., *com, net*), e i percorsi URL possano essere, semplicemente assicurarsi che il dominio di riferimento contenga il dominio di secondo livello di **.bing.** consentirà di considerare parte di questo canale tutto il traffico di ricerca organica proveniente da Bing.
Questi motivi spiegano anche perché non possano essere scelte opzioni di Rule Logic più precise, poiché escluderebbero domini di riferimento che dovrebbero essere considerati parte di questo canale.
**Opzioni di Rule Logic regex**
A causa della complessità nell'implementare soluzioni regex, impact.com non fornisce consigli o indicazioni generali su come implementare le espressioni regolari in Optimize. Se ritieni che le tue circostanze siano gestite al meglio con un'opzione di Rule Logic regex, consulta il tuo CSM su come iniziare a implementarla.
#### Corrisponde esattamente vs. Corrisponde a qualsiasi
Queste due opzioni di Rule Logic funzionano esattamente allo stesso modo, ma con una piccola distinzione. *Corrisponde esattamente* cercherà solo il Valore della regola 2 esatto così come è scritto nell'RTI. *Corrisponde a qualsiasi* cercherà tutti i Valori della regola 2 così come sono scritti esattamente nella Regola.
Se ti ritrovi a usare **Corrisponde esattamente** più di una volta con l' **E** operatore, valuta l'uso di **Corrisponde a qualsiasi**. Lo stesso vale per **Contiene** e **Contiene qualsiasi**.
#### Click ID comuni
I Click ID stanno diventando sempre più comuni per i media a pagamento. Di seguito è riportato un elenco di Click ID comuni che puoi usare per identificare il traffico.
| Fonte media | ID clic |
| ---------------------- | --------- |
| Google Ads | `GCLID` |
| Bing Ads/Ricerca Yahoo | `MSCLKID` |
| Facebook Ads | `FBCLID` |
| Pinterest | `EPIK` |
#### Traffico da escludere
A volte, creare Regole da identificare che *escludono* il traffico può essere utile quanto identificarlo come parte di un canale. Consulta le sottosezioni qui sotto per vedere come gli esempi creati sopra possano essere configurati per escludere il traffico.
{% tabs %}
{% tab title="Esempio 1: Ricerca a pagamento" %}
Ecco l'esempio creato sopra:
| | | | |
| ---------------------- | ------------------------- | ----------------------- | ------------------------- |
| **Rule Target** | **Valore della regola 1** | **Logica della regola** | **Valore della regola 2** |
| URL della landing page | `utm_medium` | Corrisponde esattamente | `search` |
Questa regola già esclude molto traffico. Aggiungendo un'altra Regola da identificare e usando l' **OPPURE** operatore, la regola può essere ampliata per qualificare più traffico:
| | | | |
| ---------------------------- | ------------------------- | ----------------------- | ------------------------- |
| **Rule Target** | **Valore della regola 1** | **Logica della regola** | **Valore della regola 2** |
| URL della landing page | `utm_medium` | Corrisponde esattamente | `search` |
| **OPPURE** | | | |
| Parametro della landing page | `GCLID` | È presente | -- |
Ora, se una delle due Regole è vera, il traffico sarà identificato come parte di questo canale.
{% endtab %}
{% tab title="Esempio 2: Ricerca organica" %}
Ecco l'esempio creato sopra:
| Rule Target | Valore della regola 1 | Logica della regola | Valore della regola 2 |
| ---------------------- | --------------------- | ------------------- | --------------------- |
| Dominio di riferimento | `--` | Contiene | .bing. |
Questa regola identificherà tutto il traffico che è stato indirizzato da Bing. Aggiungendo un'altra Regola e usando l' **E** operatore, la regola può iniziare a escludere il traffico indirizzato da Bing:
| Rule Target | Valore della regola 1 | Logica della regola | Valore della regola 2 |
| ---------------------------- | --------------------- | ------------------- | --------------------- |
| Dominio di riferimento | `--` | Contiene | .bing. |
| **E** | | | |
| Parametro della landing page | `MSCLIKID` | Non è presente | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
Ora, entrambe le Regole devono essere vere affinché il traffico venga identificato come parte di questo canale.
#### Distinzione tra maiuscole e minuscole
Le Regole da identificare non distinguono tra maiuscole e minuscole. Ad esempio, se hai un parametro in cui `utm_medium=SEARCH`, puoi comunque configurare la tua regola come:
| Rule Target | Valore della regola 1 | Logica della regola | Valore della regola 2 |
| ---------------------- | --------------------- | ----------------------- | --------------------- |
| URL della landing page | `utm_medium` | Corrisponde esattamente | `search` |
#### Cosa succede ora?
Rivedi alcuni [scenari di configurazione di Optimize](/brand/it/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md). Qui troverai raccomandazioni per scenari comuni di 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/it/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 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.
