I have analytics questions.
1. What is the business impact if we pass redundant variables (props and evar) with page call and "other" link calls?
2. If I pass default selections (that loads when the page loads) in a list variable in the page load call, can we get clicks/click through for these values that are captured in list variables? Eg. If i pass the color, brand in a list var as they are selected by default on page loads, can I see how many times a particular color or brand type have been clicked/viewed?
Solved! Go to Solution.
Views
Replies
Total Likes
Hi,
For the first question, I am not sure what you mean by "redundant variables"....
"Redundant" means unnecessary, and if you have no need to correlate the value to your action, then you don't need to send it.... but if you are talking about sending information that you do want to correlate on your clicks / actions, then that really isn't "redundant", it's being send for a purpose so that it can be used.
if you mean:
(Note that I don't need prop2 on my click, so I didn't include it.... I would consider prop2 to be truly redundant if it were to be send, since I will never need to combine that information to the button click - and I would then also have to remember to potentially exclude it depending on what metric I am looking at)
In the case of prop, prop is a hit based (no attribution) variable... if you want to know that "button x" was clicked on your "home" page, vs your "section page", vs your "product" page.. then you need to send prop1 on your click/action so that you can correlate that value to the click.
eVars are attribution based, they can be hit based, or visit based, or.... Now, if your eVar has a hit expiry, you need to send it on the click for the same correlation context on your click... if the eVar is Visit based, technically you don't need to send it... However, keep in mind that you may get unintentional behaviours... such as, what happens if the site is slow, and the click happens before the page load? Then the value in your eVar is for the previous page rather than the correct page... this would give you incorrect information.
In my example above, I used two very simple examples, page type and url, and in my setup, I use a hit based eVar for my URLs, and make sure I send the value on all hits (pages and actions). I use eVar because it has a character count of 255 (rather than the 100 characters available for props).
What I do use Visit expiry eVars for is things that don't necessarily track on each page, but I want to correlate to something like my orders... so things like a campaign... if the page has a campaign query param, I will track it on the Page View (and NOT on any clicks on the page... I want to use the "eVar Instance" to know how many entries to my site on that campaign there were, and sending again on the actions would inflate those values)... then because the value is maintained through the visit, when an Order is made, I can correlate the campaign to the Order.
As for your second question, lists (if you are talking about actual lists and not a list enabled prop) has expiry just like an eVar... if you have an expiry that is not hit, then the values in the list will be available on your clicks (without sending them manually)... if it's a hit, they you will need to send it on the click if you want to use them.... but also note, that if you are on a page that is setting a list "colour,brand,value,type,etc" and then you go to a page that has none of that information.... all of that list info will still be associated to that page...
In this scenario, your home page is now tracking a "brand x black t-shirt that costs 9.99".... which probably is not what you want to happen....
When dealing with attribution / expiry, you really have to look at what information you are tracking, and when/where the information is sent, and what that will do to your data as users move around your site...
A campaign is essentially set once and maintained through a visit.. this is the behaviour we want...and if another campaign is using in the same visit, the new value will take over from that point on.....
However, product specific data is likely something that you only want in the context of the product, and having the last value maintain beyond the context is likely to cause issues....
Hi,
For the first question, I am not sure what you mean by "redundant variables"....
"Redundant" means unnecessary, and if you have no need to correlate the value to your action, then you don't need to send it.... but if you are talking about sending information that you do want to correlate on your clicks / actions, then that really isn't "redundant", it's being send for a purpose so that it can be used.
if you mean:
(Note that I don't need prop2 on my click, so I didn't include it.... I would consider prop2 to be truly redundant if it were to be send, since I will never need to combine that information to the button click - and I would then also have to remember to potentially exclude it depending on what metric I am looking at)
In the case of prop, prop is a hit based (no attribution) variable... if you want to know that "button x" was clicked on your "home" page, vs your "section page", vs your "product" page.. then you need to send prop1 on your click/action so that you can correlate that value to the click.
eVars are attribution based, they can be hit based, or visit based, or.... Now, if your eVar has a hit expiry, you need to send it on the click for the same correlation context on your click... if the eVar is Visit based, technically you don't need to send it... However, keep in mind that you may get unintentional behaviours... such as, what happens if the site is slow, and the click happens before the page load? Then the value in your eVar is for the previous page rather than the correct page... this would give you incorrect information.
In my example above, I used two very simple examples, page type and url, and in my setup, I use a hit based eVar for my URLs, and make sure I send the value on all hits (pages and actions). I use eVar because it has a character count of 255 (rather than the 100 characters available for props).
What I do use Visit expiry eVars for is things that don't necessarily track on each page, but I want to correlate to something like my orders... so things like a campaign... if the page has a campaign query param, I will track it on the Page View (and NOT on any clicks on the page... I want to use the "eVar Instance" to know how many entries to my site on that campaign there were, and sending again on the actions would inflate those values)... then because the value is maintained through the visit, when an Order is made, I can correlate the campaign to the Order.
As for your second question, lists (if you are talking about actual lists and not a list enabled prop) has expiry just like an eVar... if you have an expiry that is not hit, then the values in the list will be available on your clicks (without sending them manually)... if it's a hit, they you will need to send it on the click if you want to use them.... but also note, that if you are on a page that is setting a list "colour,brand,value,type,etc" and then you go to a page that has none of that information.... all of that list info will still be associated to that page...
In this scenario, your home page is now tracking a "brand x black t-shirt that costs 9.99".... which probably is not what you want to happen....
When dealing with attribution / expiry, you really have to look at what information you are tracking, and when/where the information is sent, and what that will do to your data as users move around your site...
A campaign is essentially set once and maintained through a visit.. this is the behaviour we want...and if another campaign is using in the same visit, the new value will take over from that point on.....
However, product specific data is likely something that you only want in the context of the product, and having the last value maintain beyond the context is likely to cause issues....
Thank you Jennifer.
In my first query, I am seeing variables on the page which has null values. That is why i am referring to them as redundant variables.
In the second query, I am talking about a list var (that behaves like an evar). Right now for every default selection, link call is triggered which increases the server usage. Hence, I am thinking to trigger list vars in the page load call but the business question is if they will be able to see the click throughs on the values captured within the list var. Can you clarify please if click throughs are possible to get for list variables (evars)? Thank you!
Views
Replies
Total Likes
Ah, it sounds like you are using eVars, and those eVars are set to the wrong attribution. Look at the example in my answer to your second question. Yes, I agree that if the attribution is incorrect, this would indeed be "redundant"
It sounds like you really need to set your expiry to HIT. There is a time and place for a long running attribution... like Campaigns for instance.. but the way you are using it, no, there seems to be no need for that.
eVars were originally designated as "conversion variables" where a long running attribution made sense (hence why the default setting is Visit)... and even though they can still serve that purpose, eVars can hold more information, you have more of them available, and you have control over the attribution, so many people use these more often and in place of props. Lists are essentially special eVars that allow you to pass multiple items.
Both eVars and Lists should be configured to an attribution that makes sense for the use. Before you make changes however, you should check that no one is using that attribution... and maybe test out the changes in a Dev/QA environment first.
Ok, and for the second, it would be helpful to see what you are doing... I agree that sending multiple server calls is probably bad, but I don't know what exactly you are trying to accomplish, or what your use case is....
If you are saying that when your page loads you get one PV and multiple "actions" calls (for each option), then I definitely agree that isn't good. Whether you have eVars dedicated for each attribute (colour, brand, type, etc), or use a list, the result should be similar.
You will have a page view, and when the user interacts, you will have your "click", and you can calculate a CTR.
If you do use a list, you might want to use prefixes and classifications to keep the different items separate...
So instead of:
"black,brand x,9.99,t-shirt"
you would send
"colour:black,brand:brand x,price:9.99,type:t-shirt"
Then you can create classifications for "colour", "brand", "price", and "type".
The comma will still be your list delimiter, the prefix will be used to identify which classification to apply to the value...
Using a regex like:
(colour:)(\w*)
will match the "colour:black" option, then you just need to pass the second group of the regex into your classification $2
You can create regex similar to that for each expected value.
Views
Replies
Total Likes
Do you have any documentation that shows that we can get click throughs for list vars?
Views
Replies
Total Likes
I don't have any documentation, and my list items are really just page variables (not really associated to clicks, but I do have a few items that came through on a click, so here is a simplified sample:
I have a list item, using a prefix and multiple pieces of info:
author:john smith:23423-345323-44566-43444
Basically, prefix of "author", the author name, and the author UUID
My segment is a simple:
HIT
List1 equals author:john smith:23423-345323-44566-43444
Page Views is the pages where that author is seen (i.e. their profile page, the articles they wrote, etc), the Custom Link Instances is all the clicks that also have that author tracked (basically things like "contact author" via email, or going to their linkedIn, Twitter, FB account, etc)
Then the CTR is just the clicks / pvs