リダイレクトルール条件を作成

すべてのリダイレクトルールは、1つ以上の条件から始まります。1つの 条件 、ランディングページURL、国、デバイス種別など、入ってくるトラフィックの何かを確認し、そのルールが適用されるかどうかを判断します。作成方法の詳細については リダイレクトルールを作成する.

条件属性

下の表には、ルールで使用できる条件属性が一覧されています。

条件属性リファレンス

条件属性	説明
ランディングページ	元の遷移先URL。
IPアドレス	デバイスに登録されているIPアドレス。
共有ID	レポートに使用される、パートナー管理のクエリ文字列パラメータ。
国	トラフィックの発信元の国。
州	トラフィックの発信元の州。
広告ステータス	関連付けられた広告の使用状態。
SubID1	レポートに使用される、パートナー管理のクエリ文字列パラメータ。
SubID2	レポートに使用される、パートナー管理のクエリ文字列パラメータ。
SubID3	レポートに使用される、パートナー管理のクエリ文字列パラメータ。
MP ID	impact.com におけるパートナーの一意な識別子
デバイスタイプ	リダイレクトルールの有効化が求められたときに、顧客が使用していたデバイスの種類。
参照URL	元の遷移先URLへトラフィックを参照しているWebサイトのURL。
商品SKU	通常は商品カタログで指定される、広告の対象の識別子。
広告ID	impact.com における広告の一意な識別子。
確率	リダイレクトルールが、リダイレクト対象としてランダムに一定割合のトラフィックを取得します。これは主にA/Bテストで使用されます。
モバイルフォールバック	広告に モバイルフォールバック が設定されている場合、関連するルーティングルールは、アプリをダウンロードするためにトラフィックをそれぞれのアプリストアへ再ルーティングするよう要求できます。 モバイルフォールバック リダイレクトルールは通常、オンボーディング中に設定されます。モバイルフォールバックのリダイレクトルールが必要かどうか、技術仕様を確認してください。
アプリ名	リダイレクトルールの有効化が求められたときに、顧客が使用していたアプリの名前。
ブラウザ名	リダイレクトルールの有効化が求められたときに、顧客が使用していたブラウザの名前。
オペレーティングシステム名	リダイレクトルールの有効化が求められたときに、顧客が使用していたオペレーティングシステムの名前。
アプリ内WebView	リダイレクトルールの有効化が求められたときに、顧客がアプリ内WebViewを使用していたかどうか。

条件演算子

最も便利な条件属性の1つは ランディングページ、入ってくるURLに基づいて条件やリダイレクトを作成できるためです。以下に挙げる演算子は ランディングページ 属性向けのものです。利用できる演算子は、選んだ属性によって異なります。ほとんどの属性はより少ないセットしか提供しません。たとえば、 モバイルフォールバック のみ提供します である と でない.

条件演算子リファレンス

演算子	説明
含む	属性値に指定したテキストが含まれます。
で始まる	属性値が指定したテキストで始まります。
で終わる	属性値が指定したテキストで終わります。
一致する	属性値がパターンに一致します。パターンにはプレースホルダー（{NAME}）を使って値の一部をキャプチャでき、ワイルドカード（*）を使って残りの任意の文字に一致させることができます。
のいずれかに含まれる	属性値は、指定した値の一覧のいずれか1つです。
含まない	属性値に指定したテキストは含まれません。
で始まらない	属性値は指定したテキストでは始まりません。
で終わらない	属性値は指定したテキストで終わりません。
でない	属性値は指定した値と完全には一致しません。
いずれにも含まれない	属性値は、指定した値の一覧のどれにも含まれません。
正規表現	属性値がカスタム正規表現に一致します。

条件を組み合わせる

複数の条件を AND:

• 使用できます AND 。たとえば、特定の国からのトラフィックかつ特定のデバイス種別であるなど、複数のことが同時に真である必要がある場合に使います。
• 選択 もう1つ追加 して、最初の条件または新しい条件のどちらかを満たす、別個の独立した条件を追加します。両方を満たす必要はありません。つまり、 もう1つ追加 は OR 条件のようなものです。

