A Sitecore implementation can use MaxMind lookups for GeoIP resolution; this is valuable information for marketers as it provides for geography-based segmentation in reports and decision making in the Sitecore Analytics package. The Analytics.PerformLookup setting in the /App_Config/Include/Sitecore.Analytics.config file governs the lookup activity, and is true with an OOTB installation config file (so be careful!).
It’s recommended to only set this setting to true for one server in an implementation; set this setting to false for the other servers. For scaled (multi-server) Sitecore installations, this is a common issue since the default config file enables Analytics.PerformLookup.
You can enable lookups on either a CM or a CD instance. The Sitecore instance should be able to access the MaxMind web service (via the public internet) in order to complete the work. Having more than one server configured as true for this setting can cause SQL deadlocks and other problems, as well as duplicating your traffic to MaxMind (and using any lookups you’re paying for).
Under the covers, this is what this PerformLookup setting is doing:
- Sitecore periodically starts a task on the server to perform GeoIP lookups if the setting Analytics.PerformLookup is true in Sitecore.Analytics.config
- This task is considered the “Lookup Worker” task
- The frequency of the Lookup Worker running is governed by the Analytics.PerformLookup.Interval setting in Sitecore.Analytics.config
- The Lookup Worker takes records in the Sitecore “Visit” table and processes any with an EmptyLocationID value in the LocationID column
- the EmptyLocationId is a special GUID that is generated on each environment, check the first record in the Locations table with a blank business name, country, etc if you want to see what GUID your system is using
- The goal of the Lookup Worker is to process Visit records with an EmptyLocationID and populate them with data, so they are no longer empty. It does this by communicating with MaxMind.
This is only part of the picture, though, as it explains how the background agent determines GeoIP information for Visits.
What about when a page loads that makes decisions based on the visitor’s GeoIP information; for example, news sites might target different Sitecore content to European visitors compared with Asian visitors.
The process of resolving a visitor’s GeoIP information is as follows:
- Attempt to retrieve the GeoIP information from the memory cache
- If there’s no data from step 1, retrieve GeoIP information from the Analytics database
- If there’s no data from step 2, request GeoIP information from the MaxMind geolocation service
Each of the above steps gets progressively slower; reading from memory > reading from the database > reading from a remote web service.
When it comes to step 3, if a request is made to MaxMind during a visitor’s HTTP request, Sitecore doesn’t make that a synchronous call and wait for a response. I’ve seen many websites perform slowly due to blocking web service calls, so this is a smart design decision by Sitecore. If, however, you’re in a situation where you want to wait for the GeoIP data, refer to this KB article from Sitecore for two methods of addressing it: https://kb.sitecore.net/articles/320734.
If you don’t want to pursue either work-around in the Sitecore KB article, but are using geolocation targeting in your implementation, you should plan for a graceful fallback. Provide for a generic set of data for non-geolocation targeted visitors.
Additional references on GeoIP resolution with Sitecore include:
- Engagement Analytics Configuration Reference Guide has lots of relevant documentation.
- Troubleshooting With MaxMind and Sitecore