> 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/what-would-you-like-to-learn-about/platform-features/blocking-and-redirect-rules/build-redirect-rule-conditions.md). # Build Redirect Rule Conditions Every redirect rule starts with one or more conditions. A *condition* checks something about the incoming traffic, such as its landing page URL, country, or device type, and decides whether the rule applies. Read more about how to [Create a Redirect Rule](/brand/what-would-you-like-to-learn-about/platform-features/blocking-and-redirect-rules/create-a-redirect-rule.md). ## Condition attributes The table below lists the condition attributes you can use in a rule.
Condition attribute reference | Condition Attribute | Description | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Landing Page | The original destination URL. | | IP Address | The IP address registered to a device. | | Shared ID | A partner-controlled query string parameter that is used in reporting. | | Country | The country from where traffic is sourced. | | State | The state from where traffic is sourced. | | Ad Status | The associated ad's state of use. | | SubID1 | A partner-controlled query string parameter that is used in reporting. | | SubID2 | A partner-controlled query string parameter that is used in reporting. | | SubID3 | A partner-controlled query string parameter that is used in reporting. | | MP ID | impact.com's unique identifier for a partner | | Device Type | What type of device the customer was using when the redirect rule was prompted to activate. | | Ref URL | URL of the website that is referring traffic to the original destination URL. | | Product SKU | An identifier for the subject of the ad, which is usually designated in a product catalog. | | Ad ID | impact.com's unique identifier for an ad. | | Probability | The redirect rule will randomly grab a percentage of traffic to be rerouted. This is primarily used for A/B testing. | | Mobile Fallback |

If an ad has mobile fallback configured, the associated routing rule can request to reroute traffic to their respective app store to download an app.

Mobile fallback redirect rules are usually set up during Onboarding. Check your tech specs to see if you should have a mobile fallback redirect rule.

