Using Wildcards in Interaction Points
Using wildcards in Interaction Points provides an invaluable way of reducing the number of Interaction Points configured for individual Touchpoints and enabling the re-use of both capture instructions and optimizations across multiple pages of a Web Touchpoint.
You can specify wildcards both when creating Touchpoints (schema://host) and Interaction Points (/path?parameter).
Wildcards work slightly differently for each component. The most important difference is related to the matching of incoming URIs. At runtime, incoming URIs match first to a Touchpoint and then to Interaction Points within that Touchpoint.
Only a single Touchpoint, with the most exact match to the schema://host portion of the incoming URI is used. Other Touchpoints with lesser matches are discarded. After a single Touchpoint is identified, MXO searches that Touchpoint for 0..n matching Interaction Points to use to provide capture instructions and optimized content.
When should I consider using Wildcards in Interaction Point paths?
Consider using wildcards in Interaction Point paths if you want to:
- Re-use capture instructions and optimizations across multiple web pages without having to set up individual entries for each page. See Examples 1a and 1b.
- Capture a customer key on multiple landing pages.
- Capture a user-defined search term across multiple pages where a common element id is used.
- Re-use an optimization for an offer or promotion that is common across multiple web pages where a common element id reference is used.
- Capture values from a URL, where the path of that URL is dynamically generated based on changing content, that cannot be predicted in advance. See Example 3.
- Trigger multiple Interaction Points simultaneously from a single context, allowing you to capture and optimize across all of those Interaction Points. See Example 2.
Example 1a - Match all pages within the insurance section of a website
An insurance company can create a single Interaction Points to track customer interest across all their insurance products, using the following path:
/insurance/*
A customer can visit any page within the insurance section of a website, for example; /insurance/car or /insurance/house and MXO will track that activity using a single Interaction Point.
Example 1b - Match across multiple pages of a Product Catalog website
For organizations with extensive product catalogs, wildcard matching is very important, as it extends automated matching to work across product catalog web sites.
For example, a shirt company could track a customer’s preference for a particular type of shirt using either of the following paths:
/mens-shirts/*/*Slim-fit*
/mens-shirts/*/*Classic-fit*
The /mens-shirts/*/*Slim-fit* path would enable MXO to trigger Interaction Points for the following products:
/mens-shirts/mens-formal-shirts/blue-Slim-fit
/mens-shirts/mens-formal-shirts/blue-Slim-fit-double-cuff
/mens-shirts/mens-casual-shirts/pink-Slim-fit
Example 2 - Match against Multiple Interactions
A customer visits the following page on a hotel website, looking for information about five star hotels in the Galway area:
http://MyHotels.com/hotels/ireland/Galway/fivestar.html
The following Interaction Points have been configured in MXO :
/hotels/ireland/*
/hotels/ireland/{location}/fivestar.html
/hotels/ireland/{location}/fourstar.html
When the customer visits the Five Star Galway hotels page, both the /hotels/ireland/* and/hotels/ireland/{location}/fivestar.html will be triggered.
Example 3 - Match against a dynamically changing URL path
A football club can create a single Interaction Point to track customer interest in VIP hospitality packages, irrespective of away team, using the following path:
/hospitality-packages/*/packages/vip-package/
As an extension to this, the football club can also capture the name of the away team for which a customer is interested in purchasing VIP hospitality packages, by amending the path as follows:
/hospitality-packages/{awayteam}/packages/vip-package/
How do I create Wildcard Interaction Points?
Use the main MXO UI to create wildcard Interaction Points. The MXO Extension allows you to create and edit only exact match Interaction Points.
Example Wildcard Interaction Points
The table below outlines a list of common wildcard Interaction Points.
| Wildcard Interaction Points | Matches... | Does Not Match... | Matches When... |
|---|---|---|---|
| / | / | /car | A single slash is provided or missing. For example, site.com/ or site.com.This is not a wildcard. |
| /car | /car/car?a=b | 4x4/carb/car/4x4 | The path is an exact match with or without parameters. |
| /* | ALL | ||
| /car* | /car/car/4x4/car?a=b | /4x4 | |
| /car/* | /car/car/4x4/car/4x4?a=b | /carb/4x4 | |
| /car?custkey=* | /car?custkey=12345 /car?custkey=12345& c=d /car?c=d& custkey=12345 | /car?c=d /car?a=12345 /4x4?a=12345 | A parameter is present and has any value. This wildcard Interaction is useful for capturing customer keys as parameters, when present. |
| /car?a=b | /car?a=b /car?a=b&c=d /car?c=d&a=b | /car?c=d | A parameter is present and has an exact value. |
| /car/*/a=b | /car/car/a=b /car/van/a=b | /carb/car/a=b |
When setting up wildcard Interaction Points, be aware of the following:
- URL Fragments, for example /car#4x4, are not supported for matching purposes
- When using trailing slashes, /car/ is equivalent to /car
Example Wildcard Regular Expressions
The table below outlines a list of common regular expressions you can use when you need to perform more specific text matching.
When using regular expressions, MXO will also save the value captured by the wildcard into a Customer Attribute. This attribute can be retrieved by customers using capture points if they wish to use that data value in, for example, Eligibility Rules. Simply set up a URI/API Attribute Capture Point for your Interaction Point to capture the parameter with the same name used in the regular expression.
The syntax for each expression is as follows:
{property_name:regex_string}
| Regex | Matches... |
|---|---|
| {name:\w.*} | Any character (a-z, A-Z, 0-9_), zero to unlimited times. |
| {name:\d.*} | Any digit (0-9), zero to unlimited times. |
| The characters nh (case sensitive). | |
| {name:nh|vt} | Either the characters nh or vt (case sensitive). |
| {name:(?i)nh|vt} | Either the characters nh or vt (case insensitive). |
| {name:^nh.*} | Any word that begins with nh followed by any other characters. |
| {name:.*nh$} | Any word that ends nh. |
| {name:^(nh|vt).*ny$} | Any word that begins either with nh or vt followed by any other characters and ending with ny. |
| {name:.(nh)+.} | Any word that contain nh at least once. |
| {name:.(nh)?.} | Any word that contains nh once or does not contain nh at all.{name:[\w-]+} |
| {name:[\w-]+} | Any word that contain contains at least one character or dash. |
Order of Wildcard Matching
When a context triggers multiple Interaction Points, MXO matches those points in order from strongest to weakest match. This means any points configured for those points are processed when the Interaction Point is triggered.
For example, if the following four wildcard Interaction Points are configured for a Touchpoint:
- /*
- /car
- /car*
- /car/4x4
MXO matches those Interaction Points, from strongest to weakest, as follows:
- either /car or /car/4x4 (not both)
- /car*
- /*
For Interaction Points with no wildcard specified in the path, only a single Interaction Point with an exact match is triggered. Multiple wildcard Interaction Points, however, may be a match. For the example above, this means that although /car and /car/boo cannot be triggered at the same time, they can both be triggered individually by the wildcard Interaction Points.
What happens when there are multiple Interaction Point matches?
Depending on the configuration, MXO processes multiple Interaction Points, as follows:
I have Optimization Points on both
- All Optimization Points are processed and returned, in order, from strongest to weakest match.
- When a request matches only a single Interaction Point, an Action selected for a given Optimization Point is automatically excluded from consideration when the arbitration process runs for the other Optimization Points.
- When a request matches multiple Interaction Points, Actions are excluded on a per-Interaction Point basis. The same Action can be selected and returned to multiple Optimization Points belonging to different Interaction Points.
I have Activity Capture Points on both
- All configured Activities are tracked, in order, from strongest to weakest match.
- If using the “current activity” attribute in an eligibility expression, the value ‘Interaction.activityName’ matches to the activity specified for the Interaction Point for which the Optimization Point is configured.
