> 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**: Familiarizzati con le seguenti risorse prima di proseguire con questo articolo:

* [Guida di avvio di Optimize](/brand/it/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [Che cos'è una Rule To Identify?](/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 Credit Group?](/brand/it/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
  {% endhint %}

Questo articolo approfondisce le funzionalità e le caratteristiche delle Rules To Identify (RTI) di Optimize. Imparerai come sviluppare una strategia per configurare le Rules To Identify (RTI) per nuovi canali o modificare i canali esistenti nel tuo programma.

Non esiste una soluzione universale adatta a tutte le circostanze. Tuttavia, dovresti essere in grado di arrivare a una soluzione che si adatti meglio alle tue circostanze specifiche. Possono sempre esistere argomentazioni contro una certa configurazione dell'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 fondamentali e funzionali necessarie per progettare le Rules To Identify ottimali per il tuo programma.

{% hint style="info" %}
**Mantieni le configurazioni dei canali focalizzate**: Ricorda che Optimize serve a evidenziare insight a livello di canale; quando crei il tuo RTI, devi considerare come identificare il traffico proveniente da un determinato canale. Tenere presente questo ti aiuterà a mantenere il tuo RTI semplice, focalizzato ed efficace.
{% endhint %}

**Un breve promemoria**

* La Rule Target è il "dove" la regola cercherà di applicare la Rule Logic e trovare il/i Rule Value.
* La Rule Logic è il "come" con cui la regola cercherà di identificare il traffico.
* I Rule Value sono gli input che fornisci alla regola da utilizzare.

#### 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 Rule Logic in una regola non devono essere considerate intercambiabili, anche se più di un insieme di componenti può funzionare in uno scenario specifico. Vedi le sezioni seguenti per esempi di questo.

<details>

<summary>Scegli una Rule Target</summary>

Le Rule Target possono essere valutate in base a precisione e affidabilità. Il grafico seguente mostra le varie Rule Target in termini di precisione e affidabilità rispettive. Più una Rule Target è lontana dall'origine del grafico, più è precisa (lungo l'asse x) e più affidabile (lungo l'asse y) è una Rule Target.

<div data-with-frame="true"><figure><img src="/files/95ab203bf48a1903eb2dcc3d11be21ffb0b086e6" alt=""><figcaption></figcaption></figure></div>

Dovresti sempre cercare di usare la Rule Target più affidabile e precisa possibile, e spostarti a sinistra o in basso nel grafico solo se non hai altre opzioni. Di seguito sono riportati due casi di esempio per scegliere quale Rule Target utilizzare.

**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 motivo, il **Parametro della landing page** dovrebbe essere la Rule Target. La Rule To Identify inizierà a presentarsi così:

<table><thead><tr><th width="128">Rule Target</th><th>Valore 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>

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

**Esempio 2: Ricerca organica**

Il canale successivo, Ricerca organica, non avrà parametri UTM e la landing page è imprevedibile. Queste condizioni escludono tutti i Rule Target che puntano a Parametri e Query String, così come tutti i Rule Target della landing page. Come puoi vedere dal grafico sopra, la scelta migliore considerando tutti questi fattori è quindi il **Dominio di riferimento**. La Rule To Identify inizierà a presentarsi così:

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

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

</details>

<details>

<summary>Scegli un'opzione di Rule Logic</summary>

La Rule Logic può essere valutata solo in termini di precisione. Il seguente grafico mostra le varie opzioni di Rule Logic in termini di precisione relativa.

<div data-with-frame="true"><figure><img src="/files/fbc239d5bdd0b2e41d187405555031354b85e7cb" alt=""><figcaption></figcaption></figure></div>

Dovresti sempre cercare di usare l'opzione di Rule Logic più precisa possibile, e spostarti verso il basso nel grafico solo se non hai altre opzioni. Di seguito sono riportati due casi di esempio per scegliere quale opzione di Rule Logic utilizzare.

**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 regola 1 | Logica della regola     |           |
| ---------------------- | --------------- | ----------------------- | --------- |
| URL della landing page | `utm_medium`    | Corrisponde esattamente | `ricerca` |

**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, ad esempio, l'opzione di Rule Logic **Contiene** fosse usata invece, qualsiasi `utm_medium` valore con `ricerca` al suo interno sarebbe considerato parte di questo canale, il che può portare ad azioni attribuite erroneamente, compensazioni e potenzialmente altro. **Contiene** non sarebbe comunque una scelta sbagliata qui; **Corrisponde esattamente** semplicemente, si dà il caso che sia la scelta migliore.

**Esempio 2: Ricerca organica**

Poiché in precedenza il Rule Target Dominio di riferimento è stato stabilito come la scelta migliore, una possibile opzione di Rule Logic potrebbe essere la seguente:

| Rule Target            | Valore 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:

* `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 possono essere così diversi, assicurarsi semplicemente che il dominio di riferimento contenga il dominio di secondo livello di **.bing.** consentirà di considerare tutto il traffico di ricerca organica proveniente da Bing come parte di questo canale.

</details>

Questi motivi spiegano anche perché non si possano scegliere 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'implementazione delle soluzioni regex, impact.com non fornisce consigli o indicazioni generali su come implementare le espressioni regolari in Optimize. Se pensi che le tue circostanze siano meglio gestite con un'opzione di Rule Logic regex, consulta il tuo CSM per capire come iniziare a implementarla.

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

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

Se ti capita di usare **Corrisponde esattamente** più di una volta con l' **E** operatore, considera di usare **Corrisponde a uno qualsiasi**. Lo stesso vale per **Contiene** e **Contiene uno qualsiasi**.

#### Click ID comuni

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

| Fonte media            | Click ID  |
| ---------------------- | --------- |
| Google Ads             | `GCLID`   |
| Bing Ads/Ricerca Yahoo | `MSCLKID` |
| Facebook Ads           | `FBCLID`  |
| Pinterest              | `EPIK`    |

#### Escludere il traffico

A volte, creare Rules To Identify che *escludono* il traffico può essere utile quanto identificare il traffico come parte di un canale. Vedi le sottosezioni seguenti per scoprire come gli esempi creati sopra possono essere configurati per escludere il traffico.

{% tabs %}
{% tab title="Esempio 1: Ricerca a pagamento" %}
Ecco l'esempio creato sopra:

|                        |                     |                         |                     |
| ---------------------- | ------------------- | ----------------------- | ------------------- |
| **Rule Target**        | **Valore regola 1** | **Logica della regola** | **Valore regola 2** |
| URL della landing page | `utm_medium`        | Corrisponde esattamente | `ricerca`           |

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

|                              |                     |                         |                     |
| ---------------------------- | ------------------- | ----------------------- | ------------------- |
| **Rule Target**              | **Valore regola 1** | **Logica della regola** | **Valore regola 2** |
| URL della landing page       | `utm_medium`        | Corrisponde esattamente | `ricerca`           |
| **O**                        |                     |                         |                     |
| 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 regola 1 | Logica della regola | Valore 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 proveniente da Bing:

| Rule Target                  | Valore regola 1 | Logica della regola | Valore 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.

#### Sensibilità alle maiuscole/minuscole

Le Rules To Identify non sono sensibili alle maiuscole/minuscole. Ad esempio, se hai un parametro in cui `utm_medium=SEARCH`, puoi comunque configurare la regola così:

| Rule Target            | Valore regola 1 | Logica della regola     | Valore regola 2 |
| ---------------------- | --------------- | ----------------------- | --------------- |
| URL della landing page | `utm_medium`    | Corrisponde esattamente | `ricerca`       |

#### Cosa c'è dopo?

Esamina 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 i più 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.