| | App Name | The name of the app the customer was using when the redirect rule was prompted to activate. | | Browser Name | The name of the browser the customer was using when the redirect rule is prompted to activate. | | Operating System Name | The name of the operating system the customer was using when the redirect rule is prompted to activate. | | In-App WebView | Whether the customer was using an in-app webview when the redirect rule is prompted to activate. |
## Condition operators One of the most useful condition attributes is **Landing Page**, since it lets you build conditions, and redirects, based on the incoming URL. The operators listed below are for the **Landing Page** attribute. The operators available depend on which attribute you pick: most attributes offer a smaller set. For example, **Mobile Fallback** only offers **is** and **is not**.
Condition operators reference | Operator | Description | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **contains** | The attribute's value includes the specified text. | | **starts with** | The attribute's value begins with the specified text. | | **ends with** | The attribute's value ends with the specified text. | | **matches** | The attribute's value matches a pattern, which can include placeholders (`{NAME}`) to capture parts of the value and a wildcard (`*`) to match any remaining characters. | | **in** | The attribute's value is one of a specified list of values. | | **doesn't contain** | The attribute's value does not include the specified text. | | **doesn't start with** | The attribute's value does not begin with the specified text. | | **doesn't end with** | The attribute's value does not end with the specified text. | | **is not** | The attribute's value does not exactly equal the specified value. | | **not in** | The attribute's value is not any of a specified list of values. | | **Regex** | The attribute's value matches a custom regular expression. |
## Combine conditions You can combine multiple conditions using **AND**: * Use **AND** when more than one thing needs to be true at the same time, for example, traffic from a specific country and on a specific device type. * Select **Add another** to add a separate, independent condition that meets either the first condition or the new one. It doesn't need to meet both. This means that **Add another** is like an **OR** condition. The next two sections show how to create a redirect rule using the *Contains* and *Matches* operators. ## Use the contains operator The simplest way to branch traffic by URL is with two separate rules using **contains**. Say you want anyone landing on a UK page to get one query parameter, and anyone landing on a US page to get another. Rule 1, UK traffic: 1. Condition: `Landing Page` **contains** `/uk`. 2. Action: Redirect to the same URL, with `?a=123` added to the end. Rule 2, US traffic: 1. Condition: `Landing Page` **contains** `/us`. 2. Action: Redirect to the same URL, with `?a=456` added to the end. Each rule checks the incoming URL for one piece of text (either `/uk` or `/us`). If it finds the text, the redirect rule sends the visitor onward with an extra parameter added on. This works well for simple either/or splits, but this technique can't reuse parts of the original URL. For that, you need to use **matches**. ## Use the matches operator The **matches** operator lets you write a pattern for the whole URL, and mark one part of it with a placeholder, written as `{PLACEHOLDER}`, so you can reuse that exact piece later in the redirect.
Use matches with a placeholder Say you sell shoes, and every UK product page looks like `https://www.example.com/uk/`. You want to redirect each one to the same page on a partner site, keeping the product name. 1. Set the condition to `Landing Page` **matches** `https://www.example.com/uk/{PRODUCT}`, which matches any URL that starts with `https://www.example.com/uk/` and calls whatever comes right after that `PRODUCT`. 2. Test it by entering `https://www.example.com/uk/sneakers` as a test landing page. You'll receive the result: a successful match, with `{PRODUCT}` set to `sneakers`. 3. Set the action to redirect to `https://www.example.com/uk/{PRODUCT}?a=123`, which becomes `https://www.example.com/uk/sneakers?a=123` once `{PRODUCT}` is captured as `sneakers`. So the placeholder acts like a variable: whatever text it captures from the incoming URL gets dropped into the same spot in the outgoing URL.
Use matches with a wildcard Using the exact same rule as above, try testing a slightly different URL: 1. Test it by entering `https://www.example.com/uk/sneakers/mens` as a test landing page. You'll receive the result: no match found. This is because the **matches** operator checks the pattern against the entire URL, not just the start of it. The pattern `https://www.example.com/uk/{PRODUCT}` only accounts for one segment after `/uk/`, and has nothing to account for the extra `/mens`, so the match fails. To allow anything after the placeholder, add a wildcard (`*`) to the end of the pattern: * New pattern: `https://www.example.com/uk/{PRODUCT}*` * This now matches both `https://www.example.com/uk/sneakers` and `https://www.example.com/uk/sneakers/mens`. `{PRODUCT}` still only captures `sneakers` (up to the next `/`), and `*` simply absorbs whatever comes after it. If your pattern doesn't end in `*`, the incoming URL must end at exactly the same point the pattern does, or it won't match.
Use matches with multiple placeholders You can use multiple placeholders in the same pattern. Say your product pages actually include both a category and a SKU, like `https://www.example.com/uk/shop/product/sneakers/SKU123-blue-running-shoe`, and the page sometimes has extra content after that (like `/reviews`). 1. Set the condition to `Landing Page` **matches** `https://www.example.com/uk/shop/product/{CATEGORY}/{SKU}*`, where: * `{CATEGORY}` captures the segment right after `/product/`. * `{SKU}` captures the next segment after that. * the trailing `*` allows anything else that follows (like `/reviews`), using the lesson from the previous section. 2. Test it by entering `https://www.example.com/uk/shop/product/sneakers/SKU123-blue-running-shoe/reviews`. You should receive the result: a successful match, with `{CATEGORY}` set to `sneakers` and `{SKU}` set to `SKU123-blue-running-shoe`. 3. Set the action to redirect to `https://www.example.com/redirect/{CATEGORY}/{SKU}`, which becomes `https://www.example.com/redirect/sneakers/SKU123-blue-running-shoe` once both captured values are reused. The `/reviews` part is dropped because the redirect URL doesn't reference it.
Wildcards and placeholders reference The table below lists the syntax you can use when writing a **matches** rule. | Syntax | What it does | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `{NAME}` | A placeholder that captures one URL segment (up to the next `/` or the end of the URL) so it can be reused in the redirect action. | | `*` | Matches any remaining characters after a placeholder. Use it when the URL might have extra content after your pattern. | | No `*` at the end | The pattern must match the URL exactly to its end. Nothing extra is allowed. |
--- # 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/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 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.