Building a personalised and highly dynamic experience with AEM

[monohusche]

HI there,

AEM is an important component in our distributed customer experience platform which is fully based on loosely coupled components (CMS, apps, 3rd party services) which are tied together by a service oriented REST API framework. In order to create a unified developer experience, we would like all of the different services (content delivery/retrieval, data retrieval) to comply with the overall REST guidelines internally defined. At the same time, we consider personalisation as one of the most important capabilities of this platform, being applicable to all the backend components (personalised content, personalised offers/promotions, personalised data).

Combining both REST as well as the need for personalisation which translates into providing input parameters from the user, the commonly accepted best practive for doing that is using query strings as part of the URI (this would cover the generic features of pagination and sorting as well).

Our content teams (being responsible for AEM) complain though that using query strings implies dynamic page generation (of course, that's the point of personalisation), and that means that these pages can't be authored/edited manually anymore which I find a little bit odd. At the same time, I am not an AEM expert and don't intend to become one, I am merely treating AEM as a blackbox adhering to a common interface to the outside world.

Hence, my question is: Is there a commonly accepted best practice for building personalised pages/content in AEM, e.g. presenting promotions based on end user geography, size of wallet, customer segment ?

PS: I am aware of the distinction between selectors (HOW to render things...html, json, xml) and query strings (WHAT to return), and I also know that previously, people advised against query strings due to being non cacheable, but I believe, this argument is void as it can be configured which parameters allow for caching and which don't (see here)

thx in advance

[Abhinav_Sap]

       Instead of using query string, you can also use url hash strings and map url hash key value pairs to segments.

[Abhinav_Sap]

        You can use query string, with the understanding that it impact cacheability of the content in question and impact of this decision on performance. Not sure if  it works for your problem, but a webserver rule can be defined which converts query string into a url hash parameter. This was you can keep the query string if is coming from another system and still leverage advantages of caching.

[monohusche]

Sorry, there seems to be a misunderstanding. 

I am not asking for an alternative to query strings, rather the opposite: I want to use query strings, but there seem to be problems with that in AEM (in terms of authors being able to edit the dynamic pages), and I wanted to know whether these problems really exist, if yes, if they can be resolved and ultimately whether there is a better way of doing it (which is aligned to REST principles).

After all, AEM is fully rest compliant, so I would expect that their URI best practices would also align with REST, given that this is such a fundamental part of REST.

[monohusche]

After some further reading up on it, it seems that using hashes in URI's are only for client use as anchors, they never go across the network. i.e. If I entered "..../products#latest", the URL going over the wire to AEM would still be ".../products". Once ALL the content comes back, the browser identifies the anchor in the html and positions the viewpoint accordingly.

So in essence, using hashes (=fragments) in URI's is not doing filtering, but it is actually returning the full content, only to be selectively displayed on the browser. Needless to say, this creates significant limitations on the amount of dynamic content (=personalisation) that can be returned as at some stage, the pages will just get too big...or the whole experience will become very slow. Of course, one would use CDN's but then we are talking about potential impacts to the realtime nature (i.e. how often do caches get updated.

The other thing that I don't understand is...by using hashes (=anchors), all content is still available in the browser. So if the user starts scrolling, he might see other content that might not be relevant/appropriate for him.

Last but not least, in regards to caching, I had a link above which explains how query string URL's can be cached. Doesn't this solve the problem ?

Nick  

[Abhinav_Sap]

Dispatcher does have directive to ignore url parameter and cache the page in question even if the incoming URL has query parameters. Now personalization in this scenario will only work if the personalization is implemented client side (teasers should work as they are executed client side.).

But if your personalization logic is server side then it wouldn't work, as the page will be served using the cache and request wont be processed by publish instance.

[Lokesh_Shivalingaiah · Accepted solution]

Hi,

It would be easy for us to guide/suggest if you have a specific usecase. However, personalization is a part of AEM and we can use segments, campaigns and teasers to achieve the same. Teasers can be authored and create some specific segments based on the URL params and run a campaign with these teasers. 

[monohusche]

But the whole point is to create an overarching framework (with AEM just being one part of the overall eco system) that ensures that all the components can talk to each other in a homogeneous fashion without being aware of what happens inside the box (AEM). So a mobile client just needs to know the URI of a service and it's structure rather than what is being inside AEM to deliver it.

It's almost like someone stipulating IP as a network protocol for all applications to interact, but one application claims that it can't do IP because of some internal constraints. My point is that I don't know enough about the internal system to verify whether this claim ("can't do IP because...") is actually correct or not.

The alternative is that all my clients have to support two protocols, one being IP for all apps except AEM and one proprietary protocol only being used by AEM.

So again, my question is not how to implement personalisation INSIDE AEM, but how to communicate input parameters into AEM. I assume, that even for the capabilities you mentioned (e.g. campaigns, teasers etc.), in order to make those relevant to the customer/consumer, you need to push information into AEM.

So what is the best practice to inject information into AEM for dynamic page generation/personalisation, and why wouldn't query strings not work ?