Expand my Community achievements bar.

Join us January 15th for an AMA with Champion Achaia Walton, who will be talking about her article on Event-Based Reporting and Measuring Content Groups!

ACDL and the "component" property with fewer evars/props/events than in the docs

Avatar

Level 2

I'm in the process of implementing a datalayer similar to what AEM components (but without using AEM) are using, but the component property. After reading the documentation I got a little confused why in this tutorial https://experienceleague.adobe.com/docs/experience-manager-learn/sites/integrations/analytics/create... they're using "Button Id" instead of just sending "Component Id" to evar 8 without the condition where they filter out on "Component Type" button/cta button.

So you'd have eg.

  • component id (map to evar1)
  • component title (map to evar2)
  • component resource type (map to evar3)

And for success events you could have:

  • Page Viewed (event1)
  • Component Clicked (event2)
  • Component Showed (event3)
  • Component Hid (event4)

Notice a single event for all clicks, instead of specific events such as CTA Click

Then in reports

Instead of

[Page Name]**CTA Click**
Some page40
  [Button Id]40
  button-buy-now10

Couldn't you just do this

[Page Name]**Component Clicked**
Some page100
  [Component Resource Type]100
  Button50
    [Component ID]40
    button-buy-now10

 

or alternatively make an inline segment

Button▼ 

Component Resource Type inline segment dropdown

 
[Page Name]**Component Clicked**
Some page40
  [Component Id]40
  button-buy-now10

Couldn't you just do this?

 

( dimensions in [] and metrics in ** )

Of course I can see that the Button Id (evar) + CTA Click (success event) metric is a bit shorter, but since we're encouraged to use a single report suite for many projects, I think it could potentially become a scalability issue, if we don't try to keep the evar/prop/events to a minimum, due to the very limited amount of evars, props and success events for the whole report suite.

Using a single evar for all component ids and breaking it down like I just showed is a bit more verbose, but you also only need 3 evars - 1 for component id, component title and component resource type.. And the you're not limited to only component type "button" or "CTA Button", but can use it for Tabs, Accordions....everything.

I might be missing some important reasonings / details which is why I'm asking these questions. Is it better to set up more rules, using conditions to filter per type and map to different evars per rule or does it make sense what I'm suggesting?

 

Edit:

I just found out about the "product limitations" and "low traffic" and that evars can only store about 500000 unique values per 30 days.

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...


I guess that could easily become a problem (at least for the component id) if you go with component id, component title and component resource type (3 evars) instead of many eg: button id, button title, tab id, tab title, list item id, list item title etc. So what is best? Is Adobe Analytics going to be become better at supporting the event driven way of tracking? In that case we need to lift either the number of evars (250 will not go a long way when you use it for all tracked components) and events or alternatively we could use the component id approach if the 500000 unique max values are lifted?

 

What to choose?

0 Replies