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!
Topics help categorize Community content and increase your ability to discover relevant content.
@aravfshadow144 - There are various reasons, but I'd wager that these are the most common/relevant:
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_ +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!
"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."
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.)