> 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 Logic を適用し、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 は次のようになります。
Rule TargetRule Value 1Rule Logic
ランディングページURLutm_medium**
次を表示します *Rule Logic - 例 1* のセクションを参照して、 *Rule Logic* および *Rule Value 2*. **例 2: オーガニック検索** 次のチャネルであるオーガニック検索には UTM パラメータがなく、ランディングページも予測できません。これらの条件により、パラメータやクエリ文字列を対象とするすべての Rule Target と、すべてのランディングページ Rule Target は除外されます。上のグラフからわかるように、これらすべての要素を考慮すると最善の選択は **紹介元ドメイン**です。Rule To Identify は次のようになります。 | Rule Target | Rule Value 1 | Rule Logic | | | ----------- | ------------ | ---------- | -- | | 紹介元ドメイン | `--` | \* | \* | 次を表示します *Rule Logic - 例 2* のセクションを参照して、 *Rule Logic* および *Rule Value 2*.
Rule Logic のオプションを選ぶ Rule Logic は精度のみで評価できます。以下の図は、さまざまな Rule Logic オプションを相対的な精度の観点で示したものです。
常に、使える中で最も正確な Rule Logic オプションを使うようにし、ほかに選択肢がない場合にのみグラフの下へ移動してください。以下に、どの Rule Logic オプションを使うかを選ぶための 2 つの例を示します。 **例 1: 有料検索** すべての有料検索には Google の UTM パラメータが付与されているため、 `utm_medium=search`、可能な限り最適な Rule Logic オプションは **完全一致**. | Rule Target | Rule Value 1 | Rule Logic | | | ------------ | ------------ | ---------- | -------- | | ランディングページURL | `utm_medium` | 完全一致 | `search` | **完全一致** が最適です。というのも、 `utm_medium=search` の正確なパラメータのキーと値の組み合わせを持つトラフィックだけを、このチャネルの一部と見なすべきだからです。 たとえば、Rule Logic オプションの **含む** を使った場合、 `utm_medium` を含む `search` あらゆる値がこのチャネルの一部と見なされ、誤ったアトリビューションや make-good、さらにその先の問題につながる可能性があります。 **含む** ただし、これはここでの誤った選択ではありません。 **完全一致** 単に、より良い選択肢があるというだけです。 **例 2: オーガニック検索** 参照ドメイン Rule Target が先に最善の選択として確立されているため、考えられる Rule Logic オプションは次のようになります。 | Rule Target | Rule Value 1 | Rule Logic | | | ----------- | ------------ | ---------- | ------ | | 紹介元ドメイン | `--` | 含む | .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 から来るすべてのオーガニック検索トラフィックをこのチャネルの一部として扱えるようになります。
これらの理由から、さらに精密な Rule Logic オプションは選べません。選ぶと、このチャネルの一部と見なすべき参照ドメインを除外してしまうからです。 **正規表現の Rule Logic オプション** 正規表現ソリューションの実装は複雑なため、impact.com では Optimize での正規表現の実装方法について一般的な助言や指示は提供していません。正規表現の 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` | #### 対象外トラフィック 場合によっては、 *除外する* トラフィックを識別するルールを作成することが、チャネルの一部としてトラフィックを識別するのと同じくらい役立つことがあります。上で作成した例を使って、どのようにトラフィックを除外するよう設定できるかは、以下のサブセクションをご覧ください。 {% tabs %} {% tab title="例 1: 有料検索" %} 以下は、上で作成した例です: | | | | | | --------------- | ---------------- | -------------- | ---------------- | | **Rule Target** | **Rule Value 1** | **Rule Logic** | **Rule Value 2** | | ランディングページURL | `utm_medium` | 完全一致 | `search` | このルールだけでも、多くのトラフィックをすでに除外しています。さらに別の Rule To Identify を追加し、 **または** 演算子を使うことで、より多くのトラフィックを許可するようにルールを広げられます: | | | | | | --------------- | ---------------- | -------------- | ---------------- | | **Rule Target** | **Rule Value 1** | **Rule Logic** | **Rule Value 2** | | ランディングページURL | `utm_medium` | 完全一致 | `search` | | **または** | | | | | ランディングページパラメータ | `GCLID` | 存在する | -- | これで、どちらかのルールが真であれば、そのトラフィックはこのチャネルの一部として識別されます。 {% endtab %} {% tab title="例 2: オーガニック検索" %} 以下は、上で作成した例です: | Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 | | ----------- | ------------ | ---------- | ------------ | | 紹介元ドメイン | `--` | 含む | .bing. | このルールは、Bing から参照されたすべてのトラフィックを識別します。さらに別のルールを追加し、 **AND** 演算子を使うことで、Bing から参照されたトラフィックを除外し始めることができます: | Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 | | -------------- | ------------ | ---------- | ------------ | | 紹介元ドメイン | `--` | 含む | .bing. | | **AND** | | | | | ランディングページパラメータ | `MSCLIKID` | 存在しない | -- | | {% endtab %} | | | | | {% endtabs %} | | | | これで、トラフィックがこのチャネルの一部として識別されるには、両方のルールが真である必要があります。 #### 大文字小文字の区別 Rules To Identify は大文字小文字を区別しません。たとえば、 `utm_medium=SEARCH`というパラメータがある場合でも、ルールは次のように設定できます: | Rule Target | Rule Value 1 | Rule Logic | Rule Value 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.