> 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**: Familiarizzatevi con le seguenti risorse prima di passare a 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 per 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 crediti?](/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 le funzioni delle Regole per identificare (RTI) di Optimize. Imparerete come sviluppare una strategia per configurare le Regole per identificare (RTI) per nuovi canali o modificare i canali esistenti nel vostro programma.

Non esiste una soluzione unica adatta a tutte le circostanze. Tuttavia, dovreste essere in grado di arrivare a una soluzione che si adatti al meglio alle vostre circostanze specifiche. Possono sempre esistere argomentazioni contro la configurazione di una certa RTI, ma **lo scopo di una RTI non è funzionare in tutte le circostanze**. **Una RTI deve essere adattata per adattarsi al meglio alle vostre circostanze specifiche**.

Questo documento fornirà le conoscenze di base e funzionali necessarie per progettare le Regole per identificare ottimali per il vostro programma.

{% hint style="info" %}
**Mantenete le configurazioni dei canali focalizzate**: Ricordate che Optimize serve a mettere in evidenza insight a livello di canale; quando create la vostra RTI, dovete considerare come identificare il traffico proveniente da un determinato canale. Tenere presente questo vi aiuterà a mantenere la vostra RTI semplice, mirata ed efficace.
{% endhint %}

**Un rapido promemoria**

* Un obiettivo della regola è il "dove" in cui la regola cercherà di applicare la Logica della regola e trovare il/i Valore/i della regola.
* La Logica della regola è il "come" con cui la regola tenterà di identificare il traffico.
* I Valori della regola sono input che fornite alla regola da sfruttare.

#### Precisione e affidabilità

Quando progettate la vostra RTI, i concetti chiave da tenere presenti sono la precisione e l'affidabilità. Le scelte per l'opzione Obiettivo della regola e Logica della regola in una regola non dovrebbero essere considerate intercambiabili, anche se più di un insieme di componenti può funzionare per un determinato scenario. Vedi le sezioni seguenti per esempi di questo.

<details>

<summary>Scegliete un obiettivo della regola</summary>

Gli obiettivi della regola possono essere valutati in termini di precisione e affidabilità. Il grafico seguente rappresenta i vari obiettivi della regola in termini di precisione e affidabilità relativi. Più un obiettivo della regola è lontano dall'origine del grafico, più è preciso (lungo l'asse x) e affidabile (lungo l'asse y).

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

Dovreste sempre cercare di usare l'obiettivo della regola più affidabile e preciso possibile, e spostarvi a sinistra o in basso nel grafico solo se non avete altra opzione. Di seguito sono riportati due casi di esempio per scegliere quale obiettivo della regola usare.

**Esempio 1: Ricerca a pagamento**

In questo scenario, tutto il traffico della ricerca a pagamento è contrassegnato dal parametro UTM di Google `utm_medium=search`. Per questo motivo, l' **Parametro della landing page** dovrebbe essere l'obiettivo della regola. La Regola per identificare inizierà ad apparire così:

<table><thead><tr><th width="128">Obiettivo della regola</th><th>Valore della regola 1</th><th>Logica della regola</th><th></th></tr></thead><tbody><tr><td>URL della landing page</td><td><code>utm_medium</code></td><td>*</td><td>*</td></tr></tbody></table>

Consulta la *Logica della regola - Esempio 1* sezione per vedere cosa inserire nel *Logica della regola* e *Valore della regola 2*.

**Esempio 2: Ricerca organica**

Il canale successivo, Ricerca organica, non avrà parametri UTM e la pagina di destinazione è imprevedibile. Queste condizioni escludono tutti gli Obiettivi della regola che si basano su Parametri e Stringhe di query, così come tutti gli Obiettivi della regola della pagina di destinazione. Potete vedere nel grafico sopra che l'opzione migliore, considerando tutti questi fattori, è quindi l' **Dominio di riferimento**. La Regola per identificare inizierà ad apparire così:

| Obiettivo della regola | Valore della regola 1 | Logica della regola |    |
| ---------------------- | --------------------- | ------------------- | -- |
| Dominio di riferimento | `--`                  | \*                  | \* |

Consulta la *Logica della regola - Esempio 2* sezione per vedere cosa inserire nel *Logica della regola* e *Valore della regola 2*.

</details>

<details>

<summary>Scegliete un'opzione di Logica della regola</summary>

La Logica della regola può essere valutata solo in termini di precisione. Il grafico seguente rappresenta le varie opzioni di Logica della regola in termini di precisione relativa.

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

Dovreste sempre cercare di usare l'opzione di Logica della regola più precisa possibile, e scendere nel grafico solo se non avete altra opzione. Di seguito sono riportati due casi di esempio per scegliere quale opzione di Logica della regola usare.

**Esempio 1: Ricerca a pagamento**

Poiché tutta la ricerca a pagamento è contrassegnata dal parametro UTM di Google `utm_medium=search`, la migliore opzione possibile di Logica della regola sarebbe **Corrisponde esattamente**.

| Obiettivo della regola | 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 Logica della regola **Contiene** fosse usata invece, qualsiasi `utm_medium` valore con `search` al suo interno sarebbe considerato parte di questo canale, il che può portare ad azioni, make-good e potenzialmente altro attribuiti in modo errato. **Contiene** non sarebbe comunque una scelta sbagliata qui; **Corrisponde esattamente** semplicemente è la scelta migliore.

**Esempio 2: Ricerca organica**

Con l'obiettivo della regola Dominio di riferimento stabilito in precedenza come scelta migliore, una possibile opzione di Logica della regola potrebbe essere la seguente:

| Obiettivo della regola | Valore della regola 1 | Logica della regola |        |
| ---------------------- | --------------------- | ------------------- | ------ |
| Dominio di riferimento | `--`                  | Contiene            | .bing. |

**Contiene** è una buona scelta qui perché la ricerca organica di Bing può derivare da più URL di riferimento diversi, come:

* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`

A causa di quanto possono essere diversi i domini di terzo livello (ad es., *www, cn*), i domini di primo livello (ad es., *com, net*), e i percorsi URL, il semplice fatto di 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.

</details>

Questi motivi sono anche il motivo per cui non è possibile scegliere opzioni di Logica della regola più precise, poiché escluderebbero domini di riferimento che dovrebbero essere considerati parte di questo canale.

**Opzioni di Logica della regola regex**

A causa della complessità nell'implementazione di soluzioni regex, impact.com non fornisce consigli generali o indicazioni su come implementare le espressioni regolari in Optimize. Se ritenete che le vostre circostanze siano gestite al meglio con un'opzione di Logica della regola regex, consultate il vostro CSM su come iniziare a implementarla.

#### Corrisponde esattamente vs. Corrisponde a uno qualsiasi

Queste due opzioni di Logica della regola funzionano esattamente allo stesso modo, ma con una piccola distinzione. *Corrisponde esattamente* cercherà solo il Valore della regola 2 esatto così come è scritto nella RTI. *Corrisponde a uno qualsiasi* cercherà tutti i Valori della regola 2 esattamente come sono scritti nella Regola.

Se vi ritrovate a usare **Corrisponde esattamente** più di una volta con l' **AND** operatore, considerate l'uso di **Corrisponde a uno qualsiasi**. Lo stesso vale per **Contiene** e **Contiene uno qualsiasi**.

#### ID click comuni

Gli ID click stanno diventando sempre più comuni nei media a pagamento. Di seguito è riportato un elenco di ID click comuni che potete usare per identificare il traffico.

| Sorgente media        | ID click  |
| --------------------- | --------- |
| Google Ads            | `GCLID`   |
| Bing Ads/Yahoo Search | `MSCLKID` |
| Facebook Ads          | `FBCLID`  |
| Pinterest             | `EPIK`    |

#### Traffico da escludere

A volte, creare Regole per identificare che *escludono* il traffico può essere utile quanto identificare il traffico come parte di un canale. Vedi le sottosezioni seguenti 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:

|                            |                           |                         |                           |
| -------------------------- | ------------------------- | ----------------------- | ------------------------- |
| **Obiettivo della regola** | **Valore della regola 1** | **Logica della regola** | **Valore della regola 2** |
| URL della landing page     | `utm_medium`              | Corrisponde esattamente | `search`                  |

Questa regola esclude già molto traffico. Aggiungendo un'altra Regola per identificare e usando l' **OPPURE** operatore, la regola può essere ampliata per qualificare più traffico:

|                              |                           |                         |                           |
| ---------------------------- | ------------------------- | ----------------------- | ------------------------- |
| **Obiettivo della regola**   | **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 verrà identificato come parte di questo canale.
{% endtab %}

{% tab title="Esempio 2: Ricerca organica" %}
Ecco l'esempio creato sopra:

| Obiettivo della regola | Valore della regola 1 | Logica della regola | Valore della regola 2 |
| ---------------------- | --------------------- | ------------------- | --------------------- |
| Dominio di riferimento | `--`                  | Contiene            | .bing.                |

Questa regola identificherà tutto il traffico segnalato da Bing. Aggiungendo un'altra regola e usando l' **AND** operatore, la regola può iniziare a escludere il traffico segnalato da Bing:

| Obiettivo della regola       | Valore della regola 1 | Logica della regola | Valore della regola 2 |
| ---------------------------- | --------------------- | ------------------- | --------------------- |
| Dominio di riferimento       | `--`                  | Contiene            | .bing.                |
| **AND**                      |                       |                     |                       |
| 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.

#### Sensibilità alle maiuscole

Le Regole per identificare non sono sensibili alle maiuscole. Ad esempio, se avete un parametro in cui `utm_medium=SEARCH`, potete comunque configurare la regola come segue:

| Obiettivo della regola | Valore della regola 1 | Logica della regola     | Valore della regola 2 |
| ---------------------- | --------------------- | ----------------------- | --------------------- |
| URL della landing page | `utm_medium`          | Corrisponde esattamente | `search`              |

#### Qual è il prossimo passo?

Esaminate 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 troverete raccomandazioni per i comuni scenari 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 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/it/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md?ask=<question>&goal=<endgoal>
```

`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.
