Skip to main content

Pages

Pages are targetable constructs that allow you to choose where and when to deliver Rokt offers and personalized experiences on your site.

A page tells Rokt where your customer is in your transaction flow, and page type indicates the principle objective of the page they’re visiting. This helps Rokt to contextually optimize the experience for customers on your site. For example, a page may tell Rokt to show a placement on your confirmation page and launch it immediately when the page loads.

We encourage you to integrate each page within your checkout flow even if you don’t plan on having Rokt placements on every page. This way Rokt can track and analyze performance on every page involved in your transaction experience.

Page types#

This table shows common page types supported by Rokt Ecommerce, as well as if a page type is considered transactional or non-transactional.

Page typeTransaction or non-transactionCart status
Product selectionTransactionIn-cart
UpsellTransactionIn-cart
Customer detailsTransactionIn-cart
ShippingTransactionIn-cart
PaymentTransactionIn-cart
ConfirmationTransactionPost-cart
Cart reviewTransactionIn-cart
Booking detailsNon-transactionPost-cart
Landing pageNon-transactionNon-cart
Enquiry formNon-transactionNon-cart

Adding pages#

To create a page, log in to One Platform and follow these steps:

  1. Navigate to Transactions > Pages.
  2. Select Add new page.
  3. Input a Page name and select a Page type.
  4. Set up your Targeting rules.
  5. Click Save.

Congratulations, you’ve created your page!

Targeting rules configuration#

A page is identified when the unique identifier for a page on your site matches the preconfigured targeting rules for that page.

Targeting rules are necessary for Rokt to determine which page to activate when a customer is transacting on your site, depending on how you identify the steps in your transaction journey.

The following components are available for page targeting:

  • URL: The full document location of a page. URL is the building block of Rokt's targeting conditions and is extremely flexible when combined with components and operators.
  • Host: Commonly referred to as the domain or domain name.
  • Path: The portion of the URL following the host/domain name that doesn't include query parameters. This is the path (or stem) that is similar to a file path on your computer. The path is often represented by a drill down or tree structure that uses forward slashes to organize files and folders. The path includes the filename (if there is one), for example, index.htm, products.php, or about.html. The path always ends when a question mark appears in the URL, which denotes the beginning of the query string.
  • Query String: The list of variables in the URL, denoted as key-value pairs. The query string is separated from the path (or hostname) with a question mark. Pairs are separated with an ampersand, "&". Not all URLs include a query string of parameters.
  • ViewName: Used on pages when the website URL does not change, such as single page applications (SPAs). When targeting SPAs, it is best practice to use custom event functions to notify that something has occurred within the application, for example, a change in view or page content.

We've provided a convenient condition checker to help you verify whether the conditions specified in your targeting rules apply to visitors to a page on your site. You can enter a value into the check field, and if the conditions specified above apply, you'll see a green check next to it.

Example#

Consider the transaction experience on an ecommerce site with a simple four-step checkout flow comprised of the following pages:

  1. Product selection
  2. Shipping information
  3. Payment
  4. Order confirmation

A checkout confirmation page may have a simple static URL that does not change regardless of the path a customer takes to complete their purchase (e.g., domain.com/checkout/confirmation). Targeting this page in the Rokt platform may only require a single targeting rule to match a specific URL. This is how it might be configured in when setting up a new page:

Pages Checkout Confirmation

By comparison, the product selection pages of an ecommerce site may follow a similar template but contain dynamic information in the query string or URL path (e.g., domain.com/event/2E0054EDEE9410B3). You may need to configure multiple values for your targeting rule, or event a set of rules, to ensure Rokt matches your page to the relevant product selection pages at the top of your funnel. When setting up targeting on this page consider using values like:

Pages Product Selection

When the Rokt Web SDK fires on a page, it matches true when the URL of that page is http://store.example.com/product_selection?productid=1234 or http://www.example.com/store/product_selection/some-product.

Make sure the Rokt Web SDK is implemented on all of the pages you target. This ensures Rokt can track and analyze customer behavior on every page you target, regardless of whether you decide to show Rokt offers on the page.

Page targeting#

Targeting rules specify which pages on your site should activate the Rokt JavaScript SDK to track behavior and optimize the page experience for each customer. We do this by matching the URL or ViewName value specified in the targeting rules to the page your customer is on when the Rokt JavaScript SDK fires. You will be unable to save a page without targeting rules.

The following operators are available when configuring targeting rules: matches, equals, contains, starts with, ends with, and matches regex. The inverse versions are also available: does not equal, does not contain, does not start with, does not end with, and does not match regex. Read on below to learn more about the key match types and how they might be used for page targeting.

Matches#

