How to Choose the Right Approach When Creating Adobe Target Offers
If you have both Adobe Experience Manager (AEM) and Adobe Target licenses, you have a few options of where and how you can create offers.
In my previous blog posts, I discussed how to integrate AEM with Target, both for AEM 6.4 and AEM 6.5. Now the question is when to leverage the integration and when does it make sense to use the Target interface instead.
Targeting Approaches
Before attempting to answer that question, I want to discuss the differences between the three approaches.
Approach One: Target UI-Only
The most obvious approach is to leverage the plain old Target interface for all your targeting and personalization needs. With it, you’ll have the full suite of Adobe Target features at your disposal. Most commonly for websites, you’re going to use the Visual Experience Composer (VEC) to create your experiences. This method works regardless of which content management system (CMS) you use as long as you can include the Target JavaScript code (i.e. at.js) on your site.
The way it works at a high level is that you include the Target script on your site—usually with a tag manager like Adobe Launch. The script then runs and determines which audience(s) the user is part of. Once that’s identified, and the page the user is on has a targeted experience (or "offer"), the HTML of the offer is injected into the DOM. If you’re interested, you can read more about how Adobe Target works in Adobe's documentation.
Targeting elements with Adobe Target’s Visual Experience Composer (VEC).
In addition to the VEC tool, you can also choose Target’s form-based composer that can handle some advanced use cases for which the visual composer does not work. For example, creating experiences and offers for delivery in emails, kiosks, and voice assistants. If you want to learn more, please check out the Adobe docs.
Approach Two: AEM UI-Only
The AEM UI-only approach makes use of Adobe Target purely via the API. It’s the integration that’s available starting with AEM 6.4 that I’ve talked about in detail in previous blog posts. This setup allows your content authors to stay within the AEM interface. They create content as they normally would and if they want to personalize a component or create a simple A/B test, they can do so through the same interface that they’re already used to.
The AEM-Target integration does have some limitations. For example, the only two activity types available right now are Experience Targeting and A/B Tests (only simple/manual ones, not ones with Auto-Allocate or Auto-Target). That means, if you want to use any of the more advanced features like Automated Personalization, Multivariate Tests, or Recommendations, you’re not going to be able to do this within the AEM interface.
You also can not target elements that are fixed within an AEM template, for example, components like the header and footer. More generally speaking, you can only target elements that your content authors can edit/move/delete on pages.
Here’s how the AEM-Target integration works technically: As with the first approach, the Target at.js script is loaded on the end-user facing site to determine the user’s audience(s). The difference lies in how the offers are injected onto the page. Instead of returning the full HTML of the offer, Target returns a snippet of JavaScript which points to the offer location in AEM:
<script type='text/javascript'>
(function() { CQ_Analytics.TestTarget.pull('/content/campaigns/brand-name/master/regionalized-content/california/news.tandt.html','e206cb5e-d5d9-4213-a317-4ea4aa299f71','1.0.0');
})();
</script>The CQ_Analytics.TestTarget.pull() function call then makes another Ajax GET request to retrieve the offer HTML. While the HTML can be fully cached on the Dispatcher, you may still see some more latency than you do with the pure Target approach described above.
On the AEM Author side, the way the integration works is this: If you have the cloud configuration set with the "Synchronize segments from Adobe Target" option checked, there is a regular sync happening which pulls down segments/audiences to AEM from the Target API. This then allows your authors to select the audiences and create offers for them.
You can also create audiences yourself from within AEM but usually, you would want to have them centrally managed in just one system. When the offers—grouped together in an "activity"—have been created in AEM, the authors need to publish it to Target. This again is handled by a call to the Target API.
AEM’s Targeting interface.
Approach Three: Hybrid AEM and Target
Last but not least, there’s a hybrid approach of the two methods above. This requires the AEM Target integration to be configured just like in the second approach. The only difference in the setup is that we don’t need to enable the "Synchronize segments from Adobe Target" feature since we won’t be matching up audiences to offers on the AEM side.
The general idea with this approach is that your content authors create Experience Fragments for those parts of the site that they want personalized. For example, if you have a page hero that you want to target, you would create an Experience Fragment for it and add your hero component to it. You can then create additional Experience Fragments or Experience Fragment Variations for your different audiences.
On the technical side, the way it works is as follows: once the Experience Fragments have been created, your authors can select them and click on the "Export to Adobe Target" button from the toolbar. This grabs the fully rendered HTML and pushes it to Target via the API. Included in the HTML are any clientlibs that you have loaded on the Experience Fragment template. Also, links and references to images are externalized with your site’s domain. That is part one of the "hybrid" approach.
AEM’s UI to export Experience Fragments to Adobe Target.
For part two, you need to switch to the Adobe Target interface because now you actually want to make use of the Experience Fragments which you have exported. You should be able to see them in the "Offers" view in Target. You can then use the VEC tool just like in the first approach, but instead of modifying elements on the page directly, you chose the option of "Replace with Experience Fragment." The end-user shouldn’t notice any difference between the first and third approach because, in both scenarios, Adobe Target simply replaces an element in the DOM with static HTML.
Using the VEC tool in Adobe Target to replace an element with an Experience Fragment.
Choosing an Approach
Based on the descriptions above, you may already have a better understanding of which approach to use, but as you can see, there are a few factors that go into deciding on an architecture.
There are some key questions to answer to lead you down the right path:
- What version of AEM are you using?
- What kind of targeting do you want to do?
- Which aspects of the site are you trying to target?
- Is the content you want to target reusable across pages or channels?
The following decision tree can help guide you to the best approach for your use case:
I realize this can seem overwhelming so let’s look at a few examples to illustrate it.
Example One: Targeted Hero Banner on a Landing Page
Scenario: You’re on an AEM 6.4.2 instance and you would like to target a homepage hero so that visitors from California see a different hero experience than visitors from the rest of the U.S. The hero component is authored with a title, intro text, an image, and a CTA link. The hero component is part of the "Initial Content" in the Editable Template.
Let’s step down the decision tree:
1. What version of AEM are you using? 6.4.2, e.g. fulfills the requirement of 6.4+
2. What kind of targeting do you want to do? Experience Targeting
3. What aspects of the site are you planning to personalize? A hero component that doesn’t have dynamic content and which is editable on every page (i.e. not part of the template structure).
At this point, all three approaches outlined above would work for you. It comes down to your preference of which interface you’d like the team to use: AEM or Target, or both. You can also ask yourself "Is the hero reusable across pages or channels?" Because if it is, it probably makes sense to create a single Experience Fragment for it and then reuse it wherever you need it.
Example Two: Regionalized News Feed
Scenario: You’re on an AEM 6.5 instance and you would like to run a test to see if you’re getting more click-throughs on a news feed component when visitors see news reports from their region (e.g. tagged with their region tag in AEM, such as "California"), compared to everyone else seeing all content regardless of which tags are applied.
Let’s step down the decision tree:
1. What version of AEM are you using? 6.5, e.g. greater than 6.4
2. What kind of targeting do you want to do? Simple manual A/B Test
3. What aspects of the site are you planning to personalize? A news feed is usually built pretty dynamically, for example by running queries in AEM that find pages tagged with certain tags. It’s also likely to change often because as new pages are created and published with the relevant tags, you want them to show up in the feed without having to re-author the news feed itself.
All these are indicators that the AEM-Target integration might be a good fit. Because, if you were to push the component as an Experience Fragment to Target, Target would only be aware of the component state as it was when it was pushed and would not include subsequent, dynamic news feed updates.
Likewise, if you’re purely using the Target interface, how would Target know what the California-specific news articles are? With the AEM-Target integration, the offer resource would run the JCR query and pull in the latest content as long as the offer HTML is not already cached on the Dispatcher.
Example Three: Testing CTA Button Texts
Scenario: You’re on an AEM 6.5 instance and you would like to find out as quickly as possible which CTA button text leads to the most lead generation forms to be submitted. Also, Target should show the winning experience more often so that you immediately benefit from the test.
Let’s step down the decision tree:
1. What version of AEM are you using? 6.5, i.e. greater than 6.4
2. What kind of targeting do you want to do? A/B Test leveraging Auto-Allocate
3. What aspects of the site are you planning to personalize? Testing a button text, in general, could have been done with the AEM-Target integration. However, since it doesn’t currently support the Auto-Allocate feature we’re looking for here, we have to choose a different approach.
For this scenario, you have to decide between using purely Target or using the hybrid approach of managing the button in an Experience Fragment and then exporting it to Target. As before, it comes down to your preference of which interface you’d like the team to use. For "atomic" components like buttons, which can often be found across a site, it may make sense to create an Experience Fragment for it and then reuse it wherever you need it.
A Note About Experience Fragments
In the graph above, I make the distinction between re-usable and single-use content to determine if you should go the route of creating Experience Fragments and pushing them up to Target. This is not a hard requirement.
You can use this approach even if the XF is only used for that purpose and only used in a single place. In fact, it may speed up the performance of your site because replacing a DOM element with HTML that’s already in Target is faster than requiring another GET request to get the offer HTML from AEM after Target has made the decision what the user should see.
As you can tell, you’ll have to weigh the pros and cons here. If your main focus is to get everything managed through the AEM interface, you may be OK with slightly slower performance on your site. If not, you may have to go with the hybrid approach of authoring Experience Fragments in AEM and then assigning them to audiences in the VEC tool.
Find the Right Direction
As you can see, you have many options for where and how you can create offers. There’s no right or wrong way, but based on some criteria, you may find some solutions work better than others.
The decision tree above can’t cover every edge case and intricacy, but I hope that it can help lead you in the right direction or at least provide you food for thought for when you want to tackle your next targeting project.
