Location-Aware Marketing might be the next big thing in marketing.

After all, if still 90% of all purchases are done offline, then why not market in the offline segment as well? Competition is little and the potential impact on a company's bottomline is huge.

However, if it were that easy everybody would already be doing it. In what follows, I describe a business and technical overview of the challenges of such a system based on my experiences working as a consultant for almost 2 years in a Fortune 500 company where I was responsible for developing the prototype backend and putting it partly into production.

The project's goal was to market goods and services to retail customers via an established and widely used cell phone application for payments. Consequently, the app should be extended to allow for location-aware real-time marketing, i.e., "promoting things when the customer is at a specific place at a specific time."

The resulting use cases were based on the cell phone acting as a location sensor and possibly coupon display under the following scenarios:

1. Customer enters a shopping mall -> receives coupon to entice footfall in a new shop
2. Customer waits in his car at a traffic light -> the ad billboard next to the traffic light is personalized to the customer's preferences
3. Customer leaves work around noon -> offer lunch coupon to entice him and his colleagues to visit restaurant
4. Customer leaves work in the evening -> offer grocery store coupon to entice him to do his grocery purchases there

Besides the obvious cell phone application the system requires a back-end server that holds all coupon and customer data and responds fast even when being used by a few hundred thousands of people. My work was mostly on the back-end side, developing the database schema and the RESTful API while keeping an eye on application security (not so hard) and scalability (much harder). Here is a list of things to consider before you start developing your own coupon ad service:

Technical Obstacle: Efficient Geo-Lookup

The problem: Aggregating all coupons and serving those nearby, every few minutes. This must happen fast because at 1 million users and a polling interval of 5 minutes we need to serve 1600 request per seconds.

Proposed solution: Using Hilbert Curves and the google S2 library. It's also Foursquare's approach and encodes location in databases via 64 bit integers. Since integers are easily indexed, fast lookups are straightforward and don't require any special extension (such as postgis at the cost of just a little bit more application logic. This makes the solution database-agnostic and indeed we switched from a postgres prototype to an oracle database without affecting the DB structure. A good explanation of the underlying concepts can be found here.

Technical Obstacle: Recommendation Logic

For each request to serve nearby coupons we must order the coupons by relevance to the customer. This is to reduce cognitive load on the customer and to serve only the most important among the nearby coupons (reducing IO and bandwith usage thereby).

I chose to use a simple yet fast recommendation algorithm based on a Naive Bayesian Classifiers. Here, different dimensions "constituting" relevance are evaluated, each resulting in a probability. By multiplying these probabilities one arrives at an aggregate probability that the customer likes the coupon.

Examples for dimensions are:

• coupon users within the last hours ("hotness" of the coupon)
• coupon category (food, electronics, ...)
• coupon tags (a set of keywords)
• distance from customer to coupon
• distance from typical customer locations (e.g., places where customer stays regularly for several hours per week) to coupon
• time of day and day of week
• customer coupon preferences (as inferred from the customer's interaction history)
• customer eligibility (gender, age)

The approach has several advantages:

1. It is simple and very fast to calculate and needs no extensive prior training, an ideal initial recommendation algorithm that can be gradually refined.
2. It is easy to use even if the customer has no history of interacting with coupons: You just use coupon hotness and distance, i.e., switch off most dimensions until you have enough data. You gradually turn those dimensions on when you have more data.
3. It is the opposite of a black box: You can easily explain why a given coupon is chosen over another and introduce weights to modify the importance of specific dimensions. Modifying those weights later on based on customer segment is straightforward

Business Obstacle: Defining the Process and Constraints

Regarding the process, many questions have to be answered:

Creating Coupons

• Who creates the coupons - the merchant via a web portal or a service desk employee? Is there some sort of double-check or revision mechanism in case some wrong data was entered?
• Do you allow pictures with coupons? What if those contain adult material?
• How do you interface with existing coupon campaign tools that your merchants might already use?

Using Coupons

• Can a coupon be "reserved" by a customer before actually being redeemed?
• Are coupons transferrable? Can people reserve coupons for others who otherwise wouldn't be eligible?
• How do you identify yourself at the shop as the legitimate coupon owner?
• Do you want public coupons or private coupons, public coupons being those that anyone can see/redeem and private coupons being those pushed only to specific people and only redeemable by those?

Coupon Constraints

• (Maximum) Number of categories and tags?
• Are there limits on how many coupons can be reserved or redeemed as a general cap?
• Can a coupon be used more than once per person? How often? Are the limits applied to reservation or redemption?
• Is reservation or redemption in any other way limited? Maybe only during week days, or only during specific hours? Or maybe only to specific locations of a merchant?
• Until when coupons are valid?

Business Obstacle: Business Case and Actions

Depending on your business model, you will need infrastructure in place:

• If you sell impressions: You will need to control the content of ad screens and (trivially) the app
• If you sell footfalls: Your app will need to be able to connect to the internet within the target shop or at least get GPS coordinates for later use. Correcting for people who only pass by shouldn't be a big problem given enough data.
• If you sell redemptions: This is probably only easy if you control the payment network or the Merchant's Point of Sale.

Business Obstacle: Promoting the app

Finally, you need to get the app on enough consumer cell phones in order to be able to attract merchants. It's probably easiest and cheapest to start in a big city and focus on growing merchants and consumers there. Once you have a name there, you can expand to other cities.

You have a similar project in mind and need help? Let me know!