The matches condition is ideal to use when a page should broadly match to a specific URL or ViewName value, while allowing for some simple variations. You can use matches when there are query string parameters in the URLs that you don't want to include in the matching. Matches can be more flexible than equals because it adheres to the following rules:

  • Ignores query string parameters and fragments
  • Case insensitive
  • Normalized to remove a www. prefix
  • Normalized to remove a trailing slash
  • HTTP and HTTPS are optional (protocol ignored if supplied)

URL example#

Page Targeting URL Example

The values in the above example evaluate as true because they generally match the full URL specified. The matches condition ignores minor variations in the URL, such as changing the protocol, including a trailing slash, or removing the www. prefix. Even adding query or hash parameters allows the page to be matched.

Values in the URL which won't be ignored are those which suggest the page is not the same as the original URL. The URLs which fail to match the targeting conditions in the above example either add an extension (such as .html), include a subdirectory, or do not have the same subdomain (excluding the www. prefix).

Host example#

Page Targeting Host Example

These examples match because the host value does not change at all in the URL, indicating that the visitor is on the same page as the original value specified. The sample URLs which do not pass the rule check fail because they are not the same host, due to an additional subdirectory, a different subdomain, or the domain itself being different.

Path example#

Page Targeting Host Example

Query string example#

Page Targeting URL Example

Equals#

When using the URL targeting component, every character in your URL, from beginning to end, must be an exact match of the entered value for the condition to evaluate as true. Use equals when you wish to target URLs that never contain dynamic information, such as session identifiers or query string parameters.

When using the path targeting component, every character in the document path must be an exact match of the entered value for the condition to evaluate as true. As mentioned above, query string parameters cannot be evaluated when using the equals operator.

URL example#

ComponentConditionValue
URLequalshttp://www.example.com/product_selection

Evaluates true for:

  • http://www.example.com/product_selection

Evaluates false for:

  • http://www.example.com/product_selection?productid=1234

Path example#

ComponentConditionValue
Pathequals/product_selection

Evaluates true for:

  • /product_selection AND /product_selection?productid=1234

Evaluate false for:

  • /product_selection_final

Contains#

The contains condition (also known as a substring match) allows you to target any occurrence of a substring with a longer string. Contains is useful when targeting a unique query string parameter that appears in multiple URLs.

Example#

ComponentConditionValue
URLcontainspage=4

Evaluates true for

  • http://www.example.com/member.cgi?id=9&page=4

Evaluates false for:

  • http://www.example.com/member.cgi?id=9&page=2

Starts with#

The starts with condition matches identical characters starting from the beginning of the string up to and including the last character in the string you specify. Use the starts with match type when your URLs are generally unvarying but can include query string parameters at the end that you want to exclude.

Example#

ComponentConditionValue
URLstarts withhttp://www.example.com/pages

Ends with#

An exact match of the entered value with the end of the URL. For example, you can target shopping cart pages that use /thankyou.html at the end of their URLs.

ComponentConditionValue
URLends with/thankyou.html

Evaluates true for:

  • http://www.example.com/checkout/thankyou.html

Evaluates false for:

  • http://www.example.com/checkout.thankyou.html?x=1&y=1

Regular expression matches#

A regular expression (regex) uses special characters to enable wildcard and flexible matching. Regex matches are useful when the path, trailing parameters, or both, can vary in URLs for the same webpage. If a customer could be on one of many subdomains, and your URLs use session identifiers, you could use a regular expression to define the constant element of your URL.

Example#

ComponentConditionValue
URLMatch regex.\*/product_selection/(shoes\|hats\|shirts)\*

Evaluates true for:

  • http://www.example.com/product_selection/shoes
  • http://www.example.com/product_selection/shoesandsocks/index.html
  • http://www.example.com/product_selection/hats/space_helmet/?product_id=1234

Evaluates false for:

  • http://www.example.com/product_selection/pantaloons

Operators#

AND#

The AND operator is used to join multiple targeting rules so that you can isolate a page. Conditions using AND evaluate as true when all of the values are met.

Example#

To target customers visiting your /product_selection page while they're on a particular domain, create two rules joined by the AND operator.

ComponentConditionValue
URLcontains/product_selection

AND

ComponentConditionValue
URLequalsstore.example.com

OR#

The OR operator is used within the values field of individual rules. Rules using the OR operator evaluate as true when any of the values are met.

OR is useful for targeting one kind of page with multiple URL configurations. You can use OR by adding additional values in a URL targeting rule. When targeting URLs, OR is automatically appended to your first URL after pressing the Enter or Return key. Type additional URLs to continue building rules with the OR operator.

Example#

To target a store page that has two different URLs, create a rule with two URLS in the value field. OR is automatically added after you press the Enter or Return key.

ComponentConditionValue
URLstarts withhttp://store.example.com/product_selection OR
http://www.example.com/store/product_selection
Was this article helpful?