Setting to make eVars & props behave like context data variables

[#1]

Issue:

I'm sure there are many companies like ours that have a old style "non-TMS" implementations where props and eVars are hard coded into pages.  Where this is the case it can be difficult to change/reclaim props and eVars that have been implemented particularly if access to the relevant IT function is difficult to obtain.

Idea:

I would like to have a setting in the admin settings that allows me to make break the link between what is coded in the page and what ends up in the analytics database.

i.e. a setting that makes props and eVars act in the same way as context data variables; requiring a processing rule to map the variable in the incoming metrics call to the variable in the backend database.

I think this would massively increase the flexibility for those of us stuck with difficult to manage implementations.

[#2]

Does Processing Rules today give you the functionality you need? If not, why not?

[#3]

Hi Vicky,

The crux of the problem is that it is not current possible to prevent an eVar value being set using processing rules.

The reason for this is related to the persistence of the eVar values...

If I want use a processing rule to prevent an eVar value from being recorded  the only option is to set the eVar to a blank value. However, this prevents the persistence of any value previously set in the eVar.

I want to be able to completely ignore the incoming eVar value rather than replacing it with a blank value.

Hope this makes sense?

Andy

[#4]

Thanks for the detail, Andy. Can you shed some light on why you're tryingn to prevent the eVar value from being recorded? What's the specific situation that makes you want to block an eVar value from being recorded?

[#5]

Having had Adobe Analytic for a number of years we find ourselves in a situation where we are close to using all of our 75 eVars.

Many of the eVars are collecting data that we no longer require and we would like to repurpose these eVars.

We can't repurpose the eVars unless we can stop the current values that are being sent to the eVar.

We don't have a Tag Management System which means we are currently reliant on our IT department to remove the code that is setting the eVars.

IT are very slow moving and are a difficult resource to get hold of.  Therefore a processing rule solution that would allow us to block an eVar value from being recorded would be incredibly useful.

[#6]

Hi Andrew, when repurposing an eVar, Adobe recommends using the reset function on the Conversion Variables page in the Admin Console (see this documentation). Given this functionality, do you think the following steps would work?

1. Create a rule to delete the value of the eVar.
2. Reset the eVar in the Admin console to prevent any existing values from persisting.
3. Use context data for the new values you want in the eVar and create a procesing rule that executes after the rule mentioned in #1 that populates the eVar with the value of this context data.

This way only new values will show up in that eVar report.

[#7]

Hi Bret,

Assuming you are referring to using the existing functionality, this unfortunately doesn't solve the issue.

As you say this would result in only the new values showing up in the report. However the key point here is that the persistance of those new values would be affected by the processing rule set up in step 1.

With the existing processing rule functionality you cannot set up a rule to ignore an incoming eVar value, only replace it with a blank value.  Setting blank values will affect the persistency of the eVar including the new values.

Does this make sense?

Kind regards,

Andy