Surface identifier

A surface URI serves as a precise identifier directing to distinct user interface elements or components within an application. Basically, a surface URI is composed of multiple sections:

  1. Type: web, mobileapp, atm, kiosk, tvcd, service, etc.
  2. Property: page URL or app bundle
  3. Container: location on the page/app activity

The tables below list some surface URI definition examples for various devices.

Web and mobile

TypeURIDescription
Webweb://domain.com/path/page.html#elementRepresents an individual element within a specific page of a specific domain, where an element can be a label like in the following examples: hero_banner, top_nav, menu, footer, etc.
iOS appmobileapp://com.vendor.bundle/activity#elementRepresents a specific element within a native app activity, such as a button or other view element.
Android appmobileapp://com.vendor.bundle/#elementRepresents a specific element within a native app.

Other device types

TypeURIDescription
Desktopdesktop://com.vendor.bundle/#elementRepresents a specific element within an application, such as a button, menu, hero banner, etc.
TV apptvcd://com.vendor.bundle/#elementRepresents a specific element within a smart TV or TV connected device app - bundle ID.
Serviceservice://servicename/#elementRepresents a server-side process or other manual entity.
Kioskkiosk://location/screen#elementExample of potential additional surface types that can be added easily.
ATMatm://location/screen#elementExample of potential additional surface types that can be added easily.

Wildcard surfaces

TypeURIDescription
Wildcard webwildcard:web://domain.com/*#elementWildcard surface - represents an individual element in each of the pages under a specific domain.
Wildcard webwildcard:web://*domain.com/*#elementWildcard surface - represents an individual element in each of the pages under all domains that end with “domain.com”.

URI composition

In Journey Optimizer, the code-based experience channel supports two types of customer implementations:

NOTE
Learn more about the implementation prerequisites in this section.

Using code-based experiences, you can modify content on granular locations which are uniquely identified by Journey Optimizer using surface URIs.

These surface URIs are composed and handled depending on the implementation method:

  • Web/Mobile SDK: Your web/mobile developer needs to define these granular locations as simple strings, because the Web/Mobile SDK is capable of automatically compose the surface URI based on the current URL/app ID and the location string.

  • Edge Network APIs: The app/page developer must define full surface URIs that include the full path and location where the content will be consumed, because the full URIs are required in this type of implementation.

This is why, when creating a code-based experience channel configuration, you have two ways to specify the surface according to the selected platform:

  • For Web, iOS and Android platforms, you need to the enter the URL/app ID and a location or path to compose the surface. Learn more about configuring code-based experiences for web and mobile platforms

  • If the platform is Other, you need to enter the full surface URI, like in the examples above. Learn more about configuring code-based experiences for other platforms

Previous pageGuardrails & prerequisites
Next pageImplementation methods samples

Journey Optimizer