Your Retail AI Stack Is Missing One Data Source: Who Is Actually in the Store Right Now

Retail AI tools connected to live WiFi presence and footfall data in a store

First-party WiFi data can be a governed feed for retail AI. Wiacom turns the WiFi a store already operates into presence, footfall and consented first-party guest data, with consent, purpose and access controls in place, so AI tools can use it without the retailer losing control. It is available to AI tools through Wiacom’s API today, with an MCP server in development.

Retail AI is moving from dashboards to agents: assistants that answer questions, copilots that support store staff and automation tools that trigger campaigns. All of them are limited by the data they can reach.

There is one data source that almost none of them can reach: real-time physical presence. Who is in the store right now. Which zone they are in. How long they have been there. Whether this is their first visit or their tenth.

This data exists. It sits in the WiFi infrastructure that every store already operates. The gap is that most AI tools have no standard way to access it.

Why physical presence data matters for AI

The value of AI in retail operations is proportional to the richness of the context it can access. An AI scheduling tool that knows “Tuesday afternoons are historically busier” is useful. An AI scheduling tool that can see live footfall in real time and adjust recommendations accordingly is substantially more useful.

Operations — a store operations assistant that can query live zone occupancy makes staffing recommendations that reflect what is actually happening, not what happened last week.

Customer service — a retail copilot that can verify whether a known, consenting loyalty member is currently on-premises can surface relevant context at the point of service, without asking the customer to identify themselves again.

Campaign activation — a marketing automation tool that receives presence signals can trigger personalised offers the moment a known, consenting customer enters the venue, using first-party data already captured through Wiacom CDP and the WiFi portal.

Analytics — an AI analytics tool connected to WiFi presence data can surface anomalies, measure the impact of merchandising changes on dwell time, or identify which promotional placements actually shift traffic patterns. Wiacom’s Insights & Analytics already captures this footfall and dwell data.

Aggregate presence and consented identity

Presence data comes in two forms, and they should be treated differently:

  • Aggregate presence — occupancy, zone dwell time, footfall patterns and visit frequency across a venue. This does not need to identify anyone and suits staffing, merchandising and layout decisions.
  • Consented, identified presence — a registered guest or loyalty member who has agreed to the intended use. This is what supports personalised service or offers, and only where the guest’s consent and the applicable law allow it.

Devices that use randomised MAC addresses cannot be reliably recognised without sign-in, so identified presence depends on the guest registering or onboarding through Wiacom. AI tools should receive only what their configured permissions and consent rules allow, and Wiacom does not replace a retailer’s own legal review.

First-party data as a governed feed for AI

AI tools are only as useful as the data they can reach, and only as safe as the rules around that data. The aim is not to hand AI tools a database. It is to give them a governed feed of first-party data, with compliance applied before the data leaves Wiacom.

Identity → Consent → Eligibility → Governed feed → AI tool

In practice, a governed feed means:

  • Consent at the source — identity and consent are captured directly through WiFi onboarding, and consent for WiFi access is kept separate from consent for other purposes;
  • Purpose limitation — an AI tool receives only the data that is eligible for the purpose it is meant to serve;
  • Minimisation — aggregate or pseudonymous data where individual identity is not needed, and hashed identifiers where supported;
  • Access control — the Wiacom API requires strong authentication, and access can be restricted by source IP;
  • Consent changes that carry through — if a guest withdraws consent or becomes ineligible, the change should be reflected in what the feed provides;
  • Data model and residency chosen at deployment — Wiacom can operate as a secure data vault or as privacy-minimised middleware, and the hosting region is confirmed when the deployment is agreed.

The retailer also remains responsible for its own legal basis and for the AI provider it chooses: whether the provider uses data for training, where it processes it and what terms apply. Wiacom does not replace a retailer’s own legal review or its assessment of data protection law and, where relevant, AI regulation.

The standard that makes this possible

Model Context Protocol (MCP) is an open standard that allows AI agents and tools to connect to external data sources through a consistent, structured interface. Rather than requiring a custom integration for every AI tool, an MCP server exposes a defined set of capabilities that any MCP-compatible client can discover and use.

What is available today, and what is coming

Today, Wiacom already lets external systems and automation tools consume its data programmatically through a REST API and webhook events, with strong authentication and optional source-IP restriction. That is the integration path available now for retail copilots, analytics tools and automation platforms.

Wiacom is also developing an MCP server, so that MCP-compatible AI agents, including Claude and custom retail copilots, can discover and use presence, analytics and consent-aware guest data through a standard interface, subject to configured permissions. Retailers interested in early access can contact the Wiacom team.

The data already exists

The critical point for retail operators is that this is not a new data collection project. The WiFi infrastructure is already deployed. Guests are already connecting and registering. Footfall and dwell data are already being captured.

What API and MCP connectivity add is a structured way for AI tools to consume that data, without building a separate data-collection layer and without duplicating information across systems.

For retailers building or evaluating AI operations stacks, the question is not whether to collect presence data. It is whether the tools being evaluated can access the presence data that already exists.

Where this fits in the Wiacom platform

Presence, footfall and dwell data come from Insights & Analytics. Registration and consent are captured through Guest Connect and the captive portal, and Wiacom CDP holds first-party guest data. See how this applies to large retail and hypermarkets and shopping malls.

The same consented first-party data can also be activated as advertising audiences: see OpenAI Ads and Guest WiFi: Turning Physical Visitors into First-Party Audiences.

WiFi presence data for retail AI: frequently asked questions

What is physical presence data for retail AI?

Information about who and how many people are in a venue, which zone they are in, how long they stay and how often they return, drawn from the WiFi infrastructure the store already operates. It can be aggregate or, with consent, tied to a known guest.

How is first-party WiFi data kept compliant when AI tools use it?

Compliance is applied before the data reaches the AI tool: consent and purpose are captured at onboarding, only eligible data is included, aggregate or pseudonymous data is used where possible, access is authenticated and permissioned, and consent changes should carry through. The retailer remains responsible for its legal basis and for the AI provider it chooses.

Does Wiacom have an MCP server?

Wiacom is developing an MCP server for AI agents. Today, external systems and AI tools can consume Wiacom data through its REST API and webhook events.

Can AI tools identify individual shoppers from WiFi?

Only guests who have registered and given the relevant consent can be recognised as individuals. Anonymous presence is aggregate, and devices with randomised MAC addresses cannot be reliably recognised without sign-in.

Do retailers need to install new hardware?

No. Presence data comes from WiFi infrastructure the store already operates, including Cisco Meraki, HPE Aruba, Ruckus, UniFi and other compatible platforms.

Does this replace footfall counters or other sensors?

No. WiFi presence can be combined with counters, POS, loyalty and other sensors. Wiacom’s role is to provide the permissioned WiFi-based identity and presence signal.

Who controls what an AI tool can see?

The retailer. Access is authenticated and permissioned, and AI tools should only receive data their configured permissions and consent rules allow.


Wiacom provides WiFi presence, footfall and consented first-party guest data as a governed feed for retail analytics and AI tools through its REST API and webhooks, with an MCP server for AI agents in development.

Explore Wiacom’s API and webhooks → · Request a demo →