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








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

And why they also send the same value to prop8 and event 8.

With the ADCL way of doing it, using components, it is possible to simply map %event.message.event% to an eVar.

So you'd have eg.

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

And then instead of the rule "CTA Button" with a condition, you could just have a single rule:

  • "Component User Interaction Type" / "Component Event Type" 

which you can map directly in setVariables from %event.message.event% to an eVar4

Then in reports

Instead of

[Page Name]**CTA Click**
Some page40
  [Button Id]40

Couldn't you just do this

[Page Name]**Click**
Some page100
  [Component Resource Type]100
    [Component User Interaction Type]50
      [Component ID]40

( 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 resource type and 1 for component user interaction 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?

Accepted Solutions (0)

Answers (0)