A guest asks the AI Concierge, “Where can I get a massage?” The answer recommends the spa, and they request directions. Their question and route request suggest interest, but the property may not know whether they reached the spa or made a reservation.
Phunware is developing Location Aware Analytics (LAA) to produce location data using its existing indoor positioning technology. That data could show whether a device reached the spa after someone requested directions in the app.
The location-aware data layer connects that data with other information the property has about its guests. Supported booking and transaction integrations could add a reservation or purchase to the journey.
This is where location-aware personalization needs more than just an app interaction. Phunware’s Guest Intelligence Platform brings mobile, location, and property information together. IT teams evaluating this approach need to understand what the location data could show, how it would connect with other records, and which permissions each user would require.
What Location Analytics Adds to Guest Data Personalization
A property management system (PMS) holds stay details, a point-of-sale system (POS) records purchases, and a booking system holds reservations. Together, these records can show what was booked or bought, though they may leave out the questions and movement that came before it.
App activity does add some of that context. For example, a guest might open the spa page, ask about a massage, or request directions. The property can see those interactions where they’re recorded, but still needs another source to establish whether the device reached the spa area.
Location analytics could help fill that gap. For first-party guest data, IT teams need to establish which events are recorded, how records could be associated with the same device or guest, and what permissions govern those connections.
How Indoor Positioning Supports Location-Aware Personalization
In a deployment that uses Bluetooth Low Energy (BLE) beacons, a guest’s phone detects signals from beacons around the property. Because their physical locations are known, those signals help the positioning system estimate where the device is indoors and update the blue dot on the map.
Blue-dot indoor wayfinding uses that position to guide guests through the property. As someone walks from the lobby toward the pool, spa, or restaurant, their device’s changing position could also provide data for location analytics.
LAA could use this data to help identify entry into an area, time spent there, or movement between destinations. The usefulness of each measure would depend on coverage, position accuracy, reporting capabilities, and permissions. To report entry into the spa area, for example, the system would need to distinguish that event from a device passing nearby.
Timing matters for real-time guest personalization. IT should establish how quickly location events become available and whether they’re current enough for the intended use.
From a Guest Question to a Visit
Phunware’s AI Concierge can answer property-specific questions and connect guests to maps and directions. In the massage example, the question, recommendation, and route request give the property several interactions to examine.
LAA could show whether the device reached the spa area and how long it stayed. With supported booking or transaction integrations, the location-aware data layer could connect that location data with a reservation or purchase record.
The meaning of each event needs to stay clear. A device entering the spa area might belong to someone asking a question at reception, waiting for another guest, or arriving for a treatment. A reservation would add useful context, though it wouldn’t establish that the concierge recommendation caused the booking.
The following example can help IT teams review the proposed journey and confirm which steps a deployment supports.
| Step | Possible input | What IT should verify |
| Permission | App, location, and data-use choices | Which uses are permitted, and what works when location access is off? |
| Interest | Concierge question, recommendation, or venue page view | Which interactions are recorded, and how are they identified? |
| Position | Indoor location estimate and property map | What accuracy, coverage, and update intervals are supported? |
| Location event | Area entry, time in an area, or movement between venues | How is each event defined and distinguished from passing nearby? |
| Reservation or purchase | Booking or transaction record | Can it be associated with earlier activity through a supported, permitted connection? |
Connecting Location Analytics With a Hospitality Data Layer
IT teams evaluating a hospitality data layer need to understand what each system contributes and how its records relate. Location events, app interactions, stay details, and transactions may use different identifiers and update at different intervals.
Phunware’s platform is designed to complement existing property technology, so a resort may be able to keep its PMS, POS, and guest app. IT still needs to map each connection before it can judge the work involved.
For the spa example, start with the system that holds the reservation or purchase. Establish how its records could be associated with earlier app and location activity, and confirm whether the integration reads records, changes them, or supports both functions.
A data-flow diagram should cover interfaces, identifiers, authentication, refresh intervals, error handling, and monitoring. It should also make clear what happens when a source is unavailable or records can’t be matched reliably, so teams know where the reporting has gaps.
What Location Aware Analytics Could Show Operators
Location-Based Marketing in Hospitality
A restaurant promotion offers another journey to examine. Phunware’s existing Mobile Engagement analytics can show whether a guest opened the notification or viewed the restaurant page. LAA could add whether that device later entered the restaurant area.
For location-based marketing in hospitality, this could help teams compare response in the app with movement toward a venue. The location-aware data layer could connect those events with a purchase through a supported transaction integration and a reliable record match.
The offer itself should reflect current property information and the guest’s notification choices. When evaluating real-time guest personalization, look at whether guests find the information useful and what they do afterward. Sending more messages doesn’t establish that the experience has improved.
Movement Between Venues
Location analytics could help teams examine movement from a convention center to a restaurant, or between the lobby, pool, and spa. Those patterns could give operators a starting point for investigating venue visibility and routes across the property.
Operating hours, events, capacity, and transaction records would help explain the patterns. Time spent in an area could reflect a visit, a wait, or movement through the space, so teams would need that wider context before deciding what to change.
Guest Data Personalization Requires Clear Governance
When reviewing privacy-compliant guest data, look at what the app collects and how each team plans to use it. Showing a blue dot, reporting movement, and associating location history with a stay or transaction serve different purposes. Legal, privacy, security, and IT teams should review each intended use.
For first-party guest data, establish what guests are told, what choices they have, who can access the records, and how long the information is kept. Some questions may be answered through aggregated events; others may require identifiable records and a separate review of that use.
These choices need to work in the app, too. Confirm what information and navigation remain available when precise location is off, how guests change their preferences, and how those changes affect collection and reporting.
Measure App Activity, Visits, and Transactions Separately
Start with one journey, such as a spa recommendation or restaurant promotion, and establish a baseline before introducing new analytics. Use the events that can be measured reliably, including questions, page views, direction requests, and notification opens.
Where LAA supports them, add clearly defined location events such as area entry or time spent there. Keep reservations and purchases separate unless supported integrations provide those records.
Every rate needs a denominator. A venue-entry rate should identify the eligible devices or interactions counted, while a purchase rate needs a reliable transaction match. The report should also account for devices without location access, gaps in coverage, and unmatched records.
To assess revenue impact, compare results with a suitable baseline or control group and account for changes in promotions, pricing, and venue availability. A more complete journey gives teams more to work with, but doesn’t establish incremental revenue by itself.
Plan Location Aware Analytics Around Your Property
A guest’s question tells the hotel what they’re looking for, but it doesn’t show whether they reached the venue or made a reservation. LAA produces location data using the indoor positioning behind blue-dot wayfinding, which could show where their device went. With supported integrations, the location-aware data layer could connect that data with app activity and guest records to show whether a reservation or purchase followed.
Bring your property map and one use case to the IT review. Ask which events are available today, which are planned, what integrations are required, and how reporting handles missing or uncertain data.
Schedule a Strategy Session with Phunware to discuss your location infrastructure, reporting needs, integrations, and measurement plan.