次の2つのセクションでは、 含む と 一致する 演算子を使ってリダイレクトルールを作成する方法を示します。

含む演算子を使う

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の一部を再利用できません。その場合は、 一致する.

一致演算子を使う

この 一致する 演算子を使うと、URL全体のパターンを記述し、その一部をプレースホルダーとして {PLACEHOLDER}書いてマークし、後でリダイレクト内でその正確な部分を再利用できます。

プレースホルダー付きの一致を使う

商品を売っているとしましょう。各UKの商品ページは次のような形式です https://www.example.com/uk/<product-name>。それぞれを、商品名を維持したまま、パートナーサイトの同じページへリダイレクトしたいとします。

1. 条件を ランディングページ 一致する https://www.example.com/uk/{PRODUCT}に設定します。これは、 https://www.example.com/uk/ で始まるURLに一致し、直後に続く内容を PRODUCT.
2. これをテストするには、 https://www.example.com/uk/sneakers をテスト用ランディングページとして入力してください。結果として、一致が成功し、 {PRODUCT} に sneakers.
3. アクションを次のURLにリダイレクトするよう設定します https://www.example.com/uk/{PRODUCT}?a=123となり、 https://www.example.com/uk/sneakers?a=123 一度 {PRODUCT} キャプチャされると sneakers.

したがって、プレースホルダーは変数のように機能し、入力URLからキャプチャしたテキストは、出力URLの同じ場所に差し込まれます。

ワイルドカードとプレースホルダーのリファレンス

上とまったく同じルールを使って、少し異なるURLをテストしてみてください:

1. これをテストするには、 https://www.example.com/uk/sneakers/mens をテスト用ランディングページとして入力してください。結果として、一致は見つかりません。

これは 一致する 演算子が、先頭だけでなくURL全体に対してパターンを確認するためです。パターン https://www.example.com/uk/{PRODUCT} は /uk/の後の1つのセグメントしか考慮しておらず、追加の /mensを考慮していないため、一致に失敗します。

プレースホルダーの後に何でも許可するには、パターンの末尾にワイルドカード（*）を追加します:

• 新しいパターン: https://www.example.com/uk/{PRODUCT}*
• これで両方に一致します https://www.example.com/uk/sneakers と https://www.example.com/uk/sneakers/mens. {PRODUCT} は引き続き sneakers のみをキャプチャし /（次の * ）まで）、それ以降に続くものは単に吸収します。

パターンが *で終わらない場合、入力URLはパターンとまったく同じ位置で終わっていなければならず、そうでないと一致しません。

複数のプレースホルダーを使って一致させる

同じパターンの中で複数のプレースホルダーを使うことができます。たとえば、実際の商品ページには https://www.example.com/uk/shop/product/sneakers/SKU123-blue-running-shoeのようにカテゴリとSKUの両方が含まれ、ページの後ろに追加コンテンツが付くこともあります（たとえば /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. アクションを次のURLにリダイレクトするよう設定します https://www.example.com/redirect/{CATEGORY}/{SKU}となり、 https://www.example.com/redirect/sneakers/SKU123-blue-running-shoe 両方のキャプチャ値が再利用されると /reviews 、その部分はリダイレクトURLで参照されていないため削除されます。

ワイルドカードとプレースホルダーのリファレンス

下の表には、 一致する ルールを記述するときに使用できる構文が一覧されています。

構文	内容
{NAME}	次の / またはURLの末尾まで）に達する1つのURLセグメントをキャプチャし、リダイレクトアクションで再利用できるようにするプレースホルダー。
*	プレースホルダーの後に続く残りの文字に一致します。URLがパターンの後に追加の内容を持つ可能性があるときに使います。
いいえ * 末尾で	パターンはURLの末尾まで完全に一致していなければなりません。余分な文字は許可されません。