Why we are using D=v while assigning eVars & props? What is the purpose of it? | Community
Skip to main content
A
aravfshadow144
July 20, 2021
Solved

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

  • July 20, 2021
  • 1 reply
  • 2020 views

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.
Best answer by Brian_Johnson_

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

1 reply

Brian_Johnson_
Brian_Johnson_Accepted solution
Level 8
July 20, 2021

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

    pradeep_nextrow
    pradeep_nextrow
    Level 4
    August 18, 2021

    @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!

    Brian_Johnson_
    Brian_Johnson_
    Level 8
    August 18, 2021

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

    Terms & ConditionsAccessibility statement

    Loading footer...