> 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)
* [Rule To Identifyとは？](/brand/ja/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [Credit Groupとは？](/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 %}
**ちょっとしたおさらい**
* Rule Target とは、ルール ロジックを適用し、Rule Value（複数）を見つける「場所」です。
* Rule Logic は、ルールがトラフィックを識別しようとする「方法」です。
* Rule Value は、ルールに与える入力で、判定のために活用されます。
#### 精度と信頼性
RTI を設計する際に念頭に置くべき重要な概念は、精度と信頼性です。ルール内の Rule Target と Rule Logic の選択肢は、たとえあるシナリオで複数の組み合わせが機能するとしても、互換的に置き換えられるものと考えるべきではありません。その例については、以下のセクションを参照してください。
Rule Target を選ぶ
Rule Target は精度と信頼性の観点から評価できます。次のチャートは、さまざまな Rule Target を、それぞれの精度と信頼性で示したものです。グラフの原点から遠いほど、Rule Target はより高精度（x 軸）で、より信頼性が高い（y 軸）ことになります。
常に、可能な限り最も信頼性が高く、最も精度の高い Rule Target を使うようにし、ほかに選択肢がない場合にのみグラフの左または下へ移動してください。以下に、どの Rule Target を使うかを選ぶための 2 つの例を示します。
**例 1: 有料検索**
このシナリオでは、すべての有料検索トラフィックに Google の UTM パラメータ `utm_medium=search`が付与されています。したがって、 **ランディングページパラメーター** Rule Target であるべきです。Rule To Identify は次のような形になります：
| ルール対象 | ルール値 1 | ルールロジック | |
|---|
| ランディングページURL | utm_medium | * | * |
を表示する *Rule Logic - 例 1* 何を入力すべきかを確認するには、以下のセクションを参照してください。 *ルールロジック* および *ルール値 2*.
**例 2: オーガニック検索**
次のチャネルであるオーガニック検索には UTM パラメータがなく、ランディングページも予測できません。これらの条件により、パラメータやクエリ文字列を対象とするすべての Rule Target と、すべてのランディングページ Rule Target は除外されます。上のグラフを見ると、これらすべての要因を踏まえた場合の最適な選択肢は、 **参照元ドメイン**です。Rule To Identify は次のような形になります：
| ルール対象 | ルール値 1 | ルールロジック | |
| ------- | ------ | ------- | -- |
| 参照元ドメイン | `--` | \* | \* |
を表示する *Rule Logic - 例 2* 何を入力すべきかを確認するには、以下のセクションを参照してください。 *ルールロジック* および *ルール値 2*.
Rule Logic の選択肢を選ぶ
Rule Logic は精度のみで評価できます。次のチャートは、さまざまな Rule Logic の選択肢を、それぞれの相対的な精度で示したものです。
常に、可能な限り最も精度の高い Rule Logic の選択肢を使うようにし、ほかに選択肢がない場合にのみグラフを下へ移動してください。以下に、どの Rule Logic の選択肢を使うかを選ぶための 2 つの例を示します。
**例 1: 有料検索**
すべての有料検索に Google の UTM パラメータが付与されているため、 `utm_medium=search`、最も適切な Rule Logic の選択肢は **完全一致**.
| ルール対象 | ルール値 1 | ルールロジック | |
| ------------ | ------------ | ------- | -------- |
| ランディングページURL | `utm_medium` | 完全一致 | `search` |
**完全一致** が最も適しています。なぜなら、 `utm_medium=search` という正確なパラメータのキーと値の組み合わせを持つトラフィックだけが、このチャネルの一部と見なされるべきだからです。
たとえば、Rule Logic の選択肢 **含む** を代わりに使用すると、 `utm_medium` を含む任意の値 `search` が含まれるものは、このチャネルの一部と見なされ、誤った帰属のアクションや補填、さらにはそれ以上の問題につながる可能性があります。 **含む** ただし、ここでの選択として間違っているわけではありません。 **完全一致** 単に、こちらのほうがより適切な選択だというだけです。
**例 2: オーガニック検索**
以前に Referring Domain Rule Target が最適な選択であると判断されたため、考えられる Rule Logic の選択肢は次のとおりです：
| ルール対象 | ルール値 1 | ルールロジック | |
| ------- | ------ | ------- | ------ |
| 参照元ドメイン | `--` | 含む | .bing. |
**含む** は、Bing のオーガニック検索が複数の異なる参照 URL に由来し得るため、ここでは適切な選択です。たとえば：
* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`
第3レベルドメイン（例： *www、cn*）、トップレベルドメイン（例： *com、net*）や URL パスがどれほど異なり得るかを考えると、参照ドメインに第2レベルドメインの **.bing.** を含めるだけで、Bing から来るすべてのオーガニック検索トラフィックをこのチャネルの一部として扱えるようになります。
これらの理由から、これ以上精密な Rule Logic の選択肢は選べません。選んでしまうと、このチャネルの一部として扱うべき参照ドメインが除外されてしまうためです。
**正規表現の Rule Logic オプション**
regex ソリューションの実装は複雑なため、impact.com では Optimize で正規表現をどのように実装するかについて一般的な助言や指針は提供していません。regex の Rule Logic オプションが最適だと思われる場合は、導入を始める方法について CSM にご相談ください。
#### 完全一致 vs. いずれかに一致
この 2 つの Rule Logic オプションはまったく同じように機能しますが、わずかな違いがあります。 *完全一致* は、RTI に記載されているとおりの正確な Rule Value 2 のみを検索します。 *いずれかに一致* は、ルールに正確に記載されているすべての Rule Value 2 を検索します。
もし **完全一致** を **AND** 演算子とともに複数回使用しているなら、 **いずれかに一致**の使用を検討してください。同じことは **含む** および **いずれかを含む**.
#### 一般的なクリック ID
クリック ID は、ペイドメディアでますます一般的になっています。以下は、トラフィックを識別するために使用できる一般的なクリック ID の一覧です。
| メディアソース | クリック ID |
| ------------------ | --------- |
| Google 広告 | `GCLID` |
| Bing 広告 / Yahoo 検索 | `MSCLKID` |
| Facebook 広告 | `FBCLID` |
| Pinterest | `EPIK` |
#### トラフィックを除外する
ときには、 *トラフィックを除外する* Rules To Identify を作成することが、チャネルの一部としてトラフィックを識別するのと同じくらい役立つ場合があります。以下の小節では、上で作成した例を使ってトラフィックを除外する方法を示します。
{% tabs %}
{% tab title="例 1: 有料検索" %}
以下が、上で作成した例です：
| | | | |
| ------------ | ------------ | ----------- | ---------- |
| **ルール対象** | **ルール値 1** | **ルールロジック** | **ルール値 2** |
| ランディングページURL | `utm_medium` | 完全一致 | `search` |
このルールは、すでに多くのトラフィックを除外しています。さらに別の Rule To Identify を追加し、 **OR** 演算子を使用すると、ルールはより多くのトラフィックを対象に拡張できます：
| | | | |
| --------------- | ------------ | ----------- | ---------- |
| **ルール対象** | **ルール値 1** | **ルールロジック** | **ルール値 2** |
| ランディングページURL | `utm_medium` | 完全一致 | `search` |
| **OR** | | | |
| ランディングページパラメーター | `GCLID` | が存在する | -- |
これで、どちらか一方のルールが真であれば、そのトラフィックはこのチャネルの一部として識別されます。
{% endtab %}
{% tab title="例 2: オーガニック検索" %}
以下が、上で作成した例です：
| ルール対象 | ルール値 1 | ルールロジック | ルール値 2 |
| ------- | ------ | ------- | ------ |
| 参照元ドメイン | `--` | 含む | .bing. |
このルールは、Bing によって参照されたすべてのトラフィックを識別します。さらに別のルールを追加し、 **AND** 演算子を使用すると、Bing から参照されたトラフィックを除外し始めることができます：
| ルール対象 | ルール値 1 | ルールロジック | ルール値 2 |
| --------------- | ---------- | ------- | ------ |
| 参照元ドメイン | `--` | 含む | .bing. |
| **AND** | | | |
| ランディングページパラメーター | `MSCLIKID` | が存在しない | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
これで、トラフィックがこのチャネルの一部として識別されるには、両方のルールが真である必要があります。
#### 大文字・小文字の区別
Rules To Identify は大文字・小文字を区別しません。たとえば、 `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.