Level 2

Question

Processing Rules based on IP Addresses to flag internal traffic & "Replace the last octet of IP addresses with 0"

Forum|Forum|1 year ago
June 5, 2024
2 replies
1806 views

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?"

Analytics

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Jennifer_Dungan

Community Advisor and Adobe Champion

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!

andreiabenitesAuthor

Level 2

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

Community Advisor and Adobe Champion

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

Community Advisor

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.

andreiabenitesAuthor

Level 2

Thanks, Robert.

As for data processing order, what you said got me thinking as

https://experienceleague.adobe.com/en/docs/analytics/technotes/processing-order shows IP obfuscation happening before processing rules and VISTA.

RobertBlakeley

Community Advisor

The last octet obfuscation happens before. The remove ip happens after. Two different things.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded