Skip to main content Skip to search
Alex Vayl
Posted by
Alex Vayl on
July 1, 2014

Geotargeting versus Geofencing: FIGHT!

NSONE’s revolutionary Filter Chain technology perfectly balances the often competing interests of power, flexibility, and usability in order to allow you to configure powerful, complex routing algorithms that direct your end users to your infrastructure in a way that’s custom tailored to your application and network. Our approach is so kick-ass that you can sign up for a free NSONE account and build a CDN with it in just a few minutes.

Currently you can mix and match 15+ Filters to route your traffic in a way that makes most sense for your business. There are filters that let you:

  • shuffle your answers to distribute your load
  • impart properties into your answers like stickiness and priority
  • make decisions on real-time Data Feed like Up/Down status, system load, or even connection counts
  • route end users based on their geographic proximity to your infrastructure (commonly referred to as Geotargeting)

NSONE offers several unique ways to use geographic data to make routing decisions, but broadly speaking they fall into two categories: targeting and fencing. The concepts are similar but there are a few nuances and subtleties that set them apart and so today we’d like to talk about how to decide which is right for your specific application.

Geotargeting works kind of like gravity. By simply adding the latitude and longitude of each of your servers in our portal and then enabling the GEOTARGET_LATLONG filter in our portal, each of your servers becomes a source of gravity that attracts end users.

Geotargeting is extremely simple to configure, use, and manage. All you need to tell us is where each of your answers is located and then all of the geodesic distance and proximity computations are automagically handled in real-time and in-process by our DNS kernel.

If you have one server in London and one in Istanbul here’s what routing using GEOTARGET_LATLONG might look like for users in continental Europe:

If Geotargeting acts like gravity, then Geofencing is more like a tractor beam. The GEOFENCE_REGION and GEOFENCE_COUNTRY filters look for requests coming from specific regions, countries, or states that you specify and immediately route those users to the server or servers of your choosing. Beyond simple geographic proximity, this allows you build a targeting algorithm that’s based on your real world business needs.

For example, let’s say that due to some obscure copyright law users in France CAN NOT download information from your London server. We still want to use geographic proximity to route your user to the closest datacenter EXCEPT when the user is from France – regardless of the fact that they’re next door neighbors with England, we want them going to the Istanbul datacenter. By simply adding “France” as country metadata on your Istanbul server and then enabling the GEOFENCE_COUNTRY filter and placing it before your GEOTARGET_LATLONG filter, end users in Paris will always be routed to Istanbul. Everyone else who’s not explicitly Geofenced will continue on to be Geotargeted to Istanbul or London, whichever is closer:

Compliance is one example where Fencing is extremely useful. In this next example we’ve configured our country metadata such that users who are coming from EU Member Countries will be routed to London, while non-EU visitors will be routed to the server in Istanbul:

So then if Geofencing provides you with this extra granular level of control – what’s the downside? To start, you have to make sure every single country is accounted for and associated with a particular answer. If you miss a country or region, users from that geography will be sent to a catch-all answer, which may not be the answer you intended. Adding infrastructure can also be a pain as you’d have to go back through and adjust metadata on every one of your records.

It is technically possible to configure geotargeting and geofencing such that they will behave identically and return the same answers, but it requires a lot of work and it can quickly become an operational headache to maintain. The solution to this problem is to use both filters, one to do Geofencing when you know you need it, and then a second to do proximity-based Geotargeting.

TL;DR: Use Geofence selectively and explicitly when your business rules diverge from simple proximity, then Geotarget everyone else. This approach gives you the best of both Filters: the control of Geofencing on top of the ease of use, intelligence, and speed of Geotargeting.