Geofencing Marketing: A Developer's Implementation Guide

Geofencing marketing uses virtual boundaries around physical locations to trigger targeted actions - push notifications, in-app messages, or backend events - when a user's device enters or exits a defined zone. This guide covers how geofencing works at the SDK and platform level, the implementation constraints developers face on iOS and Android, and the architecture patterns that make geofencing campaigns reliable in production.

What Geofencing Marketing Does

Geofencing marketing connects digital campaigns to physical presence. A retailer draws a 200-metre radius around a store. When a customer with the app installed crosses that boundary, the system triggers a pre-configured action: a discount notification, an order preparation workflow, or an analytics event.

The marketing value comes from timing and relevance. A push notification sent when someone is 3 minutes from a store converts at 2.5x the rate of a generic broadcast. But the engineering challenge is what makes or breaks the campaign: background location accuracy, battery drain, platform-specific limits, and consent architecture.

Most geofencing marketing guides stop at the "what." This one covers the "how" - the implementation details that determine whether a geofencing campaign actually works in production.

Geofence Shapes

There are two standard approaches to defining a geofence:

Circular (centroid + radius). Define a centre point (latitude/longitude) and a radius in metres. Simple to create, efficient to monitor, and supported by every platform. Good for individual store locations.

Polygon. Define a series of vertices that outline an arbitrary shape. Useful for irregular areas - a shopping mall footprint, an industrial zone, or a neighbourhood boundary. More expensive to evaluate and not natively supported on all mobile platforms without SDK assistance.

A third approach uses isochrones - boundaries defined by travel time rather than distance. A "5-minute walk" geofence adapts to street layout and terrain, which matters in dense urban areas where 200 metres might mean a 10-minute detour.

Entry, Exit, and Dwell Events

A geofence generates three event types:

• Entry. Device crosses from outside to inside the boundary. Triggers immediate actions like push notifications.
• Exit. Device leaves the boundary. Useful for post-visit surveys or re-engagement flows.
• Dwell. Device remains inside the boundary for a configurable duration. Filters out pass-throughs (someone driving past) from genuine visits.

Dwell detection is critical for marketing accuracy. Without it, a driver passing a store at 60 km/h triggers the same event as a shopper walking in. A 2-minute dwell threshold eliminates most false positives.

Building a Geofencing Pipeline

A production geofencing system has four layers:

The SDK Layer

The mobile SDK handles two jobs: monitoring the device's position and evaluating it against registered geofences. Both iOS (Core Location) and Android (Geofencing API) provide native primitives, but raw platform APIs require significant boilerplate for production use - battery management, permission handling, retry logic, and background execution.

Here is a simplified example registering a circular geofence on Android:

On iOS, the equivalent uses `CLCircularRegion` with `CLLocationManager`. The API surface is different, but the concept is identical: register a region, receive callbacks on transitions.

The Backend Layer

Events from the SDK reach the backend as structured payloads - user ID, geofence ID, transition type, timestamp. The rules engine decides what happens:

• Frequency capping. Do not send more than one notification per store per 24 hours.
• User segmentation. Loyalty members get a personalised offer; anonymous users get a generic prompt.
• Time-of-day rules. No notifications before 08:00 or after 21:00.
• Campaign state. Check if the associated campaign is still active and within budget.

The action layer then dispatches: push notification via APNs/FCM, in-app message via a messaging SDK, or a webhook to an order management system for click-and-collect preparation.

Platform Constraints Every Developer Should Know

iOS Background Location

iOS restricts background location access aggressively. Key constraints:

• Region monitoring limit: 20 simultaneous geofences per app. If you have 500 stores, you must dynamically register the nearest 20 based on the user's last known position.
• Background refresh: iOS wakes your app for region transitions, but with no guarantee on timing. Expect 1-5 minute delays in low-power mode.
• Approximate location: Since iOS 14, users can grant "approximate" location (city-level). Geofencing requires "precise" - your permission flow must explain why.
• Always Allow: Geofencing requires "Always Allow" location permission, not just "While Using." Conversion from "While Using" to "Always Allow" drops significantly - Apple's own guidance recommends progressive disclosure.

Android Background Execution

Android has its own restrictions:

• Geofence limit: 100 per app (more generous than iOS, but still finite).
• Background location permission: Since Android 12, `ACCESS_BACKGROUND_LOCATION` must be requested separately from foreground permission, and the Play Store requires a declaration explaining why.
• Doze mode: When the device is stationary and screen-off, Android batches location updates. Geofence events may be delayed by minutes.
• Geofence re-registration: After device reboot or app update, all geofences are cleared. The app must re-register them on boot via a BroadcastReceiver.

Privacy-by-Design: GDPR-Compliant Geofencing

Location data is personal data under GDPR Article 4(1). Any geofencing implementation in the EU or UK requires:

1. Explicit consent. Location permission granted by the OS is not GDPR consent. You need a separate, informed opt-in that explains what location data you collect, why, and for how long.
2. Purpose limitation. If consent is granted for "order preparation notifications," you cannot reuse the same location data for "footfall analytics" without separate consent.
3. Data minimisation. Collect the minimum data needed. If you only need entry/exit events, do not stream continuous GPS coordinates to your server.

On-Device vs Server-Side Processing

The architecture choice matters for compliance:

Server-side geofencing sends raw device coordinates to a backend that evaluates geofence boundaries. This means location data leaves the device, creating a data controller obligation, a data processing record, and a potential cross-border transfer issue.

On-device geofencing evaluates boundaries locally on the phone. The backend receives only event payloads ("user entered geofence store-paris-01 at 14:32") - not raw coordinates. This minimises the personal data surface and simplifies compliance.

70% of consumers are willing to share location when they receive tangible value - faster service, relevant offers, or loyalty rewards. The technical architecture should make good on that trade: collect only what the use case requires, process locally where possible, and give users a clear off-switch.