Issue with Dynamic variables trying to reference previous image requests (SitCatalyst H.27)

[sarah_champerno]

So I seem to have fixed the issue by turning on Clear Vars. However, I still need an explaination for the behavior I was seeing. Here's what happened: Givens: I have a prop (we'll call it prop9) getting it's value from a data layer element (link_text). I also have an eVar (we'll call it eVar 72), which gets its value from a DIFFERENT data layer element (filter_checked) and is populated when event55 fires. Observed behavior: prop9 gets set by a click and the correct image request fires with prop9="foo". then event55 happens and the image request shows up with V72: D=C9. This is a problem because C9 is not set in this image request, only in the previous one. In reporting, this image requests will show up with V72=none. It does happen to be that link_text = filter_checked = "foo" in this case. When prop9 in the first image request is "foo", and V72 in the second image request is "bar", I do not see the problematic behavior. It seems like dynamic variables should not get set in a way that references a value from a previous image request. especially seince reporting doesn't seem to be able to deal with it. The value shows up as "none". If anyone has any insight, please let me know what may have been happening here. Thanks!

[jared_hislop]

Sarah, This was raised just recently and we have a fix in place that will be released with our next update to the SiteCatalyst template. Currently the dynamic variable setting does not take into account the variables set in s.linkTrackVars (which the SC template sets automatically). The next iteration will check to make sure the prop/eVar is set in linkTrackVars before using it as a dynamically set variable. So in this case since prop9 was not set on the link event it would not be used as D=c9.

[matthew_smith]

Hey @jared_hislop,

Is this still an open issue, or has the SiteCatalyst template been updated?

We’re running into a similar issue where dynamic variables point to previously-fired utag.link calls, resulting in _Nones_ in the SiteCatalyst reporting.

I updated to the latest template, with seemingly no change. Sarah’s fix of setting _Run clearVars_ to _Yes_ seems to work as a stopgap.

Thanks!

[jared_hislop]

Hey @matthew_smith,

It appears that some of the updates we made previously have been rolled back. I have logged a card to update the template with additional logic to keep this from happening along with a couple other updates to the dynamic data setting. 

If you'd like to remove the dynamic variable setting for the time being, please reach out to your Account Manager and we can help disable the dynamic variable compression for the time being. 

Thanks 

[matthew_smith]

Thanks, @jared_hislop,

For the benefit of my reporting, do you have a sense of the timeframe for that update? Are similar updates generally measured in days or weeks?

I’ll connect with our account manager in the meantime.

Thanks for your time!

[jared_hislop]

@matthew_smith,

The card has been moved to our up-next board. Because we already have the code for this update it could be out as soon as tomorrow or sometime next week.

Note that "None" values are common and by design in SiteCatalyst reporting. This update may not fix the None values depending on the reports you are looking at and the values that are getting passed.

[matthew_smith]

@jared_hislop

What fantastic news, thank you!

Understood, re: None values. Yes—this issue stems from a very specific report with a 1:1 event/eVar ratio, where a None truly makes no sense (and querying utag.data in DevTools confirms it’s always a value going in). But I appreciate the caveat (and confirmation of my understanding).

Thanks again for your time.