No-Code Web Personalization with Complex Experiences

Demos of Adobe Target and other web personalization tools often demonstrate a business user changing the text of a button or a hero banner image without the involvement of the development team. The promise of no-code marketing enablement with reduced delivery times seems within grasp. But when teams get ahold of the tools themselves, they realize that their real-world personalization and testing scenarios are often more complex than the demos, and the promise of “no code” begins to fade.

Consider a scenario where marketing wants to test whether visitors engage more deeply with specific slides in a Hero Carousel by replacing the experience with Tabs.  Immediately the team realizes it’s not so simple to “point and click” their way to transform the experience from one complex scenario laden with JavaScript and CSS (Carousel) to another (Tabs), and so they call in the developer reinforcements to write a bunch of front-end code and content within Target. Eventually the team can run the test, but at what cost? The personalization tool has effectively become another pseudo-CMS and code deployment mechanism in their technical ecosystem, with marketing once again beholden to IT to accomplish business goals.

To give personalization power in real-world examples to the business user requires thinking about the problem space differently, leaning into separation of concern to leverage the strengths of the different tools in play.

• AEM (CMS) specializes in allowing marketers to create mature experiences (e.g. Carousels and Tabs) and manage the content within.
• Target (Personalization) specializes in choosing different experiences for different users and analyzing the impact.

To replace a Carousel (complex experience) with Tabs (another complex experience), the solution is to not make Target into a CMS or front-end development platform but rather let AEM do the heavy lifting of creating the experiences while Target simply chooses between them.

Experience creation for personalization can be reserved strictly for AEM by employing a simple “Content Variations” component that captures multiple experiences but displays only one to a given user. Authors create within the CMS the alternative experiences they wish to personalize with or test, enjoying the following benefits:

• Full experience capabilities of existing components, complex and simple
• Standard authoring interfaces, workflows, legal reviews and translation
• No dependency on IT for development

With the experiences for personalization served from AEM, a marketer in Target needs only toggle a class on the Content Variations component to choose between the experiences for a test.

By limiting Target to “selecting” rather than “implementing” the alternate experiences, the team reaps these benefits:

• No-code application of complex experiences for testing and/or personalization
• No dependency on IT for development

Real-world personalization and testing by marketers and business users is now a reality!

You might be asking “can’t we do the same with Experience Fragments synced to Target?” Using Experience Fragments to personalize with AEM and Target does provide an OOTB method to separate the concerns of the CMS and personalization engine as well as eliminate the dependency on IT for development. However, the Content Variations approach achieves additional benefits:

• In-context authoring and storage of experience variations
• Reduced integration and cognitive complexity of test implementation
• Limited risk exposure to CMS deployments and/or content updates
• Singular test application and measurement across regional/translated (i18n) pages
• Works with any personalization engine (not just Target) or CMS

If you find yourself consistently calling on the development team to implement your personalization and A/B tests, it may be time to re-think your solution.