Solved

Why we are using D=v while assigning eVars & props? What is the purpose of it?

3 replies
2067 views
Translate All

Hi Guys,

I want to know the purpose of why we are using "D=v" while assigning eVars & props.

What may happen if we don't use this?

Your answers appreciated!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Brian_Johnson_Accepted solution

Level 8

@aravfshadow144 - There are various reasons, but I'd wager that these are the most common/relevant:

Reduce or eliminate duplication in the analytics call - Using dynamic variables cleans up the request, making it easier to do a quick, visual check as the data is captured.
Limit the character length of the analytics request - Older browsers (IE9, for example), had a limitation of 2048 characters. Anything beyond that length would be truncated, potentially causing issues with data collection. (This could be a real issue when capturing URLs and referrers in additional custom variables. So, rather than passing c1='https://.............' to store the current URL in a prop, simply passing c1='D=g' was the way to go.)
Ensure consistency - Due to timing, JS errors, or any number of other issues, populating variables with an explicit value can sometimes run into issues. With dynamic variables, you can ensure the logic runs once and that all custom variables (props/eVars) are populated correctly.

Are dynamic variables required? Certainly not. Helpful? I'd argue that they are. But, then again, I still have a fondness for working directly with the AppMeasurement library.

Brian_Johnson_Accepted solution

Level 8

@aravfshadow144 - There are various reasons, but I'd wager that these are the most common/relevant:

Reduce or eliminate duplication in the analytics call - Using dynamic variables cleans up the request, making it easier to do a quick, visual check as the data is captured.
Limit the character length of the analytics request - Older browsers (IE9, for example), had a limitation of 2048 characters. Anything beyond that length would be truncated, potentially causing issues with data collection. (This could be a real issue when capturing URLs and referrers in additional custom variables. So, rather than passing c1='https://.............' to store the current URL in a prop, simply passing c1='D=g' was the way to go.)
Ensure consistency - Due to timing, JS errors, or any number of other issues, populating variables with an explicit value can sometimes run into issues. With dynamic variables, you can ensure the logic runs once and that all custom variables (props/eVars) are populated correctly.

Are dynamic variables required? Certainly not. Helpful? I'd argue that they are. But, then again, I still have a fondness for working directly with the AppMeasurement library.

Translate

pradeep_nextrow

Level 4

@brian_johnson_ +1 for your comments. @aravfshadow144 I have used dynamic variables especially when copying values like url, header info like user agent in a prop/evar & primarily for keeping the length of the call short. But with recent times this is has become kind of obsolete, especially 2 features. 1. POST calls (if the call length is more, then AppMesurement library switches to POST rather than GET where URL length would be an issue). 2. Processing rules where you can copy hit parameters without the need for a code/library push. I have also used dynamic variables for concatenation, which again Processing rules support that now. One edge in using dynamic variables is, you can see the variables where data is copied in your network calls. In processing rules this is not possible. Hope it was helpful!

Translate

Brian_Johnson_

Level 8

"One edge in using dynamic variables is, you can see the variables where data is copied in your network calls. In processing rules this is not possible."

Exactly.

I spend much of my days implementing analytics and marketing solutions, and the ability to see exactly what is being passed/collected as the request comes off the page (or out of the app) is very important to me. It simplifies and strengthens QA and data validation processes and gives a peace of mind that I'll never have with Processing Rules. (This is just personal opinion, but I firmly believe Processing Rules should only be used where absolutely needed and/or as temporary fixes until a more permanent solution can be applied.)

Translate

Sign up

Login with SSO

Login to the community

Login with SSO