Your Customer.io Location Data Just Went GPS-Accurate. Use It for Send Times, Not Geo-Targeting

Q: What location attributes does Customer.io set?

On identify it sets cio_city, cio_region, cio_iso_country, cio_country_name, cio_latitude, cio_longitude, cio_timezone and cio_location_source. It added cio_iso_continent, cio_continent, cio_iso_region, cio_region and cio_postal_code on 17 November 2025. Don't set these yourself, because Customer.io overwrites them.

At midnight on 1 May 2000, millions of GPS receivers got ten times more accurate without anyone touching them. President Clinton had ordered the US military to switch off Selective Availability, the deliberate degradation the government had built into the civilian GPS signal for national-security reasons. A car navigation unit that the night before could place you within about a hundred metres could suddenly place you within ten.

The White House put it plainly: "It's rare that someone can press a button and make something you already own worth more, but that's exactly what's happening today." Receivers in boats, cars and hiking packs became an order of magnitude sharper, for free, overnight.

Precision arrived for everyone at once... whether or not they had a use for it. That's worth keeping in mind now that Customer.io has switched on something similar.

On 12 March 2026, Customer.io's mobile SDKs gained device-based GPS location, on top of the IP-based geolocation that was already there. The release note calls it "geo-aware messages", which reads like geofencing. It isn't. Here's what actually shipped, the rules that decide which location Customer.io stores, and the one use that earns its keep for most teams: getting the time zone right.

What actually shipped on 12 March 2026

Customer.io's mobile SDKs can now capture GPS coordinates straight from the device, reverse-geocode them into location attributes, and send a Location Update event. This sits on top of IP-based geolocation, which has been there all along. The release note frames it as "geo-aware messages with even greater accuracy than IP-based geolocation". The reason device data beats IP on mobile is mundane: VPNs, carrier routing and shared Wi-Fi all blur an IP address into the wrong city. Coordinates from the handset don't have that problem.

The capability is in all five mobile SDKs: iOS, Android, React Native, Flutter and Expo.

Here's the part the "geo-aware" phrasing gets wrong in most people's heads. This is not geofencing. There is no native "when the user crosses this radius, fire this message" trigger. Customer.io stores location as profile attributes and emits a Location Update event, and any targeting you do happens through segments and event-triggered journeys, the same machinery you already use. The GPS upgrade makes the underlying data sharper. It doesn't add a proximity engine.

IP versus device: what each one knows

IP geolocation infers a location from the IP address using MaxMind's GeoIP database, accurate to a city or region. Device geolocation reads GPS coordinates from the phone, accurate to a street. The difference shows up in two attributes: for a device-sourced location, cio_latitude and cio_longitude are the precise GPS fix; for an IP-sourced one, they're the approximate centre of the city. Customer.io is candid that the IP-derived cio_postal_code "is an approximation based on the geolocated IP address" and "may not be exact".

So device GPS buys you real street-level accuracy. The question that decides everything below is whether your messaging actually needs it.

The rules that govern your one stored location

Customer.io stores exactly one location per person, and four rules decide what it is. Get these straight before you brief anyone.

Device beats IP. When both sources are available, device-based location takes precedence because it's more precise. The cio_location_source attribute records which one won, with a value of ip or device, so you can always see where a profile's coordinates came from.
The update is throttled two ways. To protect battery life, the SDK sends a location update once per day at most, and only when the person has moved more than 1km. Both limits apply. Someone who opens your app six times from the same office won't generate six updates, or even one.
Device location is sticky. When valid device coordinates already exist, Customer.io skips IP geolocation entirely, even if the device location wasn't refreshed because the person hasn't moved that kilometre. That stops a fuzzy IP reading from overwriting a precise GPS fix. When the source does change, Customer.io rewrites all the geolocation attributes so stale values from the old source don't linger.
The EU is manual; the US is default-on. Automatic Geolocation Data Collection is on by default in the US data centre. In the EU data centre you switch it on yourself, in Workspace Settings. That default is doing privacy work for you, so change it deliberately.

The attributes Customer.io sets on identify include cio_city, cio_region, cio_iso_country, cio_country_name, cio_latitude, cio_longitude, cio_timezone and cio_location_source. Customer.io added five more on 17 November 2025: cio_iso_continent, cio_continent, cio_iso_region, cio_region and cio_postal_code, backfilled the next time you identify an older profile. Don't set any of these yourself. Customer.io overwrites them with its own values on the next identify.

The use that earns its keep: time-zone-accurate sends

For most teams, the single most valuable thing this precision buys is a correct cio_timezone. That's the attribute Customer.io reads for recommended send time. Get someone's time zone wrong and your carefully chosen 9am send lands at 2am, which no amount of subject-line testing will rescue.

This is where coarse location quietly outperforms precise location. You don't need a street address to know someone's time zone or country... you need their region, and IP geolocation already gives you that on every identify, with no permission prompt and no battery cost. Turn on automatic geolocation and cio_timezone populates for your whole identified audience. Device GPS sharpens the fix from "this city" to "this street", but the time zone was already right.

Country and region data does the same job for segmentation. cio_iso_country and cio_region let you build location segments, send the right-language campaign, or split a broadcast by market, again without any GPS. If your audience lives outside the US, accurate time zones and clean country segments will move more revenue than street-level coordinates ever will.

One nuance worth knowing: the manual timezone attribute, if you set it, takes precedence over the automatic cio_timezone. That's useful for a frequent traveller, where you'd rather pin a stable "home" time zone than chase them around the map.

When proximity targeting is actually worth the permission

