Best Practice for Implementing Adobe Target on AEM as a Cloud Service (Consultant Perspective)

[shaikhshoeb]

I have recently started a project with a client who is on AEM

While I am comfortable with Target and Launch, I am relatively new to the AEM ecosystem. I want to ensure I am suggesting the modern "best practice" workflow to the client that allows for scalable personalization.

The Scenario:

Platform: AEM .

Site Type: Standard Multi-Page Application (MPA), not a SPA.

My Proposed Approach: I am planning to suggest a "Hybrid" model:

Implementation: Use Adobe Tags (Launch) to deploy the Target library (at.js or Web SDK) and handle the global mbox/page load rules. This keeps the implementation decoupled from AEM code releases.

Content/Offers: Use AEM Experience Fragments (XF) exported to Adobe Target for the actual content offers, allowing the marketing team to build banners in AEM and push them to Target.

My Questions:

Is this considered the current best practice? Or does AEM as a Cloud Service have a "native" way to inject Target libraries that is preferred over using Adobe Tags?

For the Experience Fragments export to work, I understand we need the IMS Configuration and Cloud Service configured in AEM. If I handle the library loading via Launch, will this conflict with the AEM Cloud Service settings?

Given that it is a short-term implementation to showcase value, would you recommend sticking with at.js (which I know well) or is it strictly required to use Web SDK for AEMaaCS integrations now?

Any advice or documents would be greatly appreciated!

Thanks in advance.

[Gokul_Agiwal · Accepted solution]

Hi @shaikhshoeb 

I'm currently working in similar setup project only few difference at my end. In my current project 

Platform: AEM .

Site Type: Standard Multi-Page Application 

Tag Manager : GTM (Google Tag Manager) - Integration with Adobe Target (at.js) 

Extensive use of XF (Experience Fragment) in Adobe target exported via AEM. 

Yes the approach you're thinking is correct. If you're working in Adobe ecosystem, deploying Adobe target library via Adobe launch (either at.js / websdk) and later used Experience Fragments (XF) for content delivery to Adobe Target is good solution and it aligns well. 

Ideally, using Adobe Launch (Adobe Tag Manager) to deploy Adobe Target (via at.js or Web SDK) is a standard approach for decoupling tracking and personalization activity from the AEM codebase. It's make easier for marketing teams to manage content and experiments without needing dev involvement. 

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/integratio... 

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/integratio... 

AEM as a Cloud Service offer both at.js and Web SDK integration with Adobe Target. 

While the at.js library is still widely used and supported, Adobe recommends moving towards Web SDK for newer implementations.

Web SDK is more integrated with Adobe’s cloud ecosystem, especially when you use Adobe Experience Platform (AEP). But at.js is still a valid choice for legacy systems or if you're using Adobe target alone. 

Will handling the library loading via Launch conflict with AEM Cloud Service settings?
No, Adobe Launch and the at.js / Web SDK integration in AEMaaCS should not conflict directly. The key consideration here is the configuration of IMS settings, which handle authentication and ensure that the AEM Cloud Service is properly connected to your Adobe Experience Cloud applications like Adobe Target.

Should you stick with at.js or use Web SDK for AEMaaCS integrations?
If this is a short-term implementation to demonstrate value and you are comfortable with at.js then go ahead as it's still a valid option and will work perfectly fine with AEMaaCS. 

However, in long run, in your project is planning to switch to AEP ( Adobe Experience Platform) then better to start with Web SDK 

Hope this info helps. 

Thank you 

Gokul