On this page

Mobility collection uses platform agents and deployments to produce WiFi observations. The collection plan determines which spaces and times are represented.

Use Prepare devices for mobile permissions and field preparation, Configure measurements for the deployment, and Verify collected data before interpreting a dashboard.

A useful pilot

Choose a limited set of spaces and a time window that can be checked by site staff. Identify the devices that will cover them, the expected cadence, and how the collected data will be checked. A repeated route through one building may leave another building unmeasured.

Record exceptions: a device that was offline, lacked location permission, or stopped WiFi scanning can change the evidence available for a period. Treat the absence of readings as a collection issue until investigated.

Prepare Mobility devices

Mobility WiFi collection depends on the Android device, its permissions, and where it is carried. First complete the shared Android agent installation.

Prepare a field device

  1. Confirm that the paired agent is assigned to the correct Lens location and carries the tags used by the Mobility deployment.
  2. Grant the app the location and WiFi-related permissions required on that Android version. Check the app’s status after each request.
  3. Review battery optimization and background execution with the device owner. Some manufacturers require an additional auto-start setting for reliable unattended collection.
  4. Enable the device capabilities required by the selected program and confirm that the planned route is safe and accessible.
  5. Take a short pilot route through known spaces before sending the device across the whole site.

Do not infer that a successful login or recent agent contact means the WiFi scan and position were captured. Permissions can affect those fields independently.

Verify the pilot

Check collected data for recent observations, positioned readings, and the expected spaces. If the agent reports but no usable readings appear, inspect the app’s permission state and the device’s battery restrictions.

Configure Mobility measurements

Use the platform deployment to assign a WiFi collection program and configuration to the tagged pilot devices. The program determines the observations; the location and spatial model determine their analysis context.

Define the pilot assignment

  1. Identify the Mobility program available in Manage → Programs and check that it supports the prepared Android devices.
  2. Review its configuration and any options that affect scan behavior or output meaning.
  3. Confirm agent tags and location assignments before selecting the target group.
  4. Create or adjust the deployment schedule and timeout for the pilot.
  5. Check the Agents view for assignment and synchronization, then wait for a scheduled run.

Choose a period long enough to include the planned route and normal device use. A fast schedule cannot compensate for devices that never visit an area, and an overly broad deployment may use battery on devices outside the pilot.

Verify the result

Use Verify collected data to confirm actual readings, not just agent status. Check the time, device, and area before extending the same deployment to more locations.

Verify collected Mobility data

Verify collection after the pilot route and whenever an analysis seems incomplete. Use a period that includes a known device run.

Check the evidence

  1. In Analyze → Report, select the location, period, and relevant agent or network. Confirm that the sample count is greater than zero.
  2. In Pulse, inspect Readings this period and How complete is this?. Separate areas with enough evidence from those marked too sparse or never measured.
  3. In Diagnose, review Agent and data-collection health for reporting, permission errors, and expected sample counts.
  4. Compare the map with the route the device actually took. An apparently blank area may have been skipped, lack positioning, or have too few observations for a verdict.

The fictional MareaClara Pulse example shows three measured Lobby areas beside one with too few readings. Its green areas describe the demo’s measured signal, not all possible WiFi experiences.

Verify recovery

If readings are missing, correct the device or deployment issue and repeat a short known route. A new metric, positioned in the expected area, verifies more than a renewed agent heartbeat alone.

Troubleshoot Mobility analysis

Start with the selected location and period. Most misleading conclusions begin with the wrong filter or a gap in collection.

SymptomCheckNext step
No samples in ReportPeriod, location, agent and network filtersWiden the filter, then verify collection
Agent is online but an area is unmeasuredDeployment, WiFi and location permissions, routeRepeat a known pilot route with a prepared device
Pulse shows a high score but many sparse areasCompleteness bar and counted readingsLimit the conclusion to measured areas
Map observations appear on the wrong floorFloor plan placement, area boundaries and device positionCorrect the spatial context or positioning issue
Compare suggests a change without clear evidenceDifferences in period and completeness across sitesOpen each site’s Pulse and Diagnose views

A hatched area indicates insufficient readings, not a failed network. Agent health concerns collection; it does not by itself measure guest experience.

Verify recovery

Repeat the relevant collection, confirm fresh positioned readings, and re-open the same view with the same filters. Record what changed in both the evidence and the interpretation.

Lens 2.0.0-SNAPSHOT · Published 2026-10-05