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:
- Type: web, mobileapp, atm, kiosk, tvcd, service, etc.
- Property: page URL or app bundle
- Container: location on the page/app activity
The tables below list some surface URI definition examples for various devices.
Web and mobile
Type | URI | Description |
---|---|---|
Web | web://domain.com/path/page.html#element | Represents 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 app | mobileapp://com.vendor.bundle/activity#element | Represents a specific element within a native app activity, such as a button or other view element. |
Android app | mobileapp://com.vendor.bundle/#element | Represents a specific element within a native app. |
Other device types
Type | URI | Description |
---|---|---|
Desktop | desktop://com.vendor.bundle/#element | Represents a specific element within an application, such as a button, menu, hero banner, etc. |
TV app | tvcd://com.vendor.bundle/#element | Represents a specific element within a smart TV or TV connected device app - bundle ID. |
Service | service://servicename/#element | Represents a server-side process or other manual entity. |
Kiosk | kiosk://location/screen#element | Example of potential additional surface types that can be added easily. |
ATM | atm://location/screen#element | Example of potential additional surface types that can be added easily. |
Wildcard surfaces
Type | URI | Description |
---|---|---|
Wildcard web | wildcard:web://domain.com/*#element | Wildcard surface - represents an individual element in each of the pages under a specific domain. |
Wildcard web | wildcard:web://*domain.com/*#element | Wildcard 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:
- Based on the Adobe Experience Platform Web SDK for your websites, or on the Adobe Experience Platform Mobile SDK for you mobile apps;
- Server-side or hybrid using AEP Edge Network Server APIs.
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
Journey Optimizer
- Journey Optimizer documentation
- What’s new?
- Get started
- Journeys
- Campaigns
- Conflict management & prioritization
- Test & approve
- Communication channels
- Content management
- Audiences, profiles & identity
- Reporting
- Decision capabilities
- Data management
- Channel configuration
- Journey configuration
- Connect your systems and environments
- Access control
- Privacy