Handling Processing Rules Rollback

[nitesh__anwani]

Hi Folks,

I have a quick question regarding handling Processing Rules in Adobe Analytics.

I recently made two changes to the Processing Rules in our lower-environment report suite:

Change 1: Added several new variables
Change 2: Fixed certain mappings that were not working as expected

QA validation for Change 1 is complete, and it is ready to be pushed to the production report suite.
However, Change 2 will require an additional two weeks for my team to complete validation.

Our standard practice for production deployment is to move the entire ruleset from the development report suite to the production report suite. Given the current situation—where Change 2 is not yet fully validated—I need to roll back to a version that contains only Change 1, push that to production, and then reapply Change 2 so the team can continue their testing.

I see two possible options:

1. Manually undo the Change 2 updates, deploy the validated Change 1 to production, and then manually reapply Change 2 in the development report suite.

2. Use the “Copy to Current Ruleset” feature available in the History section of Processing Rules. When selecting a previous version through the “View” option, there is an action to copy that version to the current ruleset—effectively performing a rollback.

I have never used the “Copy to Current Ruleset” option before. It appears to do exactly what I need, but I want to confirm whether this is a safe and reliable method. Has anyone used this feature previously? Does it work as expected?

Our Processing Rules configurations are critical for the business, so we want to avoid any risk of breaking the current setup.

Thanks in advance for your guidance.

[Sumit-Kumar · Accepted solution]

Yes, “Copy to Current Ruleset” in processing rule is safe and recommended for rollback. Note that changes only affect future data, past collected data remains unchanged and cannot be retroactively changed.

Select the desired historical version in 'View History' then click the selected date 'View' for that particular date/snapshot.
Click 'Copy to Current Ruleset' note that it immediately will not save anything it just shows previous version if all ok, then Save.
This restores the ruleset exactly as it was at that particular date/snapshot.

Always verify rules/ order before saving.

[nitesh__anwani]

Hi @Sumit-Kumar ,

Thank you very much for your response.

I just want to ensure that I have understood this correctly.

Let’s assume there are two versions in the history:

• Version 1 (1st Dec): Contains 45 rules.

• Version 2 (5th Dec): Contains the original 45 rules plus 5 new rules, for a total of 50.

My current snapshot would therefore include 50 rules (Version 2).

Now, if I want to roll back to Version 1 (the version from 1st Dec), I would click “View”, and then use the “Copy to Current Ruleset” option. This should replace the current snapshot with the 45 rules from Version 1. Is that correct?

I want to double-check because I’m using this feature for the first time, and the documentation is not very detailed. The label “Copy to Current Ruleset” suggests that it will copy those rules into the current snapshot, but what I expect is that it will replace the current ruleset with the selected version.

[Sumit-Kumar]

Yes, that is correct.
In your eg, selecting Vers. 1 (1st Dec) from History and using “Copy to Current Ruleset” will replace the entire current ruleset with the 45 rules from that snapshot/date. It does not merge or append rules.
Once saved, the ruleset will exactly match the selected historical version and will only impact future data, not historical data.

[nitesh__anwani]

Thanks for the guidance on this topic!

I tested the approach, and it is working as expected.

I also created a small R script that I used to validate each step of the process—for example, extracting the rules before and after the rollback to directly compare what changed. Because I had a large number of rules, this helped ensure that only the intended changes from the recent version were rolled back.

I am including the R code snippet here in case anyone else encounters a similar use case in the future. It may be helpful as an additional layer of validation.

Although it uses the Analytics 1.4 API, it is sufficient for ad hoc validation until the API is fully sunset.

###########################################
#Refernce documentation: https://randyzwitch.com/rsitecatalyst/
###########################################


url <- "https://cran.r-project.org/src/contrib/Archive/RSiteCatalyst/RSiteCatalyst_1.4.16.tar.gz"
download.file(url, destfile = "RSiteCatalyst_1.4.16.tar.gz")
install.packages("RSiteCatalyst_1.4.16.tar.gz", repos = NULL, type = "source")


rm(list = ls());gc(); 

setwd('D:/Web Analytics Projects/Adobe admin work/20251212/');
file_name = 'processing_rules_20251212 - webmddev -after reverting the rollback action' # output file name 

library(jsonlite)
library(RSiteCatalyst)
SCAuth("username:company", "<shared secret>")
GetReportSuites()
temp <- ViewProcessingRules("webmddev") #change the name of the report suite as per the requirement 


df <- data.frame(
  text = paste(capture.output(str(temp)), collapse = "\n"),
  stringsAsFactors = FALSE
)

write_json(temp, paste0(file_name,".json"), pretty = TRUE, auto_unbox = TRUE)

temp <- fromJSON(paste0(file_name,".json"))

df <- as.data.frame(temp, stringsAsFactors = FALSE)

write.csv(df, paste0(file_name,".csv"), row.names = FALSE)