> 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/de/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md).
# Strategie für die Kanaleinrichtung
{% hint style="warning" %}
**Wichtig**: Machen Sie sich mit den folgenden Ressourcen vertraut, bevor Sie mit diesem Artikel fortfahren:
* [Leitfaden zum Einstieg in Optimize](/brand/de/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [Was ist eine Rule To Identify?](/brand/de/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [Was ist eine Credit Group?](/brand/de/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
{% endhint %}
Dieser Artikel behandelt die Merkmale und Funktionen der Rules To Identify (RTI) von Optimize. Sie lernen, wie Sie eine Strategie entwickeln, um die Rules To Identify (RTI) für neue Kanäle einzurichten oder bestehende Kanäle in Ihrem Programm anzupassen.
Es gibt keine Einheitslösung, die in allen Situationen passt. Sie sollten jedoch in der Lage sein, zu einer Lösung zu gelangen, die am besten zu Ihren individuellen Umständen passt. Gegen die Einrichtung eines bestimmten RTI können immer Argumente sprechen, aber **der Zweck eines RTI besteht nicht darin, unter allen Umständen zu funktionieren**. **Ein RTI soll so geformt werden, dass er am besten zu Ihren spezifischen Umständen passt**.
Dieses Dokument vermittelt das grundlegende und funktionale Wissen, das erforderlich ist, um die optimalen Rules To Identify für Ihr Programm zu entwerfen.
{% hint style="info" %}
**Kanal-Setups fokussiert halten**: Denken Sie daran, dass Optimize dazu dient, Einblicke auf Kanalebene sichtbar zu machen; beim Erstellen Ihres RTI müssen Sie berücksichtigen, wie der Traffic eines bestimmten Kanals identifiziert werden kann. Wenn Sie dies im Hinterkopf behalten, bleibt Ihr RTI einfach, fokussiert und effektiv.
{% endhint %}
**Eine kurze Erinnerung**
* Ein Regelziel ist das „wo“, an dem die Regel nach der Anwendung der Regel-Logik und dem Auffinden von Regelwert(en) sucht.
* Die Regel-Logik ist das „wie“, mit dem die Regel versucht, Traffic zu identifizieren.
* Regelwerte sind Eingaben, die Sie der Regel als Grundlage bereitstellen.
#### Präzision & Zuverlässigkeit
Bei der Gestaltung Ihres RTI sind Präzision und Zuverlässigkeit die wichtigsten Konzepte, die Sie im Hinterkopf behalten sollten. Die Auswahl der Optionen für Regelziel und Regel-Logik in einer Regel sollte nicht als austauschbar betrachtet werden, auch wenn mehr als eine Kombination von Komponenten für ein bestimmtes Szenario funktioniert. In den folgenden Abschnitten finden Sie Beispiele dafür.
Wählen Sie ein Regelziel
Regelziele können im Hinblick auf Präzision und Zuverlässigkeit bewertet werden. Das folgende Diagramm zeigt die verschiedenen Regelziele hinsichtlich ihrer jeweiligen Präzision und Zuverlässigkeit. Je weiter ein Regelziel vom Ursprung des Diagramms entfernt ist, desto präziser (entlang der x-Achse) und desto zuverlässiger (entlang der y-Achse) ist es.
Sie sollten stets versuchen, das zuverlässigste und präziseste Regelziel zu verwenden, das Ihnen zur Verfügung steht, und nur nach links oder unten im Diagramm gehen, wenn Sie keine andere Wahl haben. Nachfolgend finden Sie zwei Beispielanwendungen dafür, wie Sie auswählen, welches Regelziel verwendet werden soll.
**Beispiel 1: Bezahlte Suche**
In diesem Szenario ist der gesamte Traffic aus bezahlter Suche mit dem UTM-Parameter von Google markiert `utm_medium=search`. Aus diesem Grund **Landingpage-Parameter** sollte das Regelziel sein. Die Rule To Identify wird dann etwa so aussehen:
| Regelziel | Regelwert 1 | Regel-Logik | |
|---|
| Zielseiten-URL | utm_medium | * | * |
Sehen Sie sich die *Regel-Logik - Beispiel 1* Abschnitt, um zu sehen, was für den *Regel-Logik* und *Regelwert 2*.
**Beispiel 2: Organische Suche**
Der nächste Kanal, Organic Search, wird keine UTM-Parameter haben und die Landingpage ist unvorhersehbar. Diese Bedingungen schließen alle Regelziele aus, die auf Parameter und Abfragezeichenfolgen sowie alle Landingpage-Regelziele abzielen. Wie Sie in der obigen Grafik sehen können, ist unter Berücksichtigung all dieser Faktoren die beste Option dann das **Verweisende Domain**. Die Rule To Identify wird dann etwa so aussehen:
| Regelziel | Regelwert 1 | Regel-Logik | |
| ------------------ | ----------- | ----------- | -- |
| Verweisende Domain | `--` | \* | \* |
Sehen Sie sich die *Regel-Logik - Beispiel 2* Abschnitt, um zu sehen, was für den *Regel-Logik* und *Regelwert 2*.
Wählen Sie eine Option für die Regel-Logik
Die Regel-Logik kann nur im Hinblick auf Präzision bewertet werden. Das folgende Diagramm zeigt die verschiedenen Optionen für die Regel-Logik in Bezug auf ihre relative Präzision.
Sie sollten stets versuchen, die präziseste Option für die Regel-Logik zu verwenden, die Ihnen zur Verfügung steht, und nur nach unten im Diagramm gehen, wenn Sie keine andere Wahl haben. Nachfolgend finden Sie zwei Beispielanwendungen dafür, wie Sie auswählen, welche Option für die Regel-Logik verwendet werden soll.
**Beispiel 1: Bezahlte Suche**
Da die gesamte bezahlte Suche mit dem UTM-Parameter von Google markiert ist `utm_medium=search`, wäre die bestmögliche Option für die Regel-Logik **Genau übereinstimmt**.
| Regelziel | Regelwert 1 | Regel-Logik | |
| -------------- | ------------ | ------------------- | ------- |
| Zielseiten-URL | `utm_medium` | Genau übereinstimmt | `Suche` |
**Genau übereinstimmt** funktioniert hier am besten, weil nur Traffic mit dem exakten Parameter-Schlüssel-Wert-Paar von `utm_medium=search` als Teil dieses Kanals betrachtet werden sollte.
Wenn beispielsweise die Option für die Regel-Logik **Enthält** verwendet würde, würde jeder `utm_medium` Wert mit `Suche` darin als Teil dieses Kanals betrachtet werden, was zu falsch zugeordneten Aktionen, Kompensationen und möglicherweise mehr führen kann. **Enthält** wäre hier jedoch keine falsche Wahl; **Genau übereinstimmt** ist nur zufällig die bessere Wahl.
**Beispiel 2: Organische Suche**
Da das Regelziel Verweisende Domain zuvor als beste Wahl festgelegt wurde, könnte eine mögliche Option für die Regel-Logik die folgende sein:
| Regelziel | Regelwert 1 | Regel-Logik | |
| ------------------ | ----------- | ----------- | ------ |
| Verweisende Domain | `--` | Enthält | .bing. |
**Enthält** ist hier eine gute Wahl, da Bing's organische Suche aus mehreren verschiedenen verweisenden URLs stammen kann, wie zum Beispiel:
* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`
Aufgrund der Unterschiede bei den Dritt-Level-Domains (z. B. *www, cn*), den Top-Level-Domains (z. B. *com, net*), und URL-Pfaden kann es sein, dass die Sicherstellung, dass die verweisende Domain die Second-Level-Domain von **.bing.** enthält, dazu führt, dass der gesamte organische Suchverkehr von Bing als Teil dieses Kanals betrachtet werden kann.
Aus diesen Gründen können auch keine präziseren Optionen für die Regel-Logik gewählt werden, da sie verweisende Domains ausschließen würden, die als Teil dieses Kanals betrachtet werden sollten.
**Regex-Optionen für die Regel-Logik**
Aufgrund der Komplexität bei der Implementierung von Regex-Lösungen gibt impact.com keine allgemeinen Ratschläge oder Anleitungen zur Implementierung regulärer Ausdrücke in Optimize. Wenn Sie der Meinung sind, dass Ihre Situation am besten mit einer Regex-Option für die Regel-Logik gelöst wird, wenden Sie sich an Ihren CSM, um zu erfahren, wie Sie damit beginnen.
#### Genau übereinstimmt vs. Beliebige Übereinstimmung
Diese beiden Optionen für die Regel-Logik funktionieren exakt gleich, jedoch mit einem kleinen Unterschied. *Genau übereinstimmt* sucht nur nach dem exakten Regelwert 2, so wie er im RTI geschrieben ist. *Beliebige Übereinstimmung* sucht nach allen Regelwerten 2, so wie sie in der Regel exakt geschrieben sind.
Wenn Sie feststellen, dass Sie **Genau übereinstimmt** mehr als einmal mit dem **AND** Operator verwenden, sollten Sie erwägen, **Beliebige Übereinstimmung**. Gleiches gilt für **Enthält** und **Enthält beliebige**.
#### Gängige Click-IDs
Click-IDs werden im Paid-Media-Bereich immer häufiger verwendet. Nachfolgend finden Sie eine Liste gängiger Click-IDs, die Sie zur Identifizierung von Traffic verwenden können.
| Medienquelle | Click-ID |
| --------------------- | --------- |
| Google Ads | `GCLID` |
| Bing Ads/Yahoo Search | `MSCLKID` |
| Facebook Ads | `FBCLID` |
| Pinterest | `EPIK` |
#### Traffic ausschließen
Manchmal kann das Erstellen von Rules To Identify, die *ausschließen* Traffic ebenso hilfreich sein, um Traffic als Teil eines Kanals zu identifizieren. Sehen Sie sich die folgenden Unterabschnitte an, um zu sehen, wie die oben erstellten Beispiele so eingerichtet werden können, dass sie Traffic ausschließen.
{% tabs %}
{% tab title="Beispiel 1: Bezahlte Suche" %}
Hier ist das oben erstellte Beispiel:
| | | | |
| -------------- | --------------- | ------------------- | --------------- |
| **Regelziel** | **Regelwert 1** | **Regel-Logik** | **Regelwert 2** |
| Zielseiten-URL | `utm_medium` | Genau übereinstimmt | `Suche` |
Diese Regel disqualifiziert bereits viel Traffic. Durch das Hinzufügen einer weiteren Rule To Identify und die Verwendung des **ODER** Operators kann die Regel erweitert werden, um mehr Traffic zu qualifizieren:
| | | | |
| --------------------- | --------------- | ------------------- | --------------- |
| **Regelziel** | **Regelwert 1** | **Regel-Logik** | **Regelwert 2** |
| Zielseiten-URL | `utm_medium` | Genau übereinstimmt | `Suche` |
| **ODER** | | | |
| Landingpage-Parameter | `GCLID` | Ist vorhanden | -- |
Wenn nun eine der beiden Regeln wahr ist, wird der Traffic als Teil dieses Kanals identifiziert.
{% endtab %}
{% tab title="Beispiel 2: Organische Suche" %}
Hier ist das oben erstellte Beispiel:
| Regelziel | Regelwert 1 | Regel-Logik | Regelwert 2 |
| ------------------ | ----------- | ----------- | ----------- |
| Verweisende Domain | `--` | Enthält | .bing. |
Diese Regel identifiziert den gesamten Traffic, der von Bing verwiesen wurde. Durch das Hinzufügen einer weiteren Regel und die Verwendung des **AND** Operators kann die Regel beginnen, von Bing verwiesenen Traffic zu disqualifizieren:
| Regelziel | Regelwert 1 | Regel-Logik | Regelwert 2 |
| --------------------- | ----------- | ------------------- | ----------- |
| Verweisende Domain | `--` | Enthält | .bing. |
| **AND** | | | |
| Landingpage-Parameter | `MSCLIKID` | Ist nicht vorhanden | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
Jetzt müssen beide Regeln wahr sein, damit Traffic als Teil dieses Kanals identifiziert wird.
#### Groß-/Kleinschreibung
Rules To Identify sind nicht groß-/kleinschreibungssensitiv. Wenn Sie beispielsweise einen Parameter haben, bei dem `utm_medium=SEARCH`, können Sie Ihre Regel trotzdem wie folgt einrichten:
| Regelziel | Regelwert 1 | Regel-Logik | Regelwert 2 |
| -------------- | ------------ | ------------------- | ----------- |
| Zielseiten-URL | `utm_medium` | Genau übereinstimmt | `Suche` |
#### Wie geht es weiter?
Sehen Sie sich einige [Optimize-Setup-Szenarien](/brand/de/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md). Hier finden Sie Empfehlungen für gängige Optimize-Szenarien.
---
# 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/de/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.
