Delete data in Adobe Analytics

warrensander, Thanks for the clarification! 

Also, I succesfully uploaded a "Generic Data Source" to overwrite a Counter Success Event. The text file I uploaded looked like this:

Date     v1: Time Stamp (Visit)     E1: Error (Always)

10/10/2016     1476115997615     -1

We identified the Success Event to be deleted via a time stamp. As a result the "negative" events cancel out the "positive" events. So when you look at the event trended, zero events appear. Thanks for your suggestion.

@Julian  -  you can request Adobe to scrub data you don't want. I've been through it a couple times with several clients. I do not recommend it unless it is super business critical, like.. accidentally sending Adobe customer passwords or cc#'s or other extremely sensitive/private info that will get your business in all kinds of legal trouble, because Adobe will charge you a ridiculously large wad of money and time for them to do it. 

Julian, no have I haven't put in an idea here to allow a processing rule to delete everything. I was sort of hoping that Adobe would by themselves when they finish processing rules so that I can get to s.products etc that they would add a 'delete this server call' option.

Then again, if they did it and didn't make me pay for the server call that would be even better. Or route the server call to a different report suite (ie move the bad data calls off to a 'bad data' report suite) to help with the debugging process.

I do think a suite of tools to allow shifting server calls  to a different report suite via processing rules, delete the entire server call via a processing rule and delete the entire server call and don't charge me for the call (would be best).

I would not have an issue if I could delete the server call and not get charged to flag adobe to contact me about why and how much I am trying to not get charged for and make it a limited function. I had a change happen to my site in July that added 80M server calls/month and if we decide to abort those calls it would have been nice to be able to kill them via a processing rule. We can't do that now so we had to add a function to our code to kill some of these custom links that got added by accident until the app developers can fix and re-load their apps.

Hi Eric,

I am still unexperienced with the VRS, but I can imagine that setting this up, granting access to  the VRS to all relevant users and then convince (force?) everyone to use the new VRS instead of what they are used to can get both very time consuming and error prone.

Do you have any experience with that?

So one idea would be to leverage a hit-based segment in order to remove a specific set of hits from a report suite, then apply that segment to a VRS. Obviously that's different from completely deleting data from reports, but as mentioned above, that can get hairy.

I tried this in a test report suite (I wanted to remove hits from 11am on October 6th) and it seemed to work well! It's obviously not perfect, since it removes the entire hit, any evars/props that were set in that hit will also be removed, but it's another option to throw in here. I added a screenshot of my "exclude" segment if you're interested.

Hi warrensander,

You are writing "To delete the entire server call you would need adobe to impliment a 'delete this server call' type of a process." Is this something you have ever done? Or is this just something hypothetical?

Thanks,

Julian

Hi warrensander,

Thank you very much for your insights and best practices. Using processing rules and data sources seems to be a good way to "correct" bad data, so we'll look into that instead of persuing a one-click-delete-button solution.

Creating additional virtual workspaces with enforced segments looks interesting, not sure however how flexible that is in terms of adding new segments if needed.

We are of course setting calendar events for bad data, however this is only shown in charts and a lot of people work with Workspace data tables without any visualization. Maybe something for another Adobe suggestion to "fix" this...

Thanks again for your valueable insights!

Hi Creativebyte,

you can sort of do 'forced' segments with virtual report suites since those are based on segments to begin with. and I understand being over worked and under staffed to try to fix large amounts of bad data.

You should look at Data Sources because this does allow you to delete (zero out is probably a better word for it) bad data in events assuming you can actually find it.

We had an issue with an underflow where an event got translated into hex FFFFFFFFF... which ended up being 4 Billion (32 bits) and we had to back that purchase out with Data Sources. had to actually do it in several stages because I couldn't replicate the exact number so I had to kill as much as possible and then kill the leftovers.

But I learned from that incident that I REALLY didn't want to do at lot with Data Sources because that can really hurt your data.

That said it is a good way to back-out event data especially currency data that is not correct (revenue comes in and it's supposed to be dollars but it's actually yen and the currencycode didn't get set to YEN to allow for adobe to translate it during processing. etc)

For bad data in a prop or evar if you can isolate the bad data it's format etc you can use a processing rule to delete it (or move it to another variable) before it gets processed. and for already processed data you can always classify the data and have 'good data' 'bad data' classifications or copy the key value (what came in via the s-code) to a classified value and ~empty~ the bad values (or set them to "Don't use this data" etc.

The big problem with deleting data is do you delete the entire server call when evar1="bad data" or do you just delete evar1 and leave everything else. If you are thinking about just deleting that one evar value it might be better to classify it out. To delete the entire server call you would need adobe to impliment a 'delete this server call' type of a process.

I would like this in processing rules anyway so even if I have to pay for the server call it would just be nice to be able to 'delete/suppress' everything in this server call because of some setting.

so I'm with you both ways. I wish we never had to do it but understand that sometimes you need to get rid of bad data. It's just how you can go about doing it in a fast efficent manner.