Installing Adobe Analytics on AEMaaCS

[curtis_pond]

Hi Community!

There are multiple (separate) Adobe experience orgs in my organization.

I use Adobe Analytics for a couple of our sites, and another group is standing up AEMaaCS to power content on another site. I want to capture analytics from that new AEMaaCS site. I don't have experience integrating with AEM sites but have been going through the documentation to catch up.

What I would really like to try on the AEMaaCS site is a standard approach using an embed tag and digital layer and manage as a new web property in Launch.

Any issues going that route? It looks like there are ways to connect AEMaaCS to Adobe Analytics (possibly link our accounts since we're in different experience orgs), but it seems like there are limitations with what you can collect from AEMaaCS and send back to Adobe Analytics. Is that the case, or am I missing something?

Also curious...to do a lightweight Proof of Concept, could I simply put an embed tag in AEMaaCS (without a data layer for starters) to see if I can send data back to my test Report Suite? Not sure what I can do without a data layer. I just want to test if data is getting captured from our test AEMaaCS environment or not.

Thanks for any guidance! 

[yuhuisg · Accepted solution]

Firstly, I want to be upfront by saying that I don't have much technical experience with AEM nor AEMaaCS.

Having said that, the following advice is based on working with several clients and developers that use AEM or AEMaaCS:

Don't use AEM's integrations for Analytics nor Launch.

The main reason for ignoring AEM's integrations is that you get locked into Adobe's own implementation specifications, e.g. how to set events into the data layer, keys/values that are used in the data layer, assumptions about AEM components, etc.

Unfortunately, my experience has shown that this one-size-fits-all approach doesn't really work well. For example, with internal promotions, Adobe pushes certain information about the promotion component into the data layer when the user clicks it, but then they force you to write cumbersome custom code in Adobe Launch to interact with that data. Like... why??? Why force us to use custom code in your tag manager?

The integrations also work well with the built-in AEM components, but not so with your own custom components. But your website is most likely to built with custom components, thus you lose the benefit of these integrations.

I would strongly suggest the following: build your own implementation in consultation with your developers. This means not just with planning your AA setup, but also thinking about your data layer, Launch setup, report suite configuration, etc. Yes, there's a lot of custom work needed that could be eliminated with AEM's integrations, but the long-term benefits will pay off.

Some other Analytics practitioners that I've spoken to also go with the above approach of ditching AEM's integrations in favour of a custom setup. The primary benefit is by decoupling analytics from content, you have more freedom to implement whatever needs to be reported on based on your business requirements.

In your particular case, you have the complication of different Adobe organisation IDs. If you were to use AEM's integrations, I believe you're stuck with using the organisation IDs that the licences belong to. But if you go with your own implementation, you can, for example:

• Specify your own organisation ID in the Experience Cloud ID Service extension in Adobe Launch.
• Specify your own report suite ID(s) in the Analytics extension in Adobe Launch.

So that's my $0.02. Others may have differing opinions, and I advise you to weigh the pros and cons before committing to an approach. Whatever your approach, do consider the long-term implications to your organisation, both the business side and the developer side.

[curtis_pond]

Thanks @yuhuisg for the thoughtful response. The tradeoffs you highlighted are exactly what I was looking for. In the end, we have to go with the decision that works best for our AEM implementation. The key thing you mention are custom components, which inevitably our site will use to meet the needs of our customers.  At this point, I'd rather invest the time deploying a custom implementation on the AA side rather than trying to closely couple AA and AEM. But as you say, we need to weigh the pros and cons of each, giving weight to the long-term implications to the business and development side. I'm going to mark this as the correct answer, because in the end, I don't think there is a one-size fits all approach. It depends on our comfort-level with both technologies, our roadmap, and our subscription strategy with Adobe.