Build proximity campaigns only if you're a location-native product. Food delivery, live events, retail footfall, field services... businesses where the customer expects the app to know where they are. For everyone else, the permission and privacy cost outweighs the payoff, and here's why.

Device GPS depends on the operating system handing it over, and the operating system asks the user first. Apple's Location Services make an app request permission the first time it wants a location, with a prompt that names the app and its stated reason. The user can grant access While In Use, Always, or just Allow Once, and can revoke it from Settings at any time. A non-location app rarely earns even While In Use, because the user can't see why a newsletter or a project tool would need their whereabouts. Location can also be returned imprecisely, and there's a battery cost to collecting it at all.

The practical upshot: device GPS will only ever populate for the slice of your users who both granted permission and run a recent enough SDK. For a delivery app that's most of them. For a B2B SaaS it's almost nobody, and IP geolocation already handed you the time zone you actually wanted. Asking the rest for precise location, to power a targeting feature you don't have a clear use for, spends trust you'll want later.

How the data reaches the profile

Device location reaches a profile through two pathways, and knowing which one helps you brief engineering precisely.

The first is identify calls. When a mobile SDK sends an identify with the Location module enabled, it includes GPS coordinates alongside the IP address, and Customer.io checks the device coordinates first. The second is the Location Update event: the SDK sends a track event carrying latitude and longitude, which updates the profile's geolocation attributes. Because it's a normal event, you can trigger journeys and build segments from it, the same way you would with any other behavioural event. If your event schema is already disciplined, the Location Update event drops straight into it.

The privacy and hygiene checklist before you turn it on

Before you ask a single user for their location, work through this.

Decide the use first. If the honest answer is "time zones and country segments", you don't need device GPS at all. Automatic geolocation on the IP address already covers it.
Treat the EU default as a decision, not an obstacle. It's off there by design. If you turn it on, write down why and who agreed.
Never ask for "Always". While In Use covers every messaging use case. "Always" is a far harder sell and invites the user to decline outright.
Don't hand-set the cio_ attributes. Customer.io overwrites them on identify, so your values just create confusion.
Re-identify in new sessions. Location and time zone only stay current if you identify people again as they move, rather than relying on a remembered session.
Clean up if you stop. When you disable collection, Customer.io lets you delete the geolocation data you already gathered. Take that option rather than leaving stale coordinates on profiles.

Switched-on precision is only worth having if you've got a use for the extra decimal places. For most lifecycle teams, that use is a time zone, not a target.

Frequently asked questions

Does Customer.io do geofencing or trigger on location entry?

No. Customer.io has no native geofence and no "entered this area" trigger. It stores location as profile attributes and emits a Location Update event. Any location targeting happens through segments and event-triggered journeys, not a proximity engine.

How accurate is Customer.io location data, IP versus GPS?

IP-based geolocation is accurate to a city or region, derived from the IP address via MaxMind's GeoIP database. Device-based geolocation is accurate to a street, read from the phone's GPS. For a device-sourced location, the stored latitude and longitude are the precise fix; for an IP-sourced one, they're the approximate centre of the city.

Do I need the user's permission for device location?

Yes. On iOS the operating system makes your app request permission before it can read a location, and the user chooses While In Use, Always, or Allow Once, and can revoke access at any time. Device GPS only populates in Customer.io for users who have granted that permission.

Why hasn't a person's location updated after they travelled?

Three throttles are usually the reason. The SDK sends a location update once per day at most, and only when the person has moved more than 1km. You also need to identify them again in a new session for the new location to flow through. Device location is also sticky, so a valid GPS fix won't be replaced by a less precise IP reading.

Is automatic geolocation on by default in the EU?

No. Automatic Geolocation Data Collection is on by default only in the US data centre. In the EU data centre you enable it manually under Workspace Settings, Time Zone and Geolocation Settings.

Can I use location only for send-time accuracy and not targeting?

Yes, and for most teams that's the point. Enabling automatic geolocation populates cio_timezone from the IP address, which feeds recommended send time, without you ever building a location segment or asking for device permission.

What is the cio_location_source attribute?

It's a profile attribute that records where the stored location came from, with a value of ip or device. Because device data takes precedence, cio_location_source tells you at a glance whether a profile's coordinates are a precise GPS fix or an IP approximation.

Which Customer.io SDKs support device location tracking?

All five mobile SDKs: iOS, Android, React Native, Flutter and Expo, as of the 12 March 2026 release.

Does device GPS overwrite a person's IP-based location?

Yes, when device coordinates are present. Device location takes precedence, and once valid device coordinates exist Customer.io skips IP geolocation entirely. When the source changes, Customer.io rewrites all the geolocation attributes to clear stale values from the previous source.

What location attributes does Customer.io set?

On identify it sets cio_city, cio_region, cio_iso_country, cio_country_name, cio_latitude, cio_longitude, cio_timezone and cio_location_source. It added cio_iso_continent, cio_continent, cio_iso_region, cio_region and cio_postal_code on 17 November 2025. Don't set these yourself, because Customer.io overwrites them.

How is the manual timezone attribute different from cio_timezone?

cio_timezone is set automatically from geolocation. The manual timezone attribute, if you set it, takes precedence over cio_timezone. It's useful for pinning a stable "home" time zone for someone who travels across time zones often.

Will turning location tracking on drain users' batteries?

Customer.io limits location updates to once per day at most, and only when the person has moved a meaningful distance, which keeps the battery cost low. Any location permission carries some overhead, though, so only ask for it if you have a concrete use for the data.