Should we consider DOM ready variables to look for data analysis along with custom events

[JyotiSharmaV]

Hello Dear Community,

I have a click-based success event that triggers when somebody clicks on the cookie acceptance button on my website. Same time, We do have DOM-ready eVars that capture various digital data for us to understand the customer journey with every page load. One of the eVar is using our 3rd party extension to identify the most engaged website visitors. 

Keeping these scenarios in mind, I want to confirm if it is the right practice if I try to pull a click-based success event against DOM-ready eVar for understanding who are those people who clicked on my cookie acceptance button. Or should I map separate new eVars in the same click event rule to capture my most engaged web visitors? 

I do understand that 2nd option is more correct but then why my DOM-ready eVar is also showing me results of engaged visitors against the click event when I am pulling it in the freedom table 

[Hemang35]

Hi,

Your observation is correct that the second option would be the best practice for capturing the engaged visitors who clicked on the cookie acceptance button. This is because the DOM-ready eVar and the click-based success event have different scopes and are triggered at different moments in the user journey.

However, if you're seeing results in your freeform table with the DOM-ready eVar against the click event, it's likely because the eVar has a persistent value. eVars, by default, have a persistence or expiration setting, which means that their values are carried over across multiple hits (including events) until they expire or are overwritten by a new value.

So, when a user clicks on the cookie acceptance button and triggers the click-based success event, the eVar value set earlier on DOM-ready is still associated with the user and therefore appears in your freeform table.

While this method may provide some insights, it's not the most accurate way to capture the information you're looking for. To get the most accurate results, you should create a separate eVar to capture the engaged visitors in the same click event rule. This will ensure that you're explicitly capturing the desired information for your analysis.

I hope this helps! If you have any other questions, please feel free to ask.

[Jennifer_Dungan · Accepted solution]

It really depends... like @Hemang35 said, your eVars are likely persisting...

But if the value of "engaged users" doesn't change between the DOM Ready and the click, creating a separate eVar that holds basically the same information is going to confuse people.. which one do they use in what situation... and while yes, you can label them "page view" or "click" as part of the name and description, you still need to make sure that they are Hit level expiry to keep them from having values in the wrong context.. but.. why use many eVars to do the same thing, when you can consolidate them....

I try to keep my number of eVars down... for instance... I once took over an vehicle site... they had "make", "model", "trim", "year", etc for the vehicles... but they had one set for detail pages, another set for search, etc....  I consolidated the data so that "make" was "make" regardless of the context... if they wanted to see search, we just paired with the search event, for details, paired with the details event, etc...

But your scenario sounds even simpler... you are tracking visitor engagement... which doesn't really make sense to have multiple eVars for.... 

If the engagement changes as new clicks are made... update the value to the new... if engagement is based on "visits" then it shouldn't change... just keep tracking the value....

While I can't see how that third-party content works or what it is returning... I always go for the cleanest implementation, that isn't going to result in multiple dimensions that do practically the same thing.