Adobe Analytics

andreiabenites · 6/5/24

We want to enable "Replace the last octet of IP addresses with 0" in the report suite General Settings, however, we have processing rules to flag internal traffic based on IP Addresses and override a prop (employee vs non-employee). Since we enabled "Replace the last octet of IP addresses with 0" the employee visit counts dropped to 0. The IP addresses we are matching on are ranges. So for example:

XXX.XXX.86.0/23 provides IP range of XXX.XXX.86.1 - XXX.XXX.87.255

We have also tested adjusting our IP addresses list to have a zero at the end, but this also did not work. If the last octet rule executes first by changing the last set of numbers to 0 before running any logic, couldn’t we load in to match on XXX.XXX.86.0, XXX.XXX.87.0 for the above example?"

Jennifer_Dungan · 6/5/24

In theory that logic sounds good to me... we haven't enabled "Replace the last octet of IP addresses with 0", but I was going to suggest running your logic on XXX.XXX.86.0, XXX.XXX.87.0.

I am not sure if the Post-Processed data in the Experience Cloud Debugger is still broken, but if it's functioning for you, you could try to test in real-time without having to wait an hour per testing cycle... If the debugger is still glitching, do you have a mobile app with the AEP Assurance extension? If your mobile apps are registering against your internal IPs you could try testing here.. if they aren't, you could put up a temp rule based on the IP you are testing from to see if you can get the logic working.

Good luck!

andreiabenites · 6/7/24

Thanks, Jennifer!

It looks like we figured it out. Because we had over 300 IP addresses to include and each processing rule would allow me only 6 conditions with 30 rows in each, I ended up with 3 processing rules. What was happening was that because each processing rule had different IPs listed, #2 would overwrite #1 and #3 would overwrite #2. We then added a condition of “If propXX does not equal "employee” to the Otherwise do the following part of processing rules #2 and #3.

Jennifer_Dungan · 6/7/24

Ouch.. that sounds a little painful, but I am glad its working. In this instance, I was hoping the last octet was updated before processing rules so you only had to check for 2 values.

RobertBlakeley · 6/6/24

We do do something similar. We have a vista rule rule to move employee traffic to a different report suite. This does not work with the replace last octet option because of the Adobe processing order. It does work with IP Obfuscation > Remove IP Address turned on as the vista rule is processed before the IP address is removed.

Processing rules also work before the IP address is removed. I have not tried processing rules with the remove last octet option, but I would think that the last octet rule is executed before processing rules.

In our remove IP set up, we set up a processing rule to populate "allowable" IPs into another variable. You could try something similar with an internal user flag, but would still need to use the Remove IP option.