# チャネル設定戦略

{% hint style="warning" %}
**重要**: 次の記事に進む前に、以下のリソースに目を通してください:

* [Optimize スタートアップガイド](/brand/ja/nitsuitebitaidesuka/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [Rule To Identify とは？](/brand/ja/nitsuitebitaidesuka/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [Credit Group とは？](/brand/ja/nitsuitebitaidesuka/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 Logic を適用し、Rule Value(s) を見つけようとする「場所」です。
* Rule Logic とは、ルールがトラフィックを識別しようとする「方法」です。
* Rule Value とは、活用のためにルールへ入力する値です。

#### 精度と信頼性

RTI を設計する際に念頭に置くべき重要な概念は、精度と信頼性です。ルール内の Rule Target と Rule Logic オプションの選択は、たとえあるシナリオで複数の構成要素の組み合わせが機能するとしても、同じものとして扱うべきではありません。以下のセクションで例を示します。

<details>

<summary>Rule Target を選ぶ</summary>

Rule Target は精度と信頼性の観点で評価できます。次の図は、さまざまな Rule Target を、それぞれの精度と信頼性の関係で示しています。Rule Target がグラフの原点から遠いほど、より正確で（x軸方向）、より信頼性が高い（y軸方向）ことを意味します。

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

常に、使える中で最も信頼性が高く、最も正確な Rule Target を使うようにし、他に選択肢がない場合にのみグラフの左または下へ移動してください。以下に、どの Rule Target を使うか選ぶための例を 2 つ示します。

**例1: 有料検索**

このシナリオでは、すべての有料検索トラフィックに Google の UTM パラメータ `utm_medium=search`が付与されています。そのため、 **ランディングページパラメータ** が Rule Target となるべきです。Rule To Identify は次のようになります:

<table><thead><tr><th width="128">ルール対象</th><th>ルール値1</th><th>ルールロジック</th><th></th></tr></thead><tbody><tr><td>ランディングページURL</td><td><code>utm_medium</code></td><td>*</td><td>*</td></tr></tbody></table>

「 *Rule Logic - 例1* で、 *ルールロジック* および *ルール値2*.

**例2: オーガニック検索**

次のチャネルであるオーガニック検索には UTM パラメータがなく、ランディングページも予測できません。これらの条件により、パラメータやクエリ文字列を対象とするすべての Rule Target と、すべてのランディングページの Rule Target が除外されます。上のグラフを見ると、これらの要素を総合的に考慮したときの最適な選択肢は、 **参照元ドメイン**です。Rule To Identify は次のようになります:

| ルール対象   | ルール値1 | ルールロジック |    |
| ------- | ----- | ------- | -- |
| 参照元ドメイン | `--`  | \*      | \* |

「 *Rule Logic - 例2* で、 *ルールロジック* および *ルール値2*.

</details>

<details>

<summary>Rule Logic オプションを選ぶ</summary>

Rule Logic は精度のみを評価できます。次の図は、さまざまな Rule Logic オプションを、それぞれの相対的な精度で示しています。

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

常に、使える中で最も正確な 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 パスが大きく異なり得るため、参照ドメインに単に **.bing.** の第 2 レベルドメインが含まれていることを確認するだけで、Bing から来るすべてのオーガニック検索トラフィックをこのチャネルの一部として扱えるようになります。

</details>

これらの理由から、これ以上精密な Rule Logic オプションは選べません。そうすると、このチャネルの一部と見なされるべき参照ドメインが除外されてしまうからです。

**正規表現の Rule Logic オプション**

正規表現ソリューションの実装は複雑なため、impact.com では Optimize における正規表現の実装方法について一般的な助言や指針は提供していません。正規表現の Rule Logic オプションで対応するのが最適だと思われる場合は、実装を始める方法について CSM に相談してください。

#### 完全一致 と いずれかに一致

この 2 つの Rule Logic オプションはまったく同じように機能しますが、わずかな違いがあります。 *完全一致* は、RTI に記載されている正確な Rule Value 2 だけを検索します。 *いずれかに一致* は、ルールに正確に記載されているすべての Rule Value 2 を検索します。

もし **完全一致** を **および** オペレーターと組み合わせて複数回使っているなら、 **いずれかに一致**の使用を検討してください。同様に、 **含む** および **いずれかを含む**.

#### 一般的なクリック 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`  |

このルールは、すでに多くのトラフィックを除外しています。もう 1 つ Rule To Identify を追加し、 **OR** オペレーターを使うことで、このルールはより多くのトラフィックを許可するように拡張できます:

|                |              |             |           |
| -------------- | ------------ | ----------- | --------- |
| **ルール対象**      | **ルール値1**    | **ルールロジック** | **ルール値2** |
| ランディングページURL   | `utm_medium` | 完全一致        | `search`  |
| **OR**         |              |             |           |
| ランディングページパラメータ | `GCLID`      | 存在する        | --        |

これで、どちらかのルールが true であれば、トラフィックはこのチャネルの一部として識別されます。
{% endtab %}

{% tab title="例2: オーガニック検索" %}
以下が、上で作成した例です:

| ルール対象   | ルール値1 | ルールロジック | ルール値2  |
| ------- | ----- | ------- | ------ |
| 参照元ドメイン | `--`  | 含む      | .bing. |

このルールは、Bing から参照されたすべてのトラフィックを識別します。さらに別のルールを追加し、 **および** オペレーターを使うことで、このルールは Bing から参照されたトラフィックを除外し始めることができます:

| ルール対象          | ルール値1      | ルールロジック | ルール値2  |
| -------------- | ---------- | ------- | ------ |
| 参照元ドメイン        | `--`       | 含む      | .bing. |
| **および**        |            |         |        |
| ランディングページパラメータ | `MSCLIKID` | 存在しない   | --     |
| {% endtab %}   |            |         |        |
| {% endtabs %}  |            |         |        |

これで、トラフィックがこのチャネルの一部として識別されるには、両方のルールが true でなければなりません。

#### 大文字と小文字の区別

Rules To Identify は大文字と小文字を区別しません。たとえば、 `utm_medium=SEARCH`というパラメータがある場合でも、ルールは次のように設定できます:

| ルール対象        | ルール値1        | ルールロジック | ルール値2    |
| ------------ | ------------ | ------- | -------- |
| ランディングページURL | `utm_medium` | 完全一致    | `search` |

#### 次は何をする？

いくつかの [Optimize 設定シナリオ](/brand/ja/nitsuitebitaidesuka/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md)を確認してください。ここでは、一般的な Optimize シナリオに対する推奨事項を見つけることができます。


---

# Agent Instructions: 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:

```
GET https://help.impact.com/brand/ja/nitsuitebitaidesuka/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.