D6 Engine Documentation

Several third party solutions accomplish similar goals for companies, but the D6 Engine shines in its purpose: built specifically for AEM. This means that any company using AEM will have a cost-effective, easy-to-use segmentation solution totally embedded within their AEM editor.

Third Party Personalization

A traditional method of segmenting your audience is using third party tools or systems. Typically, these are client-side solutions where a Javascript library is installed onto the web pages, but content needs to be managed within their system, not within AEM.

Primary third party systems on the market include:

• Google Optimize
• Optimizely
• Adobe Target

Third Party Pros and Cons

There are pros and cons to consider with these other personalization options:

Pros

• Easy setup
• No additional load on your servers

Cons

• No control of load time or speed on the client’s device
• System swaps content after its been loaded
• No guarantee your users ever see the content
• Need to manage content in two places (your CMS and the third party targeting system)
• Relies on third party cookies

In highly regulated industries, companies cannot afford to swap content out to different users. You need the right content to be shown at the right time. When you swap content out, you’re informing the user that they're being targeted and that content is being personalized, which is something you may not want your end user to know.

The third party solutions listed above are generic, built for any website running any platform. They are platform agnostic and would run equally well on Sitecore, AEM or Wordpress, etc. This is fine but if you’re using AEM, you want the D6 Engine because it’s platform-specific. It’s built to leverage the features of AEM and to plugin to AEM so that it can take advantage of AEM features such as selector strings and dispatcher caching.

Traditional AEM personalization

To accomplish personalization directly in AEM, many clients depend on two main features: Server side includes (SSI)  and Apache Sling Dynamic Includes.

SSI

Server side includes is a method for your webpages to tell Apache that before providing a response to the customer, certain content needs to be re-rendered by the application server. Apache parses the HTML document, checks for SSI includes and reprocesses those requests. Your HTML content could look like something like this:

<div><!--#include virtual="/path/to/resource" --></div>

Apache Sling dynamic includes

Apache Sling dynamic includes is a tool that automatically inject SSI tags within your webpages. The components that need to be rendered per person are not provided in the initial output and instead each component on a page will require its own request. If a page has two dynamic includes then each one requires a new request, causing a tremendous increase in load to your application servers, and other drawbacks are:

• Inability to cache output
• Inability to redirect request to different paths based on the user's profile

While these tools work, SSI was not built for AEM. It's a generic concept built by Apache web server for any website. It accomplishes the known task that certain parts of a page are truly dynamic and can’t be cached (e.g. a user's first name). It doesn't solve the problem that a part of the page may have five total variations which can all be cached.