Set up Adobe Target with Platform Web SDK

Learn how to implement Adobe Target using Adobe Experience Platform Web SDK. Learn how to deliver experiences and how to pass additional parameters to Target.

Adobe Target is the Adobe Experience Cloud application that provides everything you need to tailor and personalize your customers’ experience, so you can maximize revenue on your web and mobile sites, apps, and other digital channels.

Learning objectives

At the end of this lesson, you are able to do the following with a Web SDK implementation of Target:

Prerequisites

To complete the lessons in this section, you must first:

Add flicker handling

Before starting, determine if an extra flicker handling solution is required depending on how the tag library is loaded.

Asynchronous implementation

When a tag library loads asynchronously, the page may finish rendering before Target has replaced default content with personalized content. This behavior can lead to what is known as “flicker,” where default content briefly displays before being replaced by the personalized content. If you want to avoid this flicker, Adobe recommends adding a special pre-hiding snippet immediately before the asynchronous tag embed code.

This snippet is already present on the Luma site, but let’s take a closer look to understand what this code does:

<script>
  !function(e,a,n,t){var i=e.head;if(i){
  if (a) return;
  var o=e.createElement("style");
  o.id="alloy-prehiding",o.innerText=n,i.appendChild(o),setTimeout(function(){o.parentNode&&o.parentNode.removeChild(o)},t)}}
  (document, document.location.href.indexOf("adobe_authoring_enabled") !== -1, ".personalization-container { opacity: 0 !important }", 3000);
</script>

The pre-hiding snippet creates a style tag in the head of the page with the CSS definition of your choosing. This style tag is removed when a response from Target is received, or the timeout is reached.

The pre-hiding behavior is controlled by two configurations at the very end of the snippet.

The pre-hiding snippet is also available within tags:

Synchronous implementation

Adobe recommends implementing tags asynchronously as demonstrated on the Luma site. However, if the tag library is loaded synchronously, then the pre-hiding snippet is not required. Instead, the pre-hiding style is specified in the Platform Web SDK extension settings.

The pre-hiding style for synchronous implementations can be configured as follows:

To learn more about how the Platform Web SDK can manage flicker, you can refer to the guide section: managing flicker for personalized experiences.

Configure the datastream

Target must be enabled in the datastream configuration before any Target activities can be delivered by Platform Web SDK.

To configure Target in the datastream:

Property token

Target Premium customers have the option to manage user permissions with properties. Target properties allow you to establish boundaries around where users can run Target activities. Refer to the Enterprise Permissions section of the Target documentation for details.

To setup or find property tokens, navigate to Adobe Target > Administration > Properties. The </> icon displays the implementation code. The at_property value is the property token that you would use in your datastream.

Only one property token can be specified per datastream, but property token overrides allow you to specify alternative property tokens to replace the primary property token defined in the datastream. An update to the sendEvent action is also needed to override the datastream.

Target environment ID

Environments in Target help you manage your implementation through all stages of development. This optional setting specifies which Target environment you are going to use with each datastream.

Adobe recommends setting the Target Environment ID differently for each of your development, staging, and production datastreams to keep things simple. Alternatively, you can organize your environments in the Target interface using the hosts feature.

To setup or find Environment IDs, navigate to Adobe Target > Administration > Environments.

Target third-party ID namespace

This optional setting allows you to specify which identity symbol to use for the Target Third Party ID. Target only supports profile syncing on a single identity symbol or namespace. For more information, you can refer to the Real-Time profile syncing for mbox3rdPartyId section of the Target guide.

The Identity Symbols are found in the identities list under Data Collection > Customer > Identities.

For the purposes of this tutorial using the Luma site, use the Identity Symbol lumaCrmId set up during the lesson about Identities.

Render visual personalization decisions

Visual personalization decisions refer to the experiences created in Adobe Target’s visual experience composer. First, you should understand the terminology used in the Target and tags interfaces:

Update the Send event action

Visual personalization decisions from Target are delivered by the Platform Web SDK, if Target is enabled in the datastream. However, they are not rendered automatically. You must update the Send event action to enable automatic rendering.

The render visual personalization decisions setting makes the Platform Web SDK automatically apply any modifications that were specified using the Target Visual Experience Composer or “global mbox”.

