Section Title instances is associated with wrong URL

[Devmalik23]

in our tracking on page load rule we are capturing the page URL in an eVar (v26) which has many sections on it and click of each section we are capturing "section title" in another evar (v48) in an event based rule.When I am pulling a report of Page URLs( v26) broken down with "Section Title" (v48) and pulling v48 (section tile) instances as metrics. It shows section titles which are not on that page. for example 

https://www.xyz.com/home/industries/ has these sections - Let's explore and My lab test

https://www.xyz.com/home/career/ has these sections - Connnect with expert and Talk to your HR

when I am generating a report of https://www.xyz.com/home/industries with breaking it with evar48 (section Tiitle" with "section title" instance as metrics it shows "Talk to your HR" as well as a line item. All the evars have default settings.

Any suggestion why we is this happening ? and what could be the fix?

[yuhuisg · Accepted solution]

Since your eVars have default settings, then I believe their expirations are set to "Visit". In that case, assuming that for some reason, eVar26 hasn't been set on the page yet a hit with eVar48 has been tracked, then eVar48 would be associated with the previous value of eVar26, i.e.

Visit X:

Hit 1: View "Industries" page --> eVar26 gets set.

Hit 2: View "Career" page --> eVar26 does not get set for some reason.

Hit 3: Click a link in "Connect with expert" section --> eVar48 gets set.

No more hits after that.

Then when you run a report for this visit, you will have:

eVar26 = Industries

breakdown eVar48 = Connect with expert

Like you, I hate this kind of non-sensical reports. So in such cases, I prefer to set the eVars with "Hit" expiry, then ensure that I set the values of eVars with every hit. In that way, I am very sure that my reports would make sense.

I.e. my implementation would be:

Hit 1: View "Industries" page --> eVar26 gets set.

Hit 2: View "Career" page --> eVar26 does not get set for some reason.

Hit 3: Click a link in "Connect with expert" section --> eVar26 and eVar48 get set.

Resulting report:

eVar26 = Career

breakdown eVar48 = Connect with expert

[Jennifer_Dungan]

Yes, I agree with @yuhuisg about checking your eVar expiry... generally for that type of tracking the expiry would be set to Hit (if you need it on actions, you will need to explicitly set on your actions, but it prevent data from continuing on to other pages...

The other possibility is that if you have an SPA site, it's possible that the values are being set at the wrong time (basically getting the previous page's value for either the URL or Section Title).

Have you been able to replicate the issue in testing? Or is it something you have only so far seen based on a subset of data?

[Devmalik23]

Thank you @yuhuisg and  Jennifer_Dungan

Correct , expiration of both the eVar is on "Visit" and allocation is "Most Recent (Last)"

I have checked the same on experience though missed page call (e.g Hit 2: View "Career" page --> eVar26 does not get set for some reason.) was not observed.

So you are suggesting we should expire both eVars on hit or just eVar48 which is captured on link click?

Thanking you in advance.

[Jennifer_Dungan]

My rule of thumb is, if the value is Page Specific (and does not need extended attribution), I set the expiry to "Hit" to prevent any data corruption....

You can always apply custom attribution later in Workspace if you need to look back...

But I keep actually "attribution" values (such as campaigns - external and internal, or carrying forward search results, or wall interactions, etc) as attribution ("Visit" or Expiry on a specific conversion events, etc) so that they can be correlated to our conversions... but things like URL, Page Titles, Page Sections, etc (stuff that relates to specific page values) I set to Hit level, as if something fails to set on the next page, those values don't belong there....

[yuhuisg]

Yep, I concur with @Jennifer_Dungan's recommendation about using Hit level for page-specific data.

[rohinihm9448887]

But we have a prop for the same page data. then no point in setting to hit expiry right? I have been seeing reports where even prop is showing wrong data. Example: dimension used is pageName(prop) and and custom event(e1). e1 is not set all pages but prop is showing all pages

[Jennifer_Dungan]

If you mean that you have both a Prop and an eVar tracking the same data, and therefore you don't need to configure your eVar to hit because you already have the prop... then no.

First off, replicating props and eVars with the same values was a really old methodology used before full correlation of dimensions was available, there is really no need to do this anymore... I would hold the page name in an eVar to leverage the 255 character limit (over the prop's 100 character limit). Unless you need access to the calculated "Entry" and "Exit" variants of your value, then you might want a prop... but since you already have the standard "Page" for that.. I am not sure its needed.

However, since you are making your reports using the eVar, you will need the eVar to behave in a manner that makes sense for the usage. 

However, the prop, which is always hit level is wrong... there are two potential issues...

1. There is a tracking issue

2. There is potentially a hash collision in the Adobe Data (which can happen when you have a lot of data).

I would try to correlate the incorrect data as much as possible, checking other data points that helps confirm or deny where the information is being set, or if there is a pattern to the browser or OS.... Then see if you can replicate any instance on the website where the wrong data is set....

If you can find no issues with your tracking, you could check with Client Care to see if they can see if there may be a hash collision...

[rohinihm9448887]

So its possible prop does not work at hit level always? I have checked that tracking is fine. Since there was prop for page name, I made the evar at visit level. I am thinking if that's a mistake and keep the evar at hit level. If hash collision could be the reason for prop having wrong page names where the event is not set,  shouldn't there be more unique values for prop? There are only 15-20 page names that goes in to this evar and prop.

[Jennifer_Dungan]

If you only have 15-20 pages in your site (or values collected in the dimension), you shouldn't be getting a hash collision.... that only happens when you get into millions of values.

So if you still have incorrect values on the prop (which is hit based, so there is no potential attribution concerns) then there must be a tracking issue.

Is it possible that your custom event e1 was potentially used in the past for another purpose and you have old cached pages being viewed that are setting it based on old logic? Or do you have a mobile app sending data into your suite that might be setting e1 incorrectly?

[rohinihm9448887]

That's a good point. I have reset my evars and waiting to see what happens. Can we reset Event e1 if it's repurposed? We do have mobile app sending data but it's hybrid and using the same web analytics.

[Jennifer_Dungan]

Good Luck with the eVar reset. For events, while there is no real "reset" since there is no attribution... in my own system, if I am switching the use of an event, I usually try to remove the current implementation, then wait a minimum of 3 months before reusing it... I make sure that the even has stopped tracking fully.... of course, there's always a chance that someone could pull up an old cached page, but I am less concerned with a one off... 

If you think this might be the case, you could try setting up a new event in the same context... firing both the event that seems to have incorrect pages and the new event.

Then you can compare these side by side and see if they still match, or if the new event looks better...

Let me know how this goes.