Make Bot rules retroactive

[#1]

In most cases, folks create new Bot Rules specifically because they've uncovered a bot that has been messing with their data... unfortunately, by the time you've identified the problem and created the rule, it's too late: the bot has already done damage.
The workarounds are pretty drastic- applying a segment to every report, or moving entirely into a Virtual Report Suite that doesn't include the bot traffic retroactively.

Bot rules working on historical data would be a huge help.

[#2]

Hey Jen, thanks for the suggestion! Have you looked at using a virtual report suite for this? I've found that creating a segment filtering out the "Linux" or "Not Specified" operating systems or if the browser contains "unknown version" usually gets 75% to 80% of bot traffic for most sites.

If you need something more serious, you can look at some solutions in our exchange portal:

ShieldSquare

PerimeterX Bot Defender for Adobe Analytics

[#3]

Yep, I know Segments and Virtual Report Suites are a workaround for this. But those have a few potential problems too:
You have to have been capturing IP into a custom variable. Unless folks have been doing that already in their RS, it has the same retroactivity problem- it would only work for data going forward.
Moving an already established org from the main report suite to a VRS can be really hard, especially if they already have a lot of workspace/ad-hoc reports set up and such.

I think I've learned my lesson and going forward for new implementations, will encourage them to a) stick IP in a custom variable (though I believe that has privacy problems in Europe) and b) START in a VRS so if/when they want to segment out bad data from already-existing reports, it's not a huge deal.

[#4]

I'd be careful about sticking IP address into a custom variable - however, it could technically work as you've described. Have you tried my suggestion of filtering out Linux, or unknown browsers?

Another thing to try is using customer attributes for this (actually passing the cookie ID in as an alias ID using setCustomerID). I've seen some customers do bot analysis offline (or find the bad IP addresses) and classify the bad visitors as bots. This works retroactively as well.