> 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/blocking-and-redirect-rules/build-redirect-rule-conditions.md).
# リダイレクトルール条件を作成
すべてのリダイレクトルールは、1つ以上の条件から始まります。A *条件* は、流入トラフィックについての何か（ランディングページのURL、国、デバイスの種類など）を確認し、そのルールが適用されるかどうかを判断します。方法の詳細を読むには [リダイレクトルールを作成する](/brand/ja/what-would-you-like-to-learn-about/platform-features/blocking-and-redirect-rules/create-a-redirect-rule.md).
## 条件属性
以下の表には、ルールで使用できる条件属性が一覧表示されています。
条件属性リファレンス
| 条件属性 | 説明 |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ランディングページ | 元の遷移先URL。 |
| IPアドレス | デバイスに登録されているIPアドレス。 |
| 共有ID | レポートで使用される、パートナーが管理するクエリ文字列パラメータ。 |
| 国 | トラフィックの発信元の国。 |
| 状態 | トラフィックの発信元の州。 |
| 広告ステータス | 関連付けられた広告の利用状態。 |
| SubID1 | レポートで使用される、パートナーが管理するクエリ文字列パラメータ。 |
| SubID2 | レポートで使用される、パートナーが管理するクエリ文字列パラメータ。 |
| SubID3 | レポートで使用される、パートナーが管理するクエリ文字列パラメータ。 |
| MP ID | impact.comのパートナー固有識別子 |
| デバイスタイプ | リダイレクトルールの有効化が促されたときに顧客が使用していたデバイスの種類。 |
| 参照URL | 元の遷移先URLへトラフィックを送っている参照元サイトのURL。 |
| 商品 SKU | 通常は製品カタログで指定される、広告の対象を識別するID。 |
| 広告ID | impact.comの広告固有識別子 |
| 確率 | リダイレクトルールは、トラフィックの一定割合をランダムに取得して別の場所へ転送します。これは主にA/Bテストで使用されます。 |
| モバイルフォールバック | 広告に モバイルフォールバック が設定されている場合、関連するルーティングルールは、アプリをダウンロードするためにそれぞれのアプリストアへトラフィックを転送するよう要求できます。
モバイルフォールバック リダイレクトルールは通常、オンボーディング時に設定されます。技術仕様を確認して、モバイルフォールバックのリダイレクトルールが必要かどうかを確認してください。
|
| アプリ名 | リダイレクトルールの有効化が促されたときに顧客が使用していたアプリの名前。 |
| ブラウザ名 | リダイレクトルールの有効化が促されたときに顧客が使用していたブラウザの名前。 |
| オペレーティングシステム名 | リダイレクトルールの有効化が促されたときに顧客が使用していたオペレーティングシステムの名前。 |
| アプリ内WebView | リダイレクトルールの有効化が促されたときに顧客がアプリ内WebViewを使用していたかどうか。 |
## 条件演算子
最も便利な条件属性の1つは **ランディングページ**です。というのも、受信URLに基づいて条件やリダイレクトを構築できるからです。以下に挙げる演算子は **ランディングページ** その属性用です。利用できる演算子は、選択した属性によって異なります。ほとんどの属性では、より少ないセットしか提供されません。たとえば、 **モバイルフォールバック** のみを提供します **次と等しい** および **ではない**.
条件演算子リファレンス
| 演算子 | 説明 |
| ------------- | -------------------------------------------------------------------------------------------- |
| **次を含む** | 属性の値に指定されたテキストが含まれます。 |
| **次で始まる** | 属性の値が指定されたテキストで始まります。 |
| **次で終わる** | 属性の値が指定されたテキストで終わります。 |
| **一致する** | 属性の値がパターンに一致します。パターンにはプレースホルダー（`{NAME}`）を含めて値の一部を取得したり、ワイルドカード（`*`）を使って残りの任意の文字列に一致させたりできます。 |
| **次のいずれか** | 属性の値が指定された値のリストのいずれかに該当します。 |
| **次を含まない** | 属性の値に指定されたテキストは含まれません。 |
| **次で始まらない** | 属性の値が指定されたテキストで始まりません。 |
| **次で終わらない** | 属性の値が指定されたテキストで終わりません。 |
| **ではない** | 属性の値が指定された値と完全には一致しません。 |
| **次のいずれでもない** | 属性の値は、指定された値のリストのいずれにも該当しません。 |
| **正規表現** | 属性の値がカスタム正規表現に一致します。 |
## 条件を組み合わせる
複数の条件を **かつ**:
* 使用して **かつ** 複数の条件が同時に真である必要がある場合に使用します。たとえば、特定の国からのトラフィックで、かつ特定のデバイス種類である場合です。
* 選択 **別の項目を追加** を使うと、最初の条件または新しい条件のどちらかを満たす、別個の独立した条件を追加できます。両方を満たす必要はありません。つまり、 **別の項目を追加** は **OR** 条件のようなものです。
次の2つのセクションでは、次の演算子を使ってリダイレクトルールを作成する方法を示します。 *含む* および *一致する* 演算子。
## contains演算子を使用する
URLによってトラフィックを分岐する最も簡単な方法は、次を使用する2つの個別ルールです。 **次を含む**。たとえば、UKページに到達した人には1つのクエリパラメータを、USページに到達した人には別のクエリパラメータを付与したいとします。
ルール1、UKトラフィック：
1. 条件： `ランディングページ` **次を含む** `/uk`.
2. アクション：同じURLにリダイレクトし、 `?a=123` を末尾に追加します。
ルール2、USトラフィック：
1. 条件： `ランディングページ` **次を含む** `/us`.
2. アクション：同じURLにリダイレクトし、 `?a=456` を末尾に追加します。
各ルールは、受信URLに含まれる1つのテキスト（ `/uk` または `/us`）。テキストが見つかると、リダイレクトルールは追加パラメータを付けて訪問者を先へ送ります。
これは単純な二者択一の分岐にはうまく機能しますが、この方法では元のURLの一部を再利用できません。そのためには、 **一致する**.
## matches演算子を使用する
この **一致する** 演算子を使うと、URL全体のパターンを記述し、その一部をプレースホルダーで示せます。プレースホルダーは `{PLACEHOLDER}`と書き、後でリダイレクトでその正確な部分を再利用できます。
プレースホルダー付きでmatchesを使用する
あなたが靴を販売していて、UKの各商品ページが次のような形だとします `https://www.example.com/uk/`。
1. 条件を次のように設定します `ランディングページ` **一致する** `https://www.example.com/uk/{PRODUCT}`。これは、次で始まる任意のURLに一致します `https://www.example.com/uk/` そして、その直後に続くものを `PRODUCT`.
2. 次を入力してテストしてください `https://www.example.com/uk/sneakers` をテスト用ランディングページとして使用します。結果として、一致成功が得られ、 `{PRODUCT}` に設定されます `sneakers`.
3. アクションを次へリダイレクトするよう設定します `https://www.example.com/uk/{PRODUCT}?a=123`。これは次のようになります `https://www.example.com/uk/sneakers?a=123` 一度 `{PRODUCT}` が次のように取得されると `sneakers`.
したがって、プレースホルダーは変数のように機能します。受信URLから取得したテキストは、送信先URLの同じ場所に挿入されます。
ワイルドカード付きでmatchesを使用する
上記とまったく同じルールを使って、少し異なるURLをテストしてみてください：
1. 次を入力してテストしてください `https://www.example.com/uk/sneakers/mens` をテスト用ランディングページとして使用します。結果として、一致は見つかりません。
これは、 **一致する** matches演算子は、パターンをURL全体に対してチェックします。先頭だけではありません。パターン `https://www.example.com/uk/{PRODUCT}` は次の後の1セグメントしか考慮していません `/uk/`。そして、追加の `/mens`を考慮するものがないため、一致に失敗します。
プレースホルダーの後ろに何でも許可するには、ワイルドカード（`*`）をパターンの末尾に追加します：
* 新しいパターン： `https://www.example.com/uk/{PRODUCT}*`
* これで次の両方に一致します `https://www.example.com/uk/sneakers` および `https://www.example.com/uk/sneakers/mens`. `{PRODUCT}` ただし取得するのは引き続き `sneakers` （次の `/`） `*` 以降の文字列をそのまま吸収します。
パターンが次で終わっていない場合 `*`、受信URLはパターンとまったく同じ位置で終わっていなければならず、そうでないと一致しません。
複数のプレースホルダー付きでmatchesを使用する
同じパターン内で複数のプレースホルダーを使用できます。たとえば、商品ページにカテゴリとSKUの両方が含まれていて、次のような場合です `https://www.example.com/uk/shop/product/sneakers/SKU123-blue-running-shoe`。また、ページによってはその後ろに追加の内容が入ることがあります（たとえば `/reviews`).
1. 条件を次のように設定します `ランディングページ` **一致する** `https://www.example.com/uk/shop/product/{CATEGORY}/{SKU}*`。ここで：
* `{CATEGORY}` は次の直後のセグメントを取得します `/product/`.
* `{SKU}` はその次のセグメントを取得します。
* 末尾の `*` は、その後に続く他の任意の内容（たとえば `/reviews`）を許可します。これは前のセクションの内容を利用しています。
2. 次を入力してテストしてください `https://www.example.com/uk/shop/product/sneakers/SKU123-blue-running-shoe/reviews`。結果として、一致成功が得られ、 `{CATEGORY}` に設定されます `sneakers` および `{SKU}` に設定されます `SKU123-blue-running-shoe`.
3. アクションを次へリダイレクトするよう設定します `https://www.example.com/redirect/{CATEGORY}/{SKU}`。これは次のようになります `https://www.example.com/redirect/sneakers/SKU123-blue-running-shoe` 両方の取得値が再利用されるときです。The `/reviews` 部分は、リダイレクトURLで参照されていないため省略されます。
ワイルドカードとプレースホルダーのリファレンス
以下の表には、 **一致する** ルールを作成するときに使用できる構文が一覧表示されています。
| 構文 | 機能 |
| ----------- | -------------------------------------------------------------------------- |
| `{NAME}` | 1つのURLセグメントを取得するプレースホルダー（次の `/` またはURLの末尾まで）を取得し、リダイレクトアクションで再利用できるようにします。 |
| `*` | プレースホルダーの後に続く残りの文字列に一致します。URLにパターンの後ろへ追加の内容が入る可能性がある場合に使用します。 |
| いいえ `*` 末尾で | パターンはURLの末尾まで完全に一致している必要があります。余分なものは一切許可されません。 |
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://help.impact.com/brand/ja/what-would-you-like-to-learn-about/platform-features/blocking-and-redirect-rules/build-redirect-rule-conditions.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.