How to make a pure ACDL/EDDL implementation scalable given the current limitations in AA

[sorenhoyer]

Hi

Last month I posted this question: https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/acdl-and-the-quot-compone... 
which unfortunately did not receive any answers yet.

To try and answer this myself I started doing some research about the limitations at first.

https://helpx.adobe.com/legal/product-descriptions/adobe-analytics.html

https://experienceleague.adobe.com/docs/analytics/technotes/low-traffic.html?lang=en#how-low-traffic...

Most importantly:

• 250 evars
• 1000 success events
• 500000 unique values per evar

I'm having a real hard time to take a fundamental decision on how to approach this given the above 3 limitations.

We've chosen to go with the Event Driven Data Layer way, using the ACDL extension for Adobe Launch. More exactly this solution https://webanalyticsfordevelopers.com/2020/11/17/lean-analytics-with-acdl/ 

At first I felt inspired by this tutorial series https://experienceleague.adobe.com/docs/experience-manager-learn/sites/integrations/analytics/track-... but in the tutorial, a condition is used to map component id to someType id based on the component resource type so there I divert. I just want to map it directly to

• evar1=componentId
• evar2=componentTitle
• evar3=componentResourceType
• event1=componentClicked
• event2=componentShowed
• event3=componentHid

(what I was asking for feedback / thoughts / advice about in my previous question https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/acdl-and-the-quot-compone...)

By doing it that way I would not spend a large part of my 250 evars on mapping each of the below eventInfo properties to their own eVar and similar events per type

• buttonId
• buttonTitle
• Button Clicked (event)
• tabId
• tabTitle
• Tab Clicked (event)
• tabPanelId
• tabPanelTitle
• Tab Panel Showed (event)
• Tab Panel Hid (event)
• listItemId,
• listItemTitle
• List Item Clicked (event)
• accordions, forms, hover/touch events etc... imagine how quickly you will run out of eVars and events (evars before events probably, but still).

We need to track a lot of (not just talking a few cta clicks) clicks and other user interaction events all over the UI, so I'm concerned how this will scale and can forsee how we will quickly run out of eVars if we follow that approach.

Which is why I thought it would work well to not use evars for each concrete type of component/element (button, tab, listitem, accordion etc) but breakdown the componentId dimension by another dimension / evar, component resource type. But then, if all components we track is mapped to evar1=componentId we might run into a scalability issue with the 500000 unique evar values and low traffic limitation.

So as I see it for AA to scale well with a pure EDDL based setup, we need A LOT more evars and events at our disposal, or we need that max unique evar limitation to be lifted? Is this just how it is for now, since evars / success events and the Adobe Analytics architecture was not built to support EDDL which is a somewhat new approach to tracking? Are there plans to support EDDL better (what can we expect and a rough ETA, so we might start today, in hopes it will scale when new features / limitations come later this year perhaps) or what am I missing?

[ch_ashish]

I don't think it's possible to get more eVars but it would be worth connecting with your Adobe Account manager and discussing the max eVar unique values.

https://experienceleague.adobe.com/docs/analytics/technotes/low-traffic.html?lang=en#changing-unique... 

[yuhuisg · Accepted solution]

Strictly speaking, this isn't a problem with ACDL/EDDL/data layers in general. Data layers serve to act as a "middleman" between your website and your analytics, so that you can track and report data that the website doesn't normally expose. How the data layer's values ultimately get tracked to your analytics is entirely up to you.

Instead, the issue is with your AA setup. I understand that you need to track a lot of data points. So think about it this way:

• Do you really need to track all those things that you've listed? What business questions are you hoping to answer with them? Based on that review, could some of those things be dropped from tracking then?
• Does each data point really need to be tracked to its own eVar? Could there instead be a "general purpose" eVar that can accept multiple values, yet can return a desired report when paired with the appropriate success event or other metric?
• Could you instead take advantage of Classifications? E.g. componentId / componentTitle / componentResourceType, etc sounds like something where you could track componentId to an eVar, then classify that to the other component fields.

Those are some of my suggestions and you don't need to answer them here.

[sorenhoyer]

Of course I have challenged our marketers, business etc. about whether they really need to track close to all (not all, but still a lot) elements that a user can interact with, or if we could just make a heatmap and a nice little Business Requirements Document with the most important high level things to track.

As a developer I'd prefer that as well, but apparently this extensive insights is unfortunately needed as they want to use analytics as the tool for the UX team to learn and understand how users are interacting with the UI as a whole, and down to each of the small components so they can optimize user experience based on how the users are actually using the UI and not only answers from a survey. Eg. do the users click on the close button in the top right corner of the modal, or do they click outside, hit escape or the CTA button same with the datepicker, comparison of data points in charts etc. It's quite a lot of data they're in need of.

So most (not all, but still a lot) components will be tracked, all buttons, links, tabs, forms, etc.

Regarding bullet 2, In my previous post which I also linked to in this post, I had that same thought and did ask for feedback on that approach until it became clear it would not scale well given the current limitations regarding max. unique values per eVar.

I guess the same can be said about your 3rd point regarding use of classifications - if you combine multiple values and classify, you will have an even bigger problem with unique values per eVar.

However, the conclusion I've come to so far, includes having a dedicated eVar for each type of component eg. evar1=link and then both linkLabel, linkURL and possibly a few others can be combined and classified, which would save 1 or 2 eVars per type which is hopefully enough until these limitations will be increased or lifted.

So while I appreciate your comment, I really can't see how any of this will help solve my problems.

[yuhuisg]

Then maybe AA isn't the correct reporting tool for your use case. There could be better reporting tools for UX analysis (though I'm unfamiliar with them).

[jantzen_b]

Do any of the answers below answer your initial question? If so, can you select one of them as the correct answer? If none of the answers already provided answer your question, can you provide additional information to better help the community solve your question?