Delete data in Adobe Analytics

Hi warrensander,

Thanks for your comment. Please know that I do not want the delte capability to delte data and then repurpose the variable. I need it to delete "wrong" data that was flowing in because of bugs in the programming. If I was a single analyst I simply could setup segments or filters to get rid of that bad data spikes, but I am not and ADobe Analytics has no way of introducing forced segments.

I understand you are hesitant to delete data - too easy to also delete unwanted data - but I see no other way. Unfortunately your correction method is not working either as I would have bad data spike on one day and another bad data spike the other. In total they would cancel each other out, but the individual days would both be wrong and would cause all kinds of questions when looking at the carts.

A feature like this needs to be treatet with care - admin only, logs of what has been done - but I think it is needed.

as for re-purposing the variable besides the fact that Adobe has taken eVars from 75 to 100 in the past couple of years and you can go to 250 with any of the premium solutions sometimes it's good the re-use a variable of value.

One way we have found is first to make sure the variable is not used for some period of time. (we like to use a fiscal year plus 1 month so we can do year over year reports eventually)

Make sure you allocate a prop to contain your S_code version which should include the Adobe version and your own local edit version using dates, release numbers etc) so you can have a version number where this new variable’s purpose starts (and make sure to do major/minor release numbers etc so you can make sure you know all the s_code versions where this variable has the re-purposed value).

In the admin console make sure to check the ‘reset’ box and select ‘reset’ in the dropdown when you re-define that will have the back-end delete all the current values for that eVar for all customer ID’s. [you don’t have this option for props because they have no context and expire on the next page-view]

Then you have a bunch of choices. You can create a segment that will include all data for when the evar had the old name/value and one for the new name/value and you can create virtual report suites for the old usage and the new usage (which lets you close that “don’t use this eVar for a year window”).

Also you can create a processing rule that if some old crufty version of your s_code got pulled into someone’s cache or copied and is loaded directly from a local storage rather than your master copy if you can identify what is valid data for that eVar going forward and if the data coming in doesn’t match what it should be then you can delete the value in the current server call since that isn’t the type of data you want.

Also with 1000 events you can probably spare a couple to fire when this happens (ie old/bad data for the evar appears, fire an event in a processing rule and delete the value of the evar (or copy it to some debug eVar) and then you can go back and attempt to find where the old information is coming from pulling url’s, s_code versions etc.

I do think attempting to actually delete information good or bad is not a practice that 99% of analytics experts should get involved with. Do you do anything with “Data Sources”? They do give you some limited ability to upload data (or change existing data). So the best example is that if you have a purchaseID and saw revenue come in but the purchase was returned and you gave a refund. Say the purchase was $100.00. You can use data sources to take that unique purchaseID and change revenue to -100.00 to zero it out. Or add a new event called ‘refunds’ and give it a value of $100.00. Then in your reports you can show revenue, returns and a calculated metric with revenue-returns to get adjusted revenue.

Adam Greco has a number of  these examples in his book and blog entries. These sorts of examples aside it’s not the easiest thing to setup and get correct.

Obviously asking Adobe to clear out all data in eVar23, eVar27, Prop14, Event15 and Event27 before 7/1/2016 would be interesting capability I think the workarounds using calendars, segments, processing rules, virtual report suites etc are a lot easier to implement and understand and the last thing you want after working for some time to get Adobe to delete a bunch of values for a variable is to then have someone come back and say ‘Hey, we really need that pre-2016 data for eVar27’

Thanks for submitting this idea, @Creativebyte, and for commenting, @AndyW. I can absolutely see how this could be a problem. I'm hopeful that we can solve this in the future. In the mean time, we'll keep an eye on this idea for votes and comments. 

cc: @tpaulsen_PM @mfreestone

This is big problem for our business.

Both for the reasons already mentioned and also in the case where we want to repurpose a variable

If we repupose a variable and it still contains data relating to the old purpose it's very confusing for users and can lead to issues.

Around 40% of our variables are currently tied up containing data that we no longer require and we are waiting to repurpose.