Summarize this documentation using AI
Overview
Geolocation and time zone data in Customer.io helps you time messages around when someone is actually awake, shopping, and likely to convert. For D2C, that usually shows up as better abandoned cart recovery, stronger first purchase conversion from browse behavior, and more repeat purchases from post-purchase replenishment and cross-sell flows. Propel helps brands operationalize time zone strategy across email, SMS, and push without turning your journey map into a maintenance project. If you want to pressure test your timing plan, book a strategy call (we implement this inside Customer.io).
How It Works
Geolocation and time zone data in Customer.io works by storing a person-level time zone (and sometimes location context) that campaigns and workflows can reference for send-time decisions.
In practice, you get value in two ways:
- Send messages in the customer’s local time zone so a “2 hours after cart” reminder lands at 7:15 PM local time, not 7:15 PM in your HQ time zone.
- Use time windows and delays more intelligently so you avoid overnight sends, and you can coordinate multi-channel touches (email first, SMS later) based on local behavior patterns.
Most D2C teams treat time zone as a durable profile attribute that is set from your source of truth (Shopify, CDP, data pipeline) and updated when new evidence appears (new shipping address, app location, more recent session). From there, journeys reference that attribute for scheduling and time-window rules in Customer.io.
Step-by-Step Setup
Geolocation and time zone data in Customer.io is only as good as your data hygiene, so set the attribute deliberately and decide which system owns updates.
- Pick your “time zone” source of truth. Common choices are shipping address time zone (highest purchase intent), billing address (less ideal), app device time zone (great for mobile-first), or IP-derived time zone (useful for browse, but can be noisy).
- Standardize the format you will store. Use a consistent time zone format across all sources (for example, IANA time zones like America/Los_Angeles) and document it for whoever sends events into Customer.io.
- Write the value to a person attribute. Create a single canonical attribute (example: timezone) rather than multiple competing fields (example: tz, user_tz, shipping_tz).
- Backfill existing customers. If you have historical orders with addresses, backfill time zone for your customer base so campaigns do not default to workspace time.
- Set update rules. Decide when you overwrite the attribute. A practical rule is “most recent high-confidence signal wins” (shipping address beats IP, app device beats IP, and a new order beats everything).
- Apply local-time sending in key journeys. Update cart abandonment, browse abandonment, and post-purchase flows to use customer time zone for delays and time windows.
- QA with real profiles. Test with a few internal profiles set to different time zones and verify send-time behavior across channels.
When Should You Use This Feature
Geolocation and time zone data in Customer.io is worth prioritizing when timing is the difference between “helpful reminder” and “ignored noise.”
- Abandoned cart recovery across regions: If you sell nationally or globally, a single cart flow can underperform simply because half your audience receives messages overnight.
- Product discovery journeys: Browse abandonment that hits during lunch breaks and evenings tends to outperform messages that land during commute hours or late night.
- Post-purchase education and cross-sell: Sending “how to use it” content at a reasonable local time reduces unsubscribes and increases second purchase rate.
- Reactivation: Winback offers perform better when they land at the customer’s typical shopping time (often evenings and weekends) rather than your team’s send schedule.
Realistic scenario: a skincare brand runs a 3-touch cart recovery sequence (email at 1 hour, SMS at 6 hours, email at 24 hours). Without time zone control, West Coast shoppers get the 6-hour SMS at 2:00 AM if they abandon at 8:00 PM ET. With local-time sending and a “no sends between 9 PM and 9 AM” window, the SMS shifts to the next morning, improving conversion and reducing opt-outs.
Operational Considerations
Geolocation and time zone data in Customer.io impacts segmentation and orchestration, so you want clear ownership and predictable fallbacks.
- Fallback logic: Decide what happens when time zone is missing. Common approach is defaulting to the store’s primary time zone for domestic-only brands, or using country-level defaults for international brands.
- Time windows vs strict delays: If you use “wait 2 hours” and also enforce a time window, understand how messages shift. This matters for cart recovery where urgency drives conversion.
- Channel coordination: Email and SMS should share the same time window rules. Otherwise you will “fix” email timing but still wake people up with SMS.
- Data drift: People travel. If you use device time zone, you may shift sends unexpectedly. If you use shipping address time zone, you may be more stable but slower to update for movers.
- Reporting interpretation: When you shift sends to local time, day-part performance changes. Compare cohorts fairly (before vs after) and watch for changes in attribution windows.
Implementation Checklist
Geolocation and time zone data in Customer.io rolls out cleanly when you treat it like a shared data contract, not a one-off campaign tweak.
- Define the canonical person attribute for time zone (name, type, allowed values)
- Choose the source of truth and the overwrite rules
- Backfill time zone for existing customers and high-intent subscribers
- Set a missing-time-zone fallback strategy
- Update cart, browse, post-purchase, and winback journeys to use local time
- Align time windows across email, SMS, and push
- QA with test profiles in at least 3 time zones
- Monitor opt-outs, spam complaints, and conversion rate changes for 2 to 4 weeks
Expert Implementation Tips
Geolocation and time zone data in Customer.io becomes a revenue lever when you combine it with intent signals, not when you apply it universally.
- Use confidence tiers for time zone. In retention programs we’ve implemented for D2C brands, we tag time zone confidence (high from shipping address, medium from device, low from IP). Then we only let low-confidence time zones control SMS timing, because the downside of waking someone up is higher than an email arriving a few hours off.
- Pair time zone with “local-time optimized” holdouts. Run a holdout where 10 percent of shoppers receive the old timing, and 90 percent receive local-time timing. This isolates the impact of timing changes from creative changes.
- Cart recovery: protect the first touch. If you enforce a time window, keep the first cart email close to abandonment (example: 30 to 60 minutes) and apply stricter windows to later touches. That preserves urgency without sending late-night SMS.
- Reactivation: schedule to shopping rhythms. If your brand sees weekend spikes, use local-time windows that favor Friday evening through Sunday afternoon, then measure lift in repeat purchase rate.
Common Mistakes to Avoid
Geolocation and time zone data in Customer.io can quietly hurt performance if the underlying assumptions are wrong.
- Storing multiple time zone fields: Teams end up referencing different attributes in different journeys, which creates inconsistent send timing and messy QA.
- Letting IP-derived time zone overwrite shipping time zone: This is a common cause of “why did my customer get a midnight text” issues, especially with VPN usage.
- Applying time windows without revisiting delays: A “wait 2 hours” plus “only send 9 AM to 6 PM” can turn into “wait 14 hours,” which can kill cart recovery conversion.
- Fixing email timing but ignoring SMS: SMS is where timing mistakes create opt-outs fastest, so it needs the strictest governance.
- Not backfilling: If only new users have time zones, you will see inconsistent results and you will misread performance trends.
Summary
Use geolocation and time zone data when message timing directly impacts conversion, especially for cart recovery and reactivation. Done right, it improves revenue while reducing opt-outs and complaints. Build it once, then standardize it across journeys in Customer.io.
Implement with Propel
Propel can help you set up time zone governance, backfills, and channel-safe time windows inside Customer.io, then validate lift with clean testing. If you want a fast implementation plan, book a strategy call.