Wednesday, December 16, 2009

Filtering IP Addresses from Marketing Analytics


Today's post is a guest post from Leigh Oxley, Team Lead in Eloqua's product support group. She has been a part of the Eloqua Product Support team since 2006, supporting marketers in their quests for marketing automation excellence.

Based out of Eloqua’s Toronto office, she is currently focusing on high-priority initiatives to improve the support organization, as well as working directly with our partner eco-system by providing dedicated support to certified partners. Not only that, but she's great to work with, so if you want ideas, insight, or help on your next campaign, data project, or lead scoring initiative, give Leigh or her team a call, and they are always glad to help.

================================


I think we can all agree that testing is an important part of any project – ensuring that everything will work as expected from start to finish. One thing we often don’t consider though, is how the test data will affect our reporting metrics once the campaign goes live. For example, if you run an email campaign driving visitors to a brand new landing page, and you have a team of internal people testing all of the pieces, you will want each of those people to click-through from your email to the landing page. Once your campaign goes live, you will have a set of visitors who are only testers, and likely shouldn’t count towards your marketing metrics once you go live – you don’t want to report inflated numbers to your executive team!

A quick and simple way to avoid this is to setup an IP filter within the Eloqua application, so that internal IP addresses are filtered from your analytics. As a Customer Administrator-level user, you have the ability to tell Eloqua “I don’t want to see visitor reporting on anyone coming from these IP addresses” through Setup -> Management -> System Management. This will simply disable tracking for anyone who visits your site from a list of IP addresses you define so that no web visitor information will be tracked. By setting this up for your organization, you can ensure that internal testers won’t be tracked and count towards your campaign metrics.


One question that clients often have when setting this up is how the functionality actually works. Essentially, when the website tracking scripts on your website pages see a visitor from an IP address you’ve configured to be filtered, they will ignore this visitor’s data. That means that if you later decide you want to track information for this IP address, you can simply remove it from the list and tracking will begin to take place. Something important to note is visitor data is removed on an ongoing basis while the IP address filter condition applies, but that existing data is not affected.

If I have a visitor profile with website visits reported from yesterday, and my IP address is added to the list today, then removed tomorrow, there will be a one-day gap in the reporting for my visitor – while I’m on the list, no web activity will be tracked. Another important point is that this does not affect other reporting for the contact, only visitor website activies are affected; all form submissions, program history, email sends, email opens, are still tracked as normal, but email click-throughs (as these are web activity) will not be tracked.

Hopefully this helps you to maximize your reporting efficiency in Eloqua and ensure you’re reporting the truest information to your teams. If you would like to set this up for your organization, there is a step-by-step interactive checklist available here in Customer Central to walk you through.

2 comments:

Unknown said...

Is there a way to do IP families to exclude hits from an entire office location altogether?

Leigh Oxley said...

Hi Aby,

You can exclude a block of IPs, using a wildcard, but at this time it's not possible to exclude a range.
For example, if your organization owns the whole block from 192.168.1.1 to 192.168.1.255, you can exclude 192.168.1.*. However, if you connect on IPs from 192.168.1.1 to 192.168.1.20, you would have to put each individual address in.
We're hoping to have the functionality soon where ranges can be input.