> 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/ja/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md).
# チャネル設定戦略
{% hint style="warning" %}
**重要**: 次のリソースに目を通してから、この記事に進んでください:
* [Optimizeスタートガイド](/brand/ja/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [識別ルールとは？](/brand/ja/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [クレジットグループとは？](/brand/ja/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
{% endhint %}
この記事では、Optimize の Rules To Identify（RTI）の機能と用途について説明します。新しいチャネルに Rules To Identify（RTI）を設定するための戦略を立てる方法、またはプログラム内の既存チャネルを変更する方法を学びます。
すべての状況に適合する万能の解決策はありません。ただし、自分の独自の状況に最も適した解決策にたどり着くことはできるはずです。ある RTI の設定に対する反論は常にあり得ますが、 **RTI の目的は、あらゆる状況で機能することではありません**. **RTI は、特定の状況に最も適するように調整することを意図しています**.
このドキュメントでは、プログラムに最適な Rules To Identify を設計するために必要な基礎知識と機能的知識を深めます。
{% hint style="info" %}
**チャネル設定は重点を絞る**: Optimize はチャネルレベルのインサイトを可視化することに重点を置いていることを忘れないでください。RTI を作成する際は、特定のチャネルから来るトラフィックをどう識別するかを考慮しなければなりません。この点を意識することで、RTI をシンプルで焦点が定まり、効果的なものに保てます。
{% endhint %}
**簡単な注意点**
* ルール対象とは、ルールロジックを適用し、ルール値を見つける「場所」のことです。
* ルールロジックとは、ルールがトラフィックを識別しようとする「方法」のことです。
* ルール値とは、ルールに入力して活用する値のことです。
#### 精度と信頼性
RTI を設計する際に念頭に置くべき重要な概念は、精度と信頼性です。ルール内のルール対象とルールロジックの選択肢は、たとえ特定のシナリオで複数の組み合わせが機能するとしても、相互に置き換え可能だと考えるべきではありません。以下のセクションでその例を示します。
ルール対象を選ぶ
ルール対象は、精度と信頼性の観点で評価できます。次のチャートは、各ルール対象をそれぞれの精度と信頼性の観点で示しています。ルール対象がグラフの原点から遠いほど、そのルール対象はより正確（x軸方向）で、より信頼性が高い（y軸方向）ことを意味します。
常に、使える中で最も信頼性が高く、最も正確なルール対象を使うようにし、他に選択肢がない場合にのみ、グラフの左または下に移動してください。以下は、どのルール対象を使うかを選ぶ2つの例です。
**例1: 有料検索**
このシナリオでは、すべての有料検索トラフィックに Google の UTM パラメータが付与されています `utm_medium=search`。そのため、 **ランディングページパラメータ** がルール対象であるべきです。識別ルールは次のようになります:
| ルール対象 | ルール値1 | ルールロジック | |
|---|
| ランディングページ URL | utm_medium | * | * |
次を表示 *ルールロジック - 例1* のセクションを見て、 *ルールロジック* 、 *ルール値2*.
**例2: オーガニック検索**
次のチャネルであるオーガニック検索には UTM パラメータがなく、ランディングページも予測できません。これらの条件により、パラメータやクエリ文字列を対象とするすべてのルール対象、およびランディングページを対象とするすべてのルール対象が除外されます。上のグラフを見ると、これらすべての要因を考慮した場合の最適な選択肢は **参照元ドメイン**です。識別ルールは次のようになります:
| ルール対象 | ルール値1 | ルールロジック | |
| ------- | ----- | ------- | -- |
| 参照元ドメイン | `--` | \* | \* |
次を表示 *ルールロジック - 例2* のセクションを見て、 *ルールロジック* 、 *ルール値2*.
ルールロジックのオプションを選ぶ
ルールロジックは精度についてのみ評価できます。次のチャートは、各ルールロジックのオプションを相対的な精度の観点で示しています。
常に、使える中で最も正確なルールロジックを使うようにし、他に選択肢がない場合にのみ、グラフの下方向に移動してください。以下は、どのルールロジックを使うかを選ぶ2つの例です。
**例1: 有料検索**
すべての有料検索に Google の UTM パラメータが付与されているため `utm_medium=search`、最適なルールロジックのオプションは **完全一致**.
| ルール対象 | ルール値1 | ルールロジック | |
| ------------- | ------------ | ------- | -------- |
| ランディングページ URL | `utm_medium` | 完全一致 | `search` |
**完全一致** が最適です。これは、 `utm_medium=search` という正確なパラメータのキーと値の組み合わせを持つトラフィックだけが、このチャネルの一部として扱われるべきだからです。
たとえば、ルールロジックのオプション **含む** を代わりに使うと、 `utm_medium` を含む `search` すべての値がこのチャネルの一部と見なされ、誤ったアトリビューション、メイクグッド、さらにはその他の問題につながる可能性があります。 **含む** とはいえ、ここでの選択として間違いというわけではありません。 **完全一致** 単に、より良い選択肢だというだけです。
**例2: オーガニック検索**
先に参照ドメインのルール対象が最良の選択であると判断されたため、ルールロジックの候補としては次のようなものが考えられます:
| ルール対象 | ルール値1 | ルールロジック | |
| ------- | ----- | ------- | ------ |
| 参照元ドメイン | `--` | 含む | .bing. |
**含む** がここで適しているのは、Bing のオーガニック検索が次のような複数の参照 URL から生じる可能性があるためです:
* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`
第3レベルドメイン（例: *www, cn*）やトップレベルドメイン（例: *com, net*）、および URL パスがどれほど異なり得るかを考えると、参照ドメインに **.bing.** の第2レベルドメインが含まれていることを確認するだけで、Bing から来るすべてのオーガニック検索トラフィックをこのチャネルの一部として扱えるようになります。
これらの理由から、これ以上精度の高いルールロジックの選択肢は使えません。そうした選択肢では、このチャネルの一部と見なすべき参照ドメインを除外してしまうからです。
**正規表現のルールロジックのオプション**
正規表現ソリューションの実装は複雑であるため、impact.com は Optimize における正規表現の実装方法について一般的な助言や指針を提供していません。正規表現のルールロジックのオプションで対処するのが最適だと思われる場合は、実装を始める方法について CSM に相談してください。
#### 完全一致 vs. いずれかに一致
この2つのルールロジックのオプションは、細かな違いを除けばまったく同じように機能します。 *完全一致* RTI に記載されたとおりの正確なルール値2のみを検索します。 *いずれかに一致* ルール内に記載されたとおりのすべてのルール値2を検索します。
もし **完全一致** を **および** 演算子とともに複数回使っているなら、 **いずれかに一致**の使用を検討してください。 **含む** 、 **いずれかを含む**.
#### 一般的なクリック ID
クリック ID は、有料メディアでますます一般的になっています。以下は、トラフィックの識別に使用できる一般的なクリック ID の一覧です。
| メディアソース | クリック ID |
| ---------------- | --------- |
| Google 広告 | `GCLID` |
| Bing 広告/Yahoo 検索 | `MSCLKID` |
| Facebook 広告 | `FBCLID` |
| Pinterest | `EPIK` |
#### トラフィックの除外
場合によっては、トラフィックを *除外する* 識別ルールを作成することが、チャネルの一部としてトラフィックを識別するのと同じくらい役立つことがあります。上の例を使って、トラフィックを除外するようにどのように設定できるかは、以下のサブセクションを参照してください。
{% tabs %}
{% tab title="例1: 有料検索" %}
以下は、上で作成した例です:
| | | | |
| ------------- | ------------ | ----------- | --------- |
| **ルール対象** | **ルール値1** | **ルールロジック** | **ルール値2** |
| ランディングページ URL | `utm_medium` | 完全一致 | `search` |
このルールは、すでに多くのトラフィックを除外しています。さらに別の識別ルールを追加し、 **または** 演算子を使うことで、このルールでより多くのトラフィックを対象にできます:
| | | | |
| -------------- | ------------ | ----------- | --------- |
| **ルール対象** | **ルール値1** | **ルールロジック** | **ルール値2** |
| ランディングページ URL | `utm_medium` | 完全一致 | `search` |
| **または** | | | |
| ランディングページパラメータ | `GCLID` | 存在する | -- |
これで、どちらかのルールが true であれば、そのトラフィックはこのチャネルの一部として識別されます。
{% endtab %}
{% tab title="例2: オーガニック検索" %}
以下は、上で作成した例です:
| ルール対象 | ルール値1 | ルールロジック | ルール値2 |
| ------- | ----- | ------- | ------ |
| 参照元ドメイン | `--` | 含む | .bing. |
このルールは、Bing によって参照されたすべてのトラフィックを識別します。さらに別のルールを追加し、 **および** 演算子を使うことで、Bing によって参照されたトラフィックの除外を開始できます:
| ルール対象 | ルール値1 | ルールロジック | ルール値2 |
| -------------- | ---------- | ------- | ------ |
| 参照元ドメイン | `--` | 含む | .bing. |
| **および** | | | |
| ランディングページパラメータ | `MSCLIKID` | 存在しない | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
これで、トラフィックがこのチャネルの一部として識別されるには、両方のルールが true でなければなりません。
#### 大文字・小文字の区別
識別ルールは大文字・小文字を区別しません。たとえば、 `utm_medium=SEARCH`というパラメータがある場合でも、ルールを次のように設定できます:
| ルール対象 | ルール値1 | ルールロジック | ルール値2 |
| ------------- | ------------ | ------- | -------- |
| ランディングページ URL | `utm_medium` | 完全一致 | `search` |
#### 次は？
いくつかの [Optimize の設定シナリオを確認してください](/brand/ja/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md)。ここでは、一般的な 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/ja/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.