> 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 zur Kanaleinrichtung

{% hint style="warning" %}
**Wichtig**: Machen Sie sich mit den folgenden Ressourcen vertraut, bevor Sie mit diesem Artikel fortfahren:

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

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. Gegen die Einrichtung einer bestimmten RTI können immer Argumente vorgebracht werden, aber **der Zweck einer RTI besteht nicht darin, unter allen Umständen zu funktionieren**. **Eine RTI soll so angepasst werden, dass sie am besten zu Ihren spezifischen Umständen passt**.

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

{% hint style="info" %}
**Halten Sie die Kanaleinrichtungen fokussiert**: 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 Traffic eines bestimmten Kanals identifiziert werden kann. Wenn Sie dies im Hinterkopf behalten, bleibt Ihre RTI einfach, fokussiert und effektiv.
{% endhint %}

**Eine kurze Erinnerung**

* Ein Rule Target ist das „wo“, nach dem die Regel sucht, 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 Verfügung stellen.

#### Präzision und Zuverlässigkeit

Bei der Gestaltung Ihrer RTI sind Präzision und Zuverlässigkeit zentrale Konzepte, die Sie im Auge behalten sollten. Die Auswahlmöglichkeiten für die Rule Target- und Rule Logic-Option in einer Regel sollten nicht als austauschbar betrachtet werden, auch wenn mehr als ein Satz von Komponenten für ein bestimmtes Szenario funktioniert. In den folgenden Abschnitten finden Sie Beispiele dazu.

<details>

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

Rule Targets können im Hinblick auf Präzision und Zuverlässigkeit bewertet werden. Die folgende Grafik zeigt die verschiedenen Rule Targets in Bezug auf ihre jeweilige Präzision und Zuverlässigkeit. 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 sich nur nach links oder unten im Diagramm bewegen, wenn Sie keine andere Wahl haben. Unten finden Sie zwei Beispielcases dafür, wie Sie auswählen, 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 versehen `utm_medium=search`. Daher sollte das **Landingpage-Parameter** das Rule Target sein. Die Rule To Identify wird dann folgendermaßen aussehen:

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

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

**Beispiel 2: Organische Suche**

Der nächste Kanal, die organische Suche, wird keine UTM-Parameter haben und die Zielseite ist unvorhersehbar. Diese Bedingungen schließen alle Rule Targets aus, die Parameter und Query Strings sowie alle Landing-Page-Rule Targets anvisieren. Sie können in der obigen Grafik sehen, dass die beste Option unter Berücksichtigung all dieser Faktoren dann das **Verweis-Domain**. Die Rule To Identify wird dann folgendermaßen aussehen:

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

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

</details>

<details>

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

Rule Logic kann nur hinsichtlich der Präzision bewertet werden. Die folgende Grafik zeigt die verschiedenen Rule Logic-Optionen im Hinblick auf ihre relative Präzision.

<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 sich nur nach unten im Diagramm bewegen, wenn Sie keine andere Wahl haben. Unten finden Sie zwei Beispielcases dafür, wie Sie auswählen, welche Rule Logic-Option verwendet werden soll.

**Beispiel 1: Bezahlte Suche**

Da der gesamte Traffic aus bezahlter Suche mit dem UTM-Parameter von Google versehen ist `utm_medium=search`, wäre die bestmögliche Rule Logic-Option **Stimmt genau überein**.

| Regelziel        | Regelwert 1  | Regellogik           |         |
| ---------------- | ------------ | -------------------- | ------- |
| Landing-Page-URL | `utm_medium` | Stimmt genau überein | `Suche` |

**Stimmt genau überein** 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 Rule Logic-Option **Enthält** stattdessen 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; **Stimmt genau überein** es ist lediglich die bessere Wahl.

**Beispiel 2: Organische Suche**

Da das Referring-Domain-Rule-Target zuvor als die beste Wahl festgelegt wurde, könnte eine mögliche Rule Logic-Option wie folgt aussehen:

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

**Enthält** ist hier eine gute Wahl, da Bings organischer Suchtraffic von 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 Subdomains auf dritter Ebene (z. B. *www, cn*), Top-Level-Domains (z. B. *com, net*), und URL-Pfaden genügt es, einfach sicherzustellen, dass die verweisende Domain die Domain zweiter Ebene 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 Anweisungen zur Umsetzung regulärer Ausdrücke in Optimize. Wenn Sie glauben, dass Ihre Umstände am besten mit einer Regex-Rule-Logic-Option gehandhabt werden, wenden Sie sich an Ihren CSM, um zu erfahren, wie Sie mit der Implementierung beginnen.

#### Exakt übereinstimmen vs. Beliebig übereinstimmen

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

Wenn Sie feststellen, dass Sie **Stimmt genau überein** mehr als einmal mit dem **UND** Operator verwenden, sollten Sie **Entspricht einem der**. Das Gleiche gilt für **Enthält** und **Enthält einen der folgenden**.

#### Gängige Klick-IDs

Click-IDs werden in bezahlten Medien immer häufiger verwendet. Im Folgenden finden Sie eine Liste gängiger Click-IDs, mit denen Sie Traffic identifizieren können.

| Medienquelle         | Click-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 kann ebenso hilfreich sein, um Traffic als Teil eines Kanals zu identifizieren. In den folgenden Unterabschnitten erfahren 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** |
| Landing-Page-URL | `utm_medium`    | Stimmt genau überein | `Suche`         |

Diese Regel disqualifiziert bereits viel Traffic. Durch Hinzufügen einer weiteren Rule To Identify und Verwendung des **ODER** Operators kann die Regel erweitert werden, um mehr Traffic zu qualifizieren:

|                       |                 |                      |                 |
| --------------------- | --------------- | -------------------- | --------------- |
| **Regelziel**         | **Regelwert 1** | **Regellogik**       | **Regelwert 2** |
| Landing-Page-URL      | `utm_medium`    | Stimmt genau überein | `Suche`         |
| **ODER**              |                 |                      |                 |
| Landingpage-Parameter | `GCLID`         | Ist vorhanden        | --              |

Jetzt wird der Traffic als Teil dieses Kanals identifiziert, wenn eine der beiden Regeln wahr ist.
{% endtab %}

{% tab title="Beispiel 2: Organische Suche" %}
Hier ist das oben erstellte Beispiel:

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

Diese Regel identifiziert den gesamten Traffic, der von Bing verwiesen wurde. Durch Hinzufügen einer weiteren Regel und Verwendung des **UND** Operators kann die Regel beginnen, von Bing verwiesenen Traffic zu disqualifizieren:

| Regelziel             | Regelwert 1 | Regellogik          | Regelwert 2 |
| --------------------- | ----------- | ------------------- | ----------- |
| Verweis-Domain        | `--`        | Enthält             | .bing.      |
| **UND**               |             |                     |             |
| Landingpage-Parameter | `MSCLIKID`  | Ist nicht vorhanden | --          |
| {% endtab %}          |             |                     |             |
| {% endtabs %}         |             |                     |             |

Jetzt müssen beide Regeln wahr sein, damit Traffic als Teil dieses Kanals identifiziert wird.

#### Groß- und Kleinschreibung

Rules To Identify sind nicht groß- und kleinschreibungssensitiv. Wenn Sie beispielsweise einen Parameter haben, bei dem `utm_medium=SEARCH`, können Sie Ihre Regel dennoch wie folgt einrichten:

| Regelziel        | Regelwert 1  | Regellogik           | Regelwert 2 |
| ---------------- | ------------ | -------------------- | ----------- |
| Landing-Page-URL | `utm_medium` | Stimmt genau ü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 häufige 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.