> 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 vor dem Weiterlesen dieses Artikels mit den folgenden Ressourcen vertraut:
* [Startleitfaden für Optimize](/brand/de/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [Was ist eine Regel zur Identifizierung?](/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 Funktionen und Merkmale der Rules To Identify (RTI) von Optimize. Sie erfahren, wie Sie eine Strategie entwickeln, um die Rules To Identify (RTI) für neue Kanäle einzurichten oder vorhandene Kanäle in Ihrem Programm anzupassen.
Es gibt keine Allzwecklö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. Gegenargumente gegen die Einrichtung einer bestimmten RTI können immer existieren, aber **der Zweck eines RTI ist es nicht, 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 nötig ist, um die optimalen Rules To Identify für Ihr Programm zu entwerfen.
{% hint style="info" %}
**Halten Sie die Kanal-Setups fokussiert**: Denken Sie daran, dass es bei Optimize darum geht, Erkenntnisse auf Kanalebene sichtbar zu machen; bei der Erstellung Ihres RTI müssen Sie berücksichtigen, wie der Traffic eines bestimmten Kanals identifiziert wird. Wenn Sie dies berücksichtigen, bleibt Ihr RTI einfach, fokussiert und effektiv.
{% endhint %}
**Eine kurze Erinnerung**
* Ein Rule Target ist das „wo“, an dem die Regel nachschaut, um die Rule Logic anzuwenden und Rule Value(s) zu finden.
* Rule Logic ist das „wie“, mit dem die Regel versucht, Traffic zu identifizieren.
* Rule Values sind Eingaben, die Sie der Regel zur Verwendung bereitstellen.
#### Präzision und Zuverlässigkeit
Bei der Gestaltung Ihres RTI sind die wichtigsten Konzepte Präzision und Zuverlässigkeit. Die Auswahlmöglichkeiten für Rule Target und Rule Logic in einer Regel sollten nicht als austauschbar betrachtet werden, auch wenn mehr als eine Kombination von Komponenten für ein bestimmtes Szenario funktioniert. Beispiele dafür finden Sie in den folgenden Abschnitten.
Wählen Sie ein Rule Target
Rule Targets können nach Präzision und Zuverlässigkeit bewertet werden. Die folgende Grafik stellt die verschiedenen Rule Targets anhand ihrer jeweiligen Präzision und Zuverlässigkeit dar. Je weiter ein Rule Target vom Ursprung des Diagramms entfernt ist, desto präziser (auf der x-Achse) und desto zuverlässiger (auf der y-Achse) ist es.
Sie sollten immer versuchen, das zuverlässigste und präziseste Rule Target zu verwenden, das Ihnen zur Verfügung steht, und sich im Diagramm nur nach links oder unten bewegen, wenn Sie keine andere Option haben. Nachfolgend finden Sie zwei Beispielcases dafür, wie Sie auswählen, welches Rule Target Sie verwenden.
**Beispiel 1: Bezahlte Suche**
In diesem Szenario ist der gesamte Traffic aus bezahlter Suche mit Googles UTM-Parameter getaggt `utm_medium=search`. Aus diesem Grund sollte der **Landing-Page-Parameter** das Rule Target sein. Die Rule To Identify wird dann etwa so aussehen:
| Rule Target | Rule Value 1 | Rule Logic | |
|---|
| Landing-Page-URL | utm_medium | * | * |
Siehe die *Rule Logic – Beispiel 1* Abschnitt, um zu sehen, was Sie für den *Rule Logic* und *Rule Value 2*.
**Beispiel 2: Organische Suche**
Der nächste Kanal, Organische Suche, hat keine UTM-Parameter und die Landingpage ist unvorhersehbar. Diese Bedingungen schließen alle Rule Targets aus, die auf Parameter und Query Strings sowie auf alle Landing-Page-Rule Targets abzielen. Sie können in der Grafik oben sehen, dass unter Berücksichtigung all dieser Faktoren dann die beste Option die **Verweisende Domain**ist. Die Rule To Identify wird dann etwa so aussehen:
| Rule Target | Rule Value 1 | Rule Logic | |
| ------------------ | ------------ | ---------- | -- |
| Verweisende Domain | `--` | \* | \* |
Siehe die *Rule Logic – Beispiel 2* Abschnitt, um zu sehen, was Sie für den *Rule Logic* und *Rule Value 2*.
Wählen Sie eine Rule-Logic-Option
Rule Logic kann nur hinsichtlich der Präzision bewertet werden. Die folgende Grafik stellt die verschiedenen Rule-Logic-Optionen anhand ihrer relativen Präzision dar.
Sie sollten immer versuchen, die präziseste Rule-Logic-Option zu verwenden, die Ihnen zur Verfügung steht, und sich im Diagramm nur nach unten bewegen, wenn Sie keine andere Option haben. Nachfolgend finden Sie zwei Beispielcases dafür, wie Sie auswählen, welche Rule-Logic-Option Sie verwenden.
**Beispiel 1: Bezahlte Suche**
Da die gesamte bezahlte Suche mit Googles UTM-Parameter getaggt ist `utm_medium=search`, wäre die bestmögliche Rule-Logic-Option **Entspricht genau**.
| Rule Target | Rule Value 1 | Rule Logic | |
| ---------------- | ------------ | ---------------- | -------- |
| Landing-Page-URL | `utm_medium` | Entspricht genau | `search` |
**Entspricht genau** funktioniert hier am besten, da nur Traffic mit dem genauen Schlüssel-Wert-Paar des Parameters `utm_medium=search` als Teil dieses Kanals betrachtet werden sollte.
Wenn beispielsweise die Rule-Logic-Option **Enthält** verwendet würde, würde jeder `utm_medium` Wert mit `search` 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; **Entspricht genau** sie ist lediglich die bessere Wahl.
**Beispiel 2: Organische Suche**
Da das Rule Target Verweisende Domain bereits zuvor als beste Wahl festgelegt wurde, könnte eine potenzielle Rule-Logic-Option wie folgt aussehen:
| Rule Target | Rule Value 1 | Rule Logic | |
| ------------------ | ------------ | ---------- | ------ |
| Verweisende Domain | `--` | Enthält | .bing. |
**Enthält** ist hier eine gute Wahl, da die organische Suche von Bing 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 Domains der dritten Ebene (z. B. *www, cn*), Top-Level-Domains (z. B. *com, net*), und URL-Pfaden kann es ausreichen, einfach sicherzustellen, dass die verweisende Domain die Second-Level-Domain von **.bing.** enthält, damit der gesamte organische Suchtraffic von Bing als Teil dieses Kanals betrachtet wird.
Aus diesen Gründen können auch keine präziseren Rule-Logic-Optionen gewählt werden, da sie verweisende Domains ausschließen würden, die als Teil dieses Kanals betrachtet werden sollten.
**Regex Rule-Logic-Optionen**
Aufgrund der Komplexität bei der Implementierung von Regex-Lösungen gibt impact.com keine allgemeine Empfehlung oder Anleitung dazu, wie reguläre Ausdrücke in Optimize implementiert werden sollten. Wenn Sie der Meinung sind, dass Ihre Situation am besten mit einer Regex-Rule-Logic-Option gelöst wird, wenden Sie sich an Ihren CSM, um zu erfahren, wie Sie mit der Implementierung beginnen.
#### Entspricht genau vs. Entspricht einem beliebigen
Diese beiden Rule-Logic-Optionen funktionieren genau gleich, jedoch mit einem kleinen Unterschied. *Entspricht genau* sucht nur nach dem genauen Rule Value 2, so wie er im RTI geschrieben steht. *Entspricht einem beliebigen* sucht nach allen Rule Value 2, so wie sie in der Regel genau geschrieben sind.
Wenn Sie feststellen, dass Sie **Entspricht genau** mehr als einmal mit dem **UND** Operator verwenden, sollten Sie erwägen, **Entspricht einem beliebigen**. Dasselbe gilt für **Enthält** und **Enthält beliebige**.
#### Gängige Click-IDs
Click-IDs werden bei Paid Media immer häufiger. Nachfolgend finden Sie eine Liste gängiger Click-IDs, mit denen Sie Traffic identifizieren können.
| Medienquelle | Klick-ID |
| -------------------- | --------- |
| Google Ads | `GCLID` |
| Bing Ads/Yahoo Suche | `MSCLKID` |
| Facebook Ads | `FBCLID` |
| Pinterest | `EPIK` |
#### Traffic disqualifizieren
Manchmal kann das Erstellen von Rules To Identify, die *disqualifizieren* Traffic ausschließen, ebenso hilfreich sein, um Traffic als Teil eines Kanals zu identifizieren. In den folgenden Unterabschnitten sehen Sie, wie die oben erstellten Beispiele so eingerichtet werden können, dass sie Traffic disqualifizieren.
{% tabs %}
{% tab title="Beispiel 1: Bezahlte Suche" %}
Hier ist das oben erstellte Beispiel:
| | | | |
| ---------------- | ---------------- | ---------------- | ---------------- |
| **Rule Target** | **Rule Value 1** | **Rule Logic** | **Rule Value 2** |
| Landing-Page-URL | `utm_medium` | Entspricht genau | `search` |
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:
| | | | |
| ---------------------- | ---------------- | ---------------- | ---------------- |
| **Rule Target** | **Rule Value 1** | **Rule Logic** | **Rule Value 2** |
| Landing-Page-URL | `utm_medium` | Entspricht genau | `search` |
| **ODER** | | | |
| Landing-Page-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:
| Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
| ------------------ | ------------ | ---------- | ------------ |
| Verweisende Domain | `--` | Enthält | .bing. |
Diese Regel identifiziert den gesamten Traffic, der über Bing verwiesen wurde. Durch das Hinzufügen einer weiteren Regel und die Verwendung des **UND** Operators kann die Regel damit beginnen, Traffic zu disqualifizieren, der über Bing verwiesen wurde:
| Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
| ---------------------- | ------------ | ------------------- | ------------ |
| Verweisende Domain | `--` | Enthält | .bing. |
| **UND** | | | |
| Landing-Page-Parameter | `MSCLIKID` | Ist nicht vorhanden | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
Nun müssen beide Regeln wahr sein, damit Traffic als Teil dieses Kanals identifiziert wird.
#### Groß-/Kleinschreibung
Rules To Identify sind nicht case-sensitiv. Wenn Sie beispielsweise einen Parameter haben, bei dem `utm_medium=SEARCH`, können Sie Ihre Regel trotzdem so einrichten:
| Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
| ---------------- | ------------ | ---------------- | ------------ |
| Landing-Page-URL | `utm_medium` | Entspricht genau | `search` |
#### 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 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/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 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.