If you prefer to render or action on these decisions yourself using custom code, you can leave the Render visual personalization decisions setting disabled. Platform Web SDK is flexible and provides this capability to give you complete control. You can refer to the guide for more information about manually rendering personalized content.

Set up a Target activity with the Visual Experience Composer

Now that the basic implementation portion is complete, create an Experience Targeting (XT) activity in Target to validate that everything is working correctly. You may refer to the Target tutorial for creating Experience Targeting activities if you need assistance.

Validate with the Debugger

If you set up an activity, you should see your content rendered on the page. However, even if no activities are live, you can also look at the Send Event network call to confirm that Target is configured properly.

Set up and render a custom decision scope

Custom decision scopes (formerly known as “mboxes”) can be used to deliver HTML or JSON content in a structured fashion using the Target Form-based Experience Composer. Content delivered to one of these custom scopes is not rendered automatically by the Platform Web SDK. It can be rendered using an action in Tags.

Add a scope to the Send event action

Modify your page load rule to add a custom decision scope:

Process the response from Target

Now that you have configured the Platform Web SDK to request content for the homepage-hero scope, you must do something with the response. The Platform Web SDK tag extension provides a Send Event Complete event, which can be used to immediately trigger a new rule when a response from a Send Event action is received.

Set up a Target activity with the Form-based Experience Composer

Now that you have a rule to manually render a custom decision scope, you can create another Experience Targeting (XT) activity in Target. This time use the Form-Based Experience Composer.

Validate with the Debugger

If you activated your activity, you should see your content render on the page. However even if no activities are live, you can also look at the Send Event network call to confirm that Target is requesting content for your custom scopes.

Send parameters to Target

In this section, you will pass Target-specific data and take a closer look at how XDM data is mapped to Target parameters.

Page (mbox) parameters and XDM

All XDM fields are automatically passed to Target as page parameters or mbox parameters.

Some of these XDM fields will map to special objects in Target’s backend. For example, web.webPageDetails.URL will automatically be available to build URL-based targeting conditions or as the page.url object when creating profile scripts.

Special parameters and the data object

There are some data points that may be useful to Target that are not mapped from the XDM object. These special Target parameters include:

These parameters must be sent in the data object instead of in the xdm object. Additionally, page (or mbox) parameters can also be included in the data object.

To populate the data object, create the following data element, reusing data elements created in the Create data elements lesson:

Update the page load rule

Passing additional data for Target outside of the XDM object requires updating any applicable rules. For this example, the only modification you must make is to include the new data.content data element to the generic page load rule and product page view rule.

Splitting Personalization and Analytics requests

The data layer on the Luma site is completely defined before the tags embed code. This allows us to use a single call to both fetch personalized content (e.g. from Adobe Target) and send analytics data (e.g. to Adobe Analytics).

On many websites, however, the data layer cannot be loaded early enough or quickly enough to use a single call for both applications. In those situations, you can use two Send event actions on a single page load and use the first for personalization and the second for analytics. Breaking up the events this way allows the personalization event to fire as early as possible, while waiting for the data layer to load completely before sending the Analytics event. This is similar to many pre-Web SDK implementations, where Adobe Target would fire the target-global-mbox at the top of the page and Adobe Analytics would fire the s.t() call at the bottom of the page

To create the personalization-on-top request:

To create the analytics-on-bottom request:

Validate with the Debugger

Now that the rules are updated, you can validate if the data is being passed correctly using the Adobe Debugger.

Validate in the Target interface

Next, look in the Target interface to confirm that data was received and is available to use in audiences and activities. XDM data is automatically mapped to custom Target parameters. You can validate that XDM data was received by Target and is available by creating an audience.

Next, validate that the login state profile attribute was successfully passed.

If you have Target Premium, you can also validate that the entity data was passed correctly and the product data was written to the Recommendations product catalog.

Validate with Assurance

Additionally, you can use Assurance where appropriate to confirm Target decisioning requests are getting the correct data and that any server side transformations are occuring correctly. You can also confirm campaign and experience information is contained in the Adobe Analytics calls even when the Target decisioning and Adobe Analytics calls are sent seperately.

This confirms that the A4T information that was queued for later transmission when we made the target decisioning call was sent properly when the analytics tracking call fired later on the page.

Now that you have completed this lesson you should have a working implementation of Adobe Target using the Platform Web SDK.

Next: Set up Journey Optimizer web channel