# チャネル設定戦略

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

* [Optimize スタートガイド](https://help.impact.com/brand/ja/nitsuitebitaidesuka/platform-features/cross-channel-performance-insights/optimize-startup-guide)
* [識別ルールとは何ですか？](https://help.impact.com/brand/ja/nitsuitebitaidesuka/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic)
* [クレジットグループとは何ですか？](https://help.impact.com/brand/ja/nitsuitebitaidesuka/platform-features/actions-and-payouts/credit-groups-explained)
  {% endhint %}

この記事では、Optimize の識別ルール（Rules To Identify、RTI）の機能と役割について説明します。新しいチャネルの RTI を設定する方法や、既存のチャネルをプログラム内で変更する方法についての戦略を学びます。

すべての状況に当てはまる万能の解決策はありません。しかし、あなたの固有の状況に最も適した解決策に到達できるはずです。ある RTI の設定に反対する意見は常に存在し得ますが、 **RTI の目的はすべての状況で機能させることではありません**. **RTI はあなたの特定の状況に最適に合わせるために形成されるべきものです**.

このドキュメントは、あなたのプログラムに最適な識別ルールを設計するために必要な基礎的かつ機能的な知識を進めます。

{% hint style="info" %}
**チャネル設定は焦点を絞ること**：Optimize はチャネルレベルの洞察を浮き彫りにすることが目的であることを忘れないでください。RTI を作成する際には、特定のチャネルから来るトラフィックをどのように識別するかを考慮する必要があります。これを念頭に置くことで、RTI をシンプルかつ焦点を絞った効果的なものに保てます。
{% endhint %}

**簡単なリマインダー**

* ルールターゲットは、ルールがルールロジックを適用してルール値を見つけようとする「場所」です。
* ルールロジックは、ルールがトラフィックを識別しようとする「方法」です。
* ルール値は、ルールに対してあなたが提供する入力です。

#### 精度と信頼性

RTI を設計する際に念頭に置くべき重要な概念は、精度と信頼性です。ルール内でのルールターゲットやルールロジックの選択は、与えられたシナリオで複数の組み合わせが機能する場合でも、互換的に扱うべきではありません。以下のセクションでその例を示します。

<details>

<summary>ルールターゲットを選ぶ</summary>

ルールターゲットは精度と信頼性で評価できます。次の図は、さまざまなルールターゲットをそれぞれの精度と信頼性に応じてプロットしたものです。グラフの原点から離れるほど、そのルールターゲットはより精度（x 軸）も高く、より信頼性（y 軸）も高くなります。

<div data-with-frame="true"><figure><img src="https://1458456015-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwMLlMoFBtKJa8ptd3zaw%2Fuploads%2Fgit-blob-489f6f57993cbcf93749f93b54b796fd3f2f0095%2Fc19fe1a665f9b3e512fe5afb73ca76dfe2ae37fcda9f0873ae316bebaf1fb02c.png?alt=media" alt=""><figcaption></figcaption></figure></div>

可能な限り最も信頼性が高く精度の高いルールターゲットを使用し、他に選択肢がない場合にのみグラフの左または下に移動してください。以下は、どのルールターゲットを使用するかを選択するための 2 つの例です。

**例 1: 有料検索（Paid Search）**

このシナリオでは、すべての有料検索トラフィックに Google の UTM パラメータが付与されています `utm_medium=search`。このため、 **ランディングページパラメータ** がルールターゲットであるべきです。識別ルール（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>

次を表示 *ルールロジック - 例 1* セクションで、に何を入力するかを確認してください *ルールロジック* と *ルール値 2*.

**例 2: オーガニック検索（Organic Search）**

次のチャネルであるオーガニック検索には UTM パラメータがなく、ランディングページは予測不可能です。これらの条件により、パラメータやクエリ文字列をターゲットにするすべてのルールターゲットと、すべてのランディングページルールターゲットが除外されます。上のグラフからも分かるように、これらの要因を考慮した最良の選択肢は **参照ドメイン（Referring Domain）**&#x3067;す。識別ルールは次のようになります：

| ルールターゲット                 | ルール値 1 | ルールロジック |    |
| ------------------------ | ------ | ------- | -- |
| 参照ドメイン（Referring Domain） | `--`   | \*      | \* |

次を表示 *ルールロジック - 例 2* セクションで、に何を入力するかを確認してください *ルールロジック* と *ルール値 2*.

</details>

<details>

<summary>ルールロジックオプションを選ぶ</summary>

ルールロジックは精度のみで評価できます。次の図は、さまざまなルールロジックオプションを相対的な精度に応じてプロットしたものです。

<div data-with-frame="true"><figure><img src="https://1458456015-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwMLlMoFBtKJa8ptd3zaw%2Fuploads%2Fgit-blob-c917a70e8cfa00de3db2c1855ae9276f687da113%2F5a7fdeb96314eec55916b1fb0357483ee17dd3aec317357e20bbf514232c2ab0.png?alt=media" alt=""><figcaption></figcaption></figure></div>

可能な限り最も精度の高いルールロジックオプションを使用し、他に選択肢がない場合にのみグラフの下に移動してください。以下に、どのルールロジックオプションを使用するかを選ぶための 2 つの例を示します。

**例 1: 有料検索（Paid Search）**

すべての有料検索が Google の UTM パラメータでタグ付けされているため `utm_medium=search`、最良のルールロジックオプションは **正確一致（Exactly Matches）**.

| ルールターゲット      | ルール値 1       | ルールロジック               |          |
| ------------- | ------------ | --------------------- | -------- |
| ランディングページ URL | `utm_medium` | 正確一致（Exactly Matches） | `search` |

**正確一致（Exactly Matches）** です。ここでは、正確なキーと値のペアが `utm_medium=search` であるトラフィックのみがこのチャネルの一部と見なされるため、最適です。

たとえば、ルールロジックオプションとして **が含まれる（Contains）** を代わりに使用した場合、 `utm_medium` を含む任意の `search` 値はこのチャネルの一部とみなされるため、誤った帰属や補償（make-goods）、さらにはその他の問題を引き起こす可能性があります。 **が含まれる（Contains）** とはいえ、ここでそれが誤りの選択というわけではありません； **正確一致（Exactly Matches）** は単により良い選択であるだけです。

**例 2: オーガニック検索（Organic Search）**

前述のとおり参照ドメインが最良の選択であると確定した場合、考えられるルールロジックのオプションは次のようになります：

| ルールターゲット                 | ルール値 1 | ルールロジック         |        |
| ------------------------ | ------ | --------------- | ------ |
| 参照ドメイン（Referring Domain） | `--`   | が含まれる（Contains） | .bing. |

**が含まれる（Contains）** はここでは良い選択です。Bing のオーガニック検索は次のような複数の異なる参照 URL から生じる可能性があるためです：

* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`

サードレベルドメイン（例： *www、cn*）やトップレベルドメイン（例： *com、net*）、および URL パスが非常に異なり得るため、参照ドメインが **.bing.** のセカンドレベルドメインを含むことを確認するだけで、Bing から来るすべてのオーガニック検索トラフィックをこのチャネルの一部と見なせます。

</details>

これらの理由から、より精度の高いルールロジックオプションを選ぶことはできません。そうすると、このチャネルの一部と見なすべき参照ドメインが除外されてしまうためです。

**正規表現（Regex）ルールロジックオプション**

正規表現ソリューションの実装が複雑であるため、impact.com は Optimize 内で正規表現を実装する方法に関して一般的な助言や指示を提供していません。状況によっては正規表現のルールロジックが最適であると思われる場合は、実装を開始する方法について CSM に相談してください。

#### 正確一致（Exactly Matches）と任意一致（Matches Any）

これら 2 つのルールロジックオプションはほぼ同じように機能しますが、小さな違いがあります。 *正確一致（Exactly Matches）* は RTI に記載されている通りの正確なルール値 2 のみを検索します。 *任意一致（Matches Any）* は、ルール内に記載されているすべてのルール値 2 をそのまま検索します。

もし **正確一致（Exactly Matches）** を AND 演算子で複数回使用していることに気付いたら、 **AND** の代わりに **任意一致（Matches Any）**&#x306E;使用を検討してください。同じことは **が含まれる（Contains）** と **Contains Any**.

#### にも当てはまります。

一般的なクリック ID

| クリック ID は有料メディアでますます一般的になっています。以下はトラフィックを識別するために使用できる一般的なクリック ID の一覧です。 | メディアソース                 |
| ----------------------------------------------------------------------- | ----------------------- |
| クリック ID                                                                 | `Google 広告（Google Ads）` |
| GCLID                                                                   | `Bing 広告／Yahoo 検索`      |
| MSCLKID                                                                 | `Facebook 広告`           |
| Pinterest                                                               | `FBCLID`                |

#### EPIK

トラフィックの除外（Disqualifying traffic） *場合によっては、トラフィックを「除外する（disqualify）」 RTI を作成することが、チャネルの一部としてトラフィックを識別するのと同じくらい有用です。以下のサブセクションで、上で作成した例をどのようにトラフィックを除外するように設定できるかを確認してください。* 上で作成した例は次のとおりです：

{% tabs %}
{% tab title="例 1: 有料検索（Paid Search）" %}
このルールは既に多くのトラフィックを除外しています。別の識別ルールを追加し、

|               |              |                       |            |
| ------------- | ------------ | --------------------- | ---------- |
| **ルールターゲット**  | **ルール値 1**   | **ルールロジック**           | **ルール値 2** |
| ランディングページ URL | `utm_medium` | 正確一致（Exactly Matches） | `search`   |

OR **演算子を使用することで、ルールはより多くのトラフィックを対象に拡張できます：** 現在のどちらかのルールが真であれば、そのトラフィックはこのチャネルの一部として識別されます。

|                                            |                         |                       |            |
| ------------------------------------------ | ----------------------- | --------------------- | ---------- |
| **ルールターゲット**                               | **ルール値 1**              | **ルールロジック**           | **ルール値 2** |
| ランディングページ URL                              | `utm_medium`            | 正確一致（Exactly Matches） | `search`   |
| **演算子を使用することで、ルールはより多くのトラフィックを対象に拡張できます：** |                         |                       |            |
| ランディングページパラメータ                             | `Google 広告（Google Ads）` | が存在する（Is Present）     | --         |

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

{% tab title="例 2: オーガニック検索（Organic Search）" %}
このルールは既に多くのトラフィックを除外しています。別の識別ルールを追加し、

| ルールターゲット                 | ルール値 1 | ルールロジック         | ルール値 2 |
| ------------------------ | ------ | --------------- | ------ |
| 参照ドメイン（Referring Domain） | `--`   | が含まれる（Contains） | .bing. |

このルールは Bing によって参照されたすべてのトラフィックを識別します。別のルールを追加し、 **AND** 演算子を使用することで、そのルールは Bing によって参照されたトラフィックを除外し始めることができます：

| ルールターゲット                 | ルール値 1     | ルールロジック                | ルール値 2 |
| ------------------------ | ---------- | ---------------------- | ------ |
| 参照ドメイン（Referring Domain） | `--`       | が含まれる（Contains）        | .bing. |
| **AND**                  |            |                        |        |
| ランディングページパラメータ           | `MSCLIKID` | が存在しない（Is Not Present） | --     |
| {% endtab %}             |            |                        |        |
| {% endtabs %}            |            |                        |        |

今では、両方のルールが真である場合にのみ、そのトラフィックはこのチャネルの一部として識別されます。

#### 大文字と小文字の区別（Case sensitivity）

識別ルールは大文字小文字を区別しません。たとえば、パラメータが `utm_medium=SEARCH`であっても、ルールを次のように設定できます：

| ルールターゲット      | ルール値 1       | ルールロジック               | ルール値 2   |
| ------------- | ------------ | --------------------- | -------- |
| ランディングページ URL | `utm_medium` | 正確一致（Exactly Matches） | `search` |

#### 次は何ですか？

いくつかの [Optimize セットアップのシナリオ](https://help.impact.com/brand/ja/nitsuitebitaidesuka/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples)を確認してください。ここでは、一般的な Optimize シナリオに関する推奨事項が見つかります。