> 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 in diesem Artikel mit den folgenden Ressourcen vertraut:

* [Optimize-Startup-Leitfaden](/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 Aufgaben 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 bestehende Kanäle in Ihrem Programm zu ändern.

Es gibt keine universelle Lösung, die in allen Fällen 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 bestehen, aber **der Zweck einer RTI besteht nicht darin, unter allen Umständen zu funktionieren**. **Eine RTI soll so angepasst werden, dass sie optimal zu Ihren spezifischen Umständen passt**.

Dieses Dokument vermittelt die grundlegenden und funktionalen Kenntnisse, die erforderlich sind, um die optimale Rules To Identify für Ihr Programm zu entwerfen.

{% hint style="info" %}
**Kanaleinrichtungen fokussiert halten**: Denken Sie daran, dass es bei Optimize darum geht, Erkenntnisse auf Kanalebene sichtbar zu machen; bei der Erstellung Ihrer RTI müssen Sie berücksichtigen, wie der aus einem bestimmten Kanal kommende Traffic identifiziert werden kann. Wenn Sie dies im Blick behalten, hilft Ihnen das, Ihre RTI einfach, fokussiert und wirksam zu halten.
{% endhint %}

**Eine kurze Erinnerung**

* Ein Rule Target ist das „Wo“, an dem die Regel nach der Rule Logic und den Rule Value(s) sucht.
* Rule Logic ist das „Wie“, mit dem die Regel versucht, Traffic zu identifizieren.
* Rule Values sind Eingaben, die Sie der Regel zur Nutzung bereitstellen.

#### Präzision und Zuverlässigkeit

Beim Entwerfen Ihrer RTI sind die wichtigsten Konzepte Präzision und Zuverlässigkeit. Die Auswahloptionen für Rule Target und Rule Logic innerhalb einer Regel sollten nicht als austauschbar betrachtet werden, auch wenn für ein bestimmtes Szenario mehr als eine Kombination von Komponenten funktioniert. Beispiele dazu finden Sie in den folgenden Abschnitten.

<details>

<summary>Wählen Sie ein Rule Target</summary>

Rule Targets können nach Präzision und Zuverlässigkeit bewertet werden. Das folgende Diagramm ordnet die verschiedenen Rule Targets in Bezug auf ihre jeweilige Präzision und Zuverlässigkeit ein. Je weiter ein Rule Target vom Ursprung des Diagramms entfernt ist, desto präziser (entlang der x-Achse) und desto zuverlässiger (entlang der y-Achse) ist es.

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

Sie sollten immer versuchen, das zuverlässigste und präziseste Rule Target zu verwenden, das Ihnen zur Verfügung steht, und nur dann im Diagramm nach links oder unten ausweichen, wenn Sie keine andere Option haben. Im Folgenden finden Sie zwei Beispiel-Fälle dafür, wie Sie auswählen können, welches Rule Target 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`. Deshalb sollte das **Landingpage-Parameter** das Rule Target sein. Die Rule To Identify wird dann ungefähr so aussehen:

<table><thead><tr><th width="128">Regelziel</th><th>Regelwert 1</th><th>Regellogik</th><th></th></tr></thead><tbody><tr><td>Landingpage-URL</td><td><code>utm_medium</code></td><td>*</td><td>*</td></tr></tbody></table>

Siehe die *Rule Logic – Beispiel 1* Abschnitt, um zu sehen, was Sie für das *Regellogik* und *Regelwert 2*.

**Beispiel 2: Organische Suche**

Der nächste Kanal, Organische Suche, wird keine UTM-Parameter haben und die Landingpage ist unvorhersehbar. Diese Bedingungen schließen alle Rule Targets aus, die auf Parametern und Query Strings basieren, sowie alle Landingpage-Rule Targets. Sie können im obigen Diagramm sehen, dass die beste Option unter all diesen Faktoren dann die **Verweisende Domain**. Die Rule To Identify wird dann ungefähr so aussehen:

| Regelziel          | Regelwert 1 | Regellogik |    |
| ------------------ | ----------- | ---------- | -- |
| Verweisende Domain | `--`        | \*         | \* |

Siehe die *Rule Logic – Beispiel 2* Abschnitt, um zu sehen, was Sie für das *Regellogik* und *Regelwert 2*.

</details>

<details>

<summary>Wählen Sie eine Rule-Logic-Option</summary>

Rule Logic kann nur nach Präzision bewertet werden. Das folgende Diagramm ordnet die verschiedenen Rule-Logic-Optionen in Bezug auf ihre relative Präzision ein.

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

Sie sollten immer versuchen, die präziseste Rule-Logic-Option zu verwenden, die Ihnen zur Verfügung steht, und im Diagramm nur dann nach unten gehen, wenn Sie keine andere Wahl haben. Im Folgenden finden Sie zwei Beispiel-Fälle dafür, wie Sie auswählen können, welche Rule-Logic-Option 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 Rule-Logic-Option **Stimmt exakt überein**.

| Regelziel       | Regelwert 1  | Regellogik           |         |
| --------------- | ------------ | -------------------- | ------- |
| Landingpage-URL | `utm_medium` | Stimmt exakt überein | `Suche` |

**Stimmt exakt überein** ist hier am besten geeignet, weil nur Traffic mit genau dem Parameter-Key-Value-Paar von `utm_medium=search` als Teil dieses Kanals betrachtet werden sollte.

Wenn beispielsweise stattdessen die Rule-Logic-Option **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, Kulanzleistungen und möglicherweise mehr führen kann. **Enthält** wäre hier allerdings keine falsche Wahl; **Stimmt exakt überein** ist einfach die bessere Wahl.

**Beispiel 2: Organische Suche**

Nachdem der Rule Target „Referring Domain“ bereits als beste Wahl festgelegt wurde, könnte eine mögliche Rule-Logic-Option die folgende sein:

| Regelziel          | Regelwert 1 | Regellogik |        |
| ------------------ | ----------- | ---------- | ------ |
| Verweisende Domain | `--`        | Enthält    | .bing. |

**Enthält** ist hier eine gute Wahl, weil die organische Suche von Bing aus mehreren unterschiedlichen 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 Domainen der dritten Ebene (z. B. *www, cn*), Top-Level-Domains (z. B. *com, net*) und URL-Pfaden reicht es aus, 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 werden kann.

</details>

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 allgemeinen Ratschläge oder Anleitungen dazu, wie reguläre Ausdrücke in Optimize implementiert werden. Wenn Sie glauben, dass Ihre Situation am besten mit einer Regex-Rule-Logic-Option gelöst wird, sprechen Sie mit Ihrem CSM darüber, wie Sie mit der Implementierung beginnen können.

#### Genau übereinstimmend vs. trifft auf beliebige zu

Diese beiden Rule-Logic-Optionen funktionieren exakt gleich, mit einem kleinen Unterschied. *Stimmt exakt überein* wird nur nach dem exakten Rule Value 2 suchen, wie er in der RTI geschrieben ist. *Entspricht irgendeinem* wird nach allen Rule Value 2 suchen, so wie sie exakt in der Regel geschrieben sind.

Wenn Sie feststellen, dass Sie **Stimmt exakt überein** mehr als einmal mit dem **UND** Operator verwenden, sollten Sie **Entspricht irgendeinem**in Betracht ziehen. Dasselbe gilt für **Enthält** und **Enthält irgendeines**.

#### Gängige Click-IDs

Click-IDs werden für Paid Media zunehmend üblich. Im Folgenden finden Sie eine Liste gängiger Click-IDs, die Sie zur Identifizierung von Traffic verwenden können.

| Medienquelle          | Klick-ID  |
| --------------------- | --------- |
| Google Ads            | `GCLID`   |
| Bing Ads/Yahoo Search | `MSCLKID` |
| Facebook Ads          | `FBCLID`  |
| Pinterest             | `EPIK`    |

#### Traffic disqualifizieren

Manchmal ist das Erstellen von Rules To Identify, die *disqualifizieren* von Traffic ebenso hilfreich, 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:

|                 |                 |                      |                 |
| --------------- | --------------- | -------------------- | --------------- |
| **Regelziel**   | **Regelwert 1** | **Regellogik**       | **Regelwert 2** |
| Landingpage-URL | `utm_medium`    | Stimmt exakt überein | `Suche`         |

Diese Regel disqualifiziert bereits viel Traffic. Wenn Sie eine weitere Rule To Identify hinzufügen und den **ODER** Operator verwenden, kann die Regel erweitert werden, um mehr Traffic zu qualifizieren:

|                       |                 |                      |                 |
| --------------------- | --------------- | -------------------- | --------------- |
| **Regelziel**         | **Regelwert 1** | **Regellogik**       | **Regelwert 2** |
| Landingpage-URL       | `utm_medium`    | Stimmt exakt überein | `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 | Regellogik | Regelwert 2 |
| ------------------ | ----------- | ---------- | ----------- |
| Verweisende Domain | `--`        | Enthält    | .bing.      |

Diese Regel identifiziert den gesamten Traffic, der über Bing verwiesen wurde. Wenn Sie eine weitere Regel hinzufügen und den **UND** Operator verwenden, kann die Regel beginnen, über Bing verwiesenen Traffic zu disqualifizieren:

| Regelziel             | Regelwert 1 | Regellogik          | Regelwert 2 |
| --------------------- | ----------- | ------------------- | ----------- |
| Verweisende Domain    | `--`        | Enthält             | .bing.      |
| **UND**               |             |                     |             |
| Landingpage-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 groß-/kleinschreibungssensitiv. Wenn Sie beispielsweise einen Parameter haben, bei dem `utm_medium=SEARCH`, können Sie Ihre Regel dennoch so einrichten:

| Regelziel       | Regelwert 1  | Regellogik           | Regelwert 2 |
| --------------- | ------------ | -------------------- | ----------- |
| Landingpage-URL | `utm_medium` | Stimmt exakt überein | `Suche`     |

#### Wie geht es weiter?

Sehen Sie sich einige [Optimize-Einrichtungsszenarien](/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=<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.