The instructions in this article utilize a ThousandEyes Virtual Appliance (TEVA) for demonstration purposes only. TEVAs are locked and permit only a subset of privileged commands to be run. Please use the guidance below for creating a self-signed cer...
Introduction 1. PowerShell Script Creation 2. SCCM Application Creation & Configuration >2.1 Create the Application >2.2 Specify SCCM Application Settings >2.3 Configure the PowerShell Script Execution in SCCM >2.4 Distribution Settings >2.5 Poduct C...
A Practical Guide for IT Professionals & Network EngineersAuthor: Raghavender Reddy PatiDate: March 25, 2026Version: 1.0Disclaimer: This whitepaper reflects the author's personal experience and opinions. It is not affiliated with or endorsed by Cisco...
Join us to explore practical automation solutions for Meraki networks through APIs, workflows, and Infrastructure as Code tools like Ansible and Terraform. This series will guide you in simplifying network configuration and management, enabling faste...
Introduction >What are Handlebars and why are they important? Understanding Handlebars for Webhook Alerts >Basic Handlebars Concepts >> 1. Expression ({{variable}}) >> 2. Context >> 3. Nested Data Access >Built-in Block Helpers - if, each, with >Adva...
Q. What is Catalyst Center Global Manager (CCGM)? Q. How does Catalyst Center Global Manager (CCGM) deliver business value to enterprises? Q. Which Catalyst Center features are supported in Catalyst Center Global Manager (CCGM)? Q. How many Catalyst ...
Introduction, Overview & Requirements MCP Workflow Overview Cursor MCP Client Capabilities Requirements Step 1: Configure the ThousandEyes MCP Server Step 2: Enabling or Disabling MCP Tools Step 3: Run your first ThousandEyes Workflow in Cursor Examp...
Introduction Why is this important? Pre-requisites & Assumptions Step 1: Setting up an OAuth Application Registry in ServiceNow Step 2: Integrations 2.0 Configuration on ThousandEyes Step 3: Configure ThousandEyes alerts to notify the Operation in Se...
Introduction Ways to regenerate ThousandEyes API tokens 1. Revoke the existing bearer token. 2. Create a new bearer token. 3. The step also involves passingMulti factor authentication (MFA), where a code would be sent to your email. 4. Then you’d nee...
Overview Step One: Validate Data from the Exporter Side > 1. NetFlow Configuration Comparison. > 2. Ensure NetFlow meets the minimum requirements. > 3. Verify NetFlow Transmission. Step Two: Confirm & Analyze Agent Packet Capture > 1. Initiate Captur...
Overview :With PIM Bidirectional, all packets move on the shared tree so RP redundancy is even more important than with PIM Sparse-Mode where RP failover has only an impact on newly active streams...Despite PIM SM, there is no point with PIM Bidir to...
Unlock the full potential of your network with our exclusive six-part Expert Insights Series, Elevate with Cisco Catalyst Center. Whether you’re looking to streamline operations, strengthen your security posture, or integrate advanced solutions, this...
Introduction Pre-Requisites & Assumptions Automatic Update Components Troubleshooting Automatic-Update Problems on Ubuntu > Troubleshooting APT auto-updates with ThousandEyes > ThousandEyes repository configuration >> Checking ThousandEyes APT reposi...
Understanding API calls API (Application Programming Interface) is a way for one program to interact with another. An API call or API request is a message sent to a server asking an API to provide a service or information. In our lab setup, since ...
Jump to Introduction The Problem: Long Scripts and Cumulative Timeouts The Solution: Two Tests in Parallel, Each Owning a Slice Example Scripts The Result Patterns from Production Environments Best Practices Visualizing the Complete Journey in a Sing...
If you've been asked to design a Cisco Spaces deployment, you've probably realized something quickly: this isn't just another wireless feature you toggle on. Cisco Spaces is a cloud platform that turns your existing Wi-Fi network into a sensor fabric — and the quality of what comes out of it depends almost entirely on how you design the wireless network underneath. AP density, AP placement, BLE coverage, the connection method to the cloud, the licensing tier, and the use case you're solving for all interact with each other.
This guide walks through the design principles, sizing decisions, and AP placement geometry you need to plan a Cisco Spaces deployment that actually works on day one. It's aimed at network architects and pre-sales engineers who already know wireless and want to understand how Spaces overlays on top of it.
Cisco Spaces is a cloud-delivered platform that ingests data from your wireless infrastructure (Catalyst 9800 controllers, Meraki MR access points, Catalyst switches, Webex devices) and turns it into indoor location, occupancy, and IoT outcomes. It's the evolution of MSE → CMX → DNA Spaces, now consolidated under a single brand.
In practice, Cisco Spaces does six things: locates Wi-Fi clients and BLE assets indoors, measures occupancy and behavior in real time and historically, onboards guests via captive portal and OpenRoaming, acts as an IoT gateway for BLE/Zigbee/Thread devices, runs rules and engagements (notifications, integrations with Webex/ServiceNow/Teams), and exposes everything through APIs for downstream systems.
There are two ways to get data from your wireless network to the Cisco Spaces cloud: the Cisco Spaces Connector or Direct Connect from the Catalyst 9800.
The Connector is a free virtual machine that aggregates data from your wireless controllers and forwards it to the cloud. One Connector handles up to 16 WLCs and supports the full Spaces feature set — Captive Portal, IoT Services, Hyperlocation, FastLocate, OpenRoaming, Asset Locator, and the rule engines for Right Now and Engagements. Communication to the cloud is outbound HTTPS only — no inbound rules required on your firewall.
This is the deployment model for any production network. If you're designing for a real customer, you're using the Connector.
The Catalyst 9800 can register directly with Spaces using the NMSP cloud-service, bypassing the Connector entirely. This sounds attractive — fewer moving parts — but it has a hard scale limit and a much-reduced feature set.
Direct Connect is positioned for proof-of-concept deployments and very small environments — typically up to 50 clients. There's no Captive Portal, no IoT Services, no OpenRoaming, no Hyperlocation. Use it for labs, EWC (Embedded Wireless Controller), Mobility Express, or quick demos.
Don't design production deployments around Direct Connect.
Meraki MR access points connect to Spaces directly through a cloud-to-cloud integration in the Meraki dashboard — no Connector required. The integration is enabled per Meraki network. Spaces ingests presence and location data and, with newer architecture, raw measurement data via MQTT for cloud-side X/Y compute.
| Aspect | Spaces Connector | Direct Connect (9800) | Meraki Cloud-to-Cloud |
|---|---|---|---|
| Recommended scale | Up to 16 WLCs per Connector | < 50 clients (PoC only) | Per Meraki org |
| Captive Portal | Yes | No | Yes |
| IoT Services / BLE Gateway | Yes | No | Yes (MR with BLE) |
| OpenRoaming / RadSec | Yes | No | Yes |
| Hyperlocation / FastLocate | Yes | No | N/A |
| Asset Locator | Yes | Limited | Yes |
| HA Model | VIP-paired or Active/Active | WLC HA-SSO only | Meraki cloud HA |
| Outbound from network | Single egress (Connector → cloud) | Each WLC opens HTTPS | Meraki cloud handles |
The Connector ships as an OVA (and Hyper-V VHDX, Nutanix, Azure, AWS AMI) in three sizes. Pick the size based on the number of APs you're aggregating, the services you'll run, and whether you'll be doing IoT/BLE in addition to location.
| OVA Type | vCPU | RAM | Storage | Recommended For |
|---|---|---|---|---|
| Standard | 2 | 4 GB | 60 GB / 120 GB | Location-only, small-medium deployments |
| Advanced 1 | 4 | 8 GB | 60 GB / 120 GB | Location-only large, or location + light IoT |
| Advanced 2 | 8 | 16 GB | 60 GB / 120 GB | Location + IoT combined, large enterprise |
Connector 3 requires an x86-64-v2 CPU (SSE3, SSE4_1, SSE4_2, SSSE3) running on ESXi 7.0/8.0/9.0, Hyper-V, Nutanix AHV, Azure (AVS or native), or AWS AMI.
| Connector Type | Use Case | Max APs | Client / Tag Count | Outgoing Message Rate |
|---|---|---|---|---|
| Standard | Location only | 9,000 | 90,000 (clients + RFIDs + rogues) | 21K NMSP msg/s |
| Advanced 1 | Location only | 15,000 | 150,000 | 38K NMSP msg/s |
| Advanced 1 | IoT only | 3,000 | 150,000 BLE tags | 25K BLE msg/s |
| Advanced 1 | Location + IoT | 12,000 (2K IoT + 10K location) | 100K clients + 20K BLE tags | 17K NMSP + 120K BLE msg/s |
| Advanced 2 | Location only | 25,000 | 250,000 | 44K NMSP msg/s |
| Advanced 2 | IoT only | 4,500 | 220,000 BLE tags | 40K BLE msg/s |
| Advanced 2 | Location + IoT | 18,000 (3K IoT + 15K location) | 150K clients + 30K BLE tags | 38K NMSP + 170K BLE msg/s |
The numbers above are ceilings!!! Real-world capacity is reduced by host CPU type, network latency to the cloud, and whether IoT MAC-prefix filtering is enabled. For deployments with significant BLE volume, consider deploying a dedicated Advanced-2 Connector for IoT and a separate Standard or Advanced-1 for location — isolating the IoT message firehose protects location accuracy at scale.
The Connector supports two HA models:
| Model | Behavior | When to Use |
|---|---|---|
| VIP-Paired (Active/Standby) | Two instances on the same L2/VLAN sharing a VIP via Keepalived/VRRP | Required for IoT Service HA, hotspot-cert continuity, captive portal |
| Active-Active | Both Connectors connect to all WLCs and forward to the cloud; cloud de-duplicates | Location-only deployments where load distribution matters more than feature continuity |
Choose VIP-Paired if you have IoT Services or captive portal in scope. Active-Active is fine for pure location deployments. Maximum two tokens per Connector pair — adding a third causes hotspot certificate issuance to fail.
All cloud communication is Connector-initiated outbound. No inbound from the internet to the Connector is required.
| Port / Protocol | Destination | Purpose |
|---|---|---|
| TCP 443 (HTTPS) | Regional Spaces endpoints | Telemetry, control plane, app data |
| UDP/TCP 53 | DNS server | Name resolution |
| UDP 123 | NTP server | Time sync (mandatory) |
Regional endpoints:
connector.dnaspaces.io / connect.ciscospaces.ioconnector.dnaspaces.eu / connect.ciscospaces.euconnector.ciscospaces.sg / connect.ciscospaces.sg| Port / Protocol | Direction | Purpose |
|---|---|---|
| TCP 16113 (NMSP) | WLC → Connector | Location telemetry over TLS |
| TCP 830 (NETCONF/SSH) | Connector → 9800 | Configuration push, model-driven telemetry |
| TCP 8004 (TDL) | 9800 → Connector | Streaming telemetry |
| TCP 22 (SSH) | Connector → WLC | Optional management |
| Port / Protocol | Direction | Purpose |
|---|---|---|
| UDP 2003 | AP → Connector | FastLocate RSSI streams |
| TCP 8000 (gRPC) | AP → Connector | IoT BLE gateway |
| TCP 8443 | Connector → AP | IOx app install |
| TCP 443 | Connector → AP | REST API |
| Port / Protocol | Purpose |
|---|---|
| TCP/UDP 1812, 1813 | RADIUS auth/accounting |
| TCP/UDP 2083 (RadSec) | OpenRoaming federated auth |
| TCP 443 | Splash page assets (region-specific Spaces IPs) |
This is where Spaces deployments succeed or fail. You can have the right Connector, the right license, and the right cloud configuration — but if the wireless underneath isn't designed for location, the platform produces noise instead of intelligence. This section is the longest in the guide because it deserves to be.
Indoor location accuracy depends on AP density and placement geometry
For Cisco Spaces to compute an accurate position for any device — Wi-Fi client or BLE tag — three conditions must be true simultaneously:
This is why "we have great Wi-Fi coverage, why isn't location working?" is one of the most common Spaces support tickets. Coverage is not the same as location!!! Coverage means one AP can serve a client. Location means three or more APs can simultaneously hear a client well enough to triangulate. These are very different design requirements.
Cisco's design framework for location-capable wireless networks splits into three classes — A, B, and C — each progressively denser and more capable. Pick the class that matches your use case, then design to it.
This is a standard wireless design optimized for data throughput. APs are spaced ~12 m (40 ft) apart, placed centrally in coverage zones, no perimeter reinforcement. It produces excellent connectivity, but for Spaces it only delivers presence-based outcomes — building-level and floor-level occupancy, behavior metrics, basic Right Now widgets.
Don't expect zone-level location accuracy with Design A. You won't get it. Devices near the perimeter walls will be heard by only one or two APs, fail the convex hull test, and either show up at the wrong location or not at all. If you tell a customer they're getting Design A and then promise them asset tracking, you're going to have a difficult conversation in three months.
Use Design A when: Spaces is a lightweight overlay for occupancy reporting only, the WLAN was already designed for connectivity and you can't justify additional APs, or the use case truly is presence-only (e.g., "how many people came into the building today").
This is the workhorse design for most Spaces deployments. AP spacing remains ~12 m, but you add perimeter APs along all exterior walls and around major obstacles (elevator shafts, atriums, large structural elements). The result is roughly 1.4× more APs than Design A — a 60 m × 60 m floor goes from ~25 APs to ~36.
The perimeter APs solve the convex hull problem. Now devices anywhere on the floor are surrounded by APs on all sides, and trilateration works at the walls and corners as well as in the center. You'll get X/Y location accuracy in the 5–10 meter range with RSSI, and 3–5 meters with FastLocate.
Use Design B when: the customer needs zone-level occupancy (Space Utilization, Right Now per zone), basic asset tracking with BLE tags (room or area-level — "the laptop is in the IT lab"), real-time captive portal triggering tied to specific zones, or marketing/engagement rules that fire when devices enter/leave defined areas.
This is the design for use cases that require room-level or sub-room accuracy. AP spacing tightens to ~10 m (33 ft), perimeter coverage is mandatory, and the convex hull is enforced everywhere on the floor. AP count is roughly 1.9× Design A — that 60 m × 60 m floor now needs ~49 APs.
With Design C, you can deliver: high-precision asset tracking ("the ventilator is in Room 312, not on the third floor"), AP-only BLE wayfinding (no floor beacons required), zone-level occupancy with very small zones (individual meeting rooms, bays, alcoves), and Hyperlocation-grade accuracy when paired with Hyperlocation hardware.
Use Design C when: asset tracking has a clinical, financial, or operational SLA (hospital equipment, manufacturing tools, retail high-value inventory), wayfinding through a mobile app needs to deliver turn-by-turn navigation, or you're solving for high-density occupancy analytics in venues with many small rooms.
| Design Class | AP Spacing | Perimeter APs | Coverage per AP | Density Multiplier | Typical Use |
|---|---|---|---|---|---|
| A — Connectivity | ~12 m / 40 ft | No | ~150 m² | 1.0× | Presence, behavior, basic occupancy |
| B — RTLS | ~12 m / 40 ft | Yes | ~100 m² | 1.4× | Zone occupancy, asset tracking, captive portal triggers |
| C — Advanced | ~10 m / 33 ft | Yes (convex hull enforced) | ~75 m² | 1.9× | Room-level accuracy, wayfinding, high-precision RTLS |
The math is straightforward once you know your floor area and design class. Below are realistic examples for each major venue type.
Real-world venues drive different design class decisions
A typical open-plan office floor with meeting rooms around the perimeter, 2.7–3.0 m drop ceilings, drywall partitions.
| Design | AP Count | Outcome |
|---|---|---|
| A | ~25 APs | Floor-level occupancy, Behavior Metrics, OpenRoaming |
| B | ~36 APs | Zone occupancy per neighborhood, hot-desking via Smart Workspaces, room-level Right Now |
| C | ~49 APs | Per-meeting-room occupancy, individual desk presence, BLE wayfinding |
For corporate hybrid-work deployments, Design B is the sweet spot. It supports hot-desking, room booking integration with Webex, Space Utilization analytics, and reasonable asset tracking for laptops/tags — without the cost overhead of Design C. Save Design C for executive floors or labs where you genuinely need per-room precision.
A clinical floor with patient rooms along corridors, nurse stations, treatment rooms. Ceilings often higher (3.5–4.0 m), more concrete and metal in walls (X-ray shielding, medical gas piping), heavy RF interference.
| Design | AP Count | Outcome |
|---|---|---|
| A | ~22 APs | Not recommended for hospitals — won't support asset tracking |
| B | ~32 APs | Bed-level zone tracking, ward occupancy, basic asset visibility |
| C | ~44 APs | Room-level asset tracking (ventilators, infusion pumps, beds), staff duress, patient flow analytics |
Hospitals almost always require Design C. The use cases — locating expensive shared equipment, demonstrating regulatory compliance for asset tracking, supporting patient flow analytics, and meeting clinical workflow SLAs — depend on accuracy. Add to this the RF challenges (concrete walls, medical equipment interference, metal carts everywhere) and Design B often degrades to Design A in practice. Plan for Design C and validate with a predictive survey.
Large open spaces, very high ceilings (8–15 m), reflective surfaces (glass, polished floors), seasonal occupancy spikes (10–50× variation).
| Design | AP Count | Outcome |
|---|---|---|
| A | ~107 APs | Gate-level presence, dwell-time analytics |
| B | ~150 APs | Zone occupancy (security line, gate seating, retail concessions), captive portal targeting per zone |
| C | ~213 APs | Per-seat-cluster occupancy, advanced wayfinding from check-in to gate |
Airports introduce a special challenge: ceiling height. APs mounted at 8–10 m have very different propagation than the standard 2.7 m office model the AP datasheets assume. Coverage radius increases (more area per AP), but RSSI dynamic range compresses (the difference between –40 dBm and –70 dBm shrinks at distance), reducing trilateration accuracy. Design B with directional or down-tilt antennas often produces better location results than Design C with standard omnis at high mount points. Consider Cisco APs with internal antennas designed for high-ceiling deployment, or external-antenna APs paired with appropriate antenna selection.
Guest room corridors with rooms on both sides, lobbies and meeting spaces on ground floors.
| Design | AP Count | Outcome |
|---|---|---|
| A | ~7 APs | Floor-level occupancy, OpenRoaming for guest onboarding |
| B | ~10 APs | Per-corridor zone presence, captive portal with branded engagement, behavior metrics |
| C | ~13 APs | Per-room presence (where corridor APs can hear into rooms) |
Hotel guest floors are usually Design A or B. True per-room location through guest room walls is unreliable — drywall passes RF reasonably, but bathroom plumbing, mirror backings, and metal door frames disrupt it room-to-room. The realistic outcome is corridor-zone presence plus excellent OpenRoaming for guest onboarding. For lobby areas, conference floors, and ballrooms, design those specifically as Design B or C — they're high-value engagement zones, not corridors.
Open retail floor with department zones, fitting rooms, checkout, displays. Mostly drywall, some concrete columns.
| Design | AP Count | Outcome |
|---|---|---|
| A | ~40 APs | Store-level footfall, dwell time, Behavior Metrics |
| B | ~57 APs | Department-zone analytics, captive portal with location-based offers, customer journey |
| C | ~80 APs | Aisle-level analytics, advanced wayfinding, fitting-room dwell time |
Retail typically lands at Design B, with Design C reserved for flagship stores or anchor tenants where the marketing-team ROI justifies the AP density. Be careful with Design A in retail — Behavior Metrics can show meaningful trends but the absolute counts are unreliable for reporting to a CFO. If the customer is making merchandising decisions on Spaces data, you need Design B at minimum.
Large open spaces, high ceilings (6–10 m), metal racking, forklift traffic, RF-noisy industrial equipment.
| Design | AP Count | Outcome |
|---|---|---|
| A | ~80 APs | Zone-level worker presence (very rough) |
| B | ~115 APs | Aisle-level asset tracking, worker safety, equipment visibility |
| C | ~160 APs | Pallet-level asset tracking, real-time WIP visibility, integration with WMS |
Warehouses and manufacturing floors are similar to airports in that high ceilings change the RF propagation model. Add the rack effect — metal shelving creates RF canyons where signals bounce along aisles but don't propagate across them — and AP placement becomes critical. Mount APs in aisle centers, not above racks, or accept that you'll have an aisle-by-aisle location grid. Design B with careful aisle-centric placement often outperforms Design C with naïve grid placement.
Standard AP datasheets assume 2.7–3.0 m ceilings. Above 5 m, coverage radius grows but trilateration accuracy shrinks. Design for the highest ceilings in your venue separately — don't use a single density model across an office floor and a 12-meter atrium.
Open spaces (warehouses, atriums, lobbies) need lower density per square meter than partitioned spaces (offices, hospitals, hotels) — but they need APs in the open volume, not at the perimeter. Don't only mount APs on perimeter walls in a 30 m × 30 m open lobby — RF will coverage-cover but not location-cover.
BLE has ~1/3 the range of Wi-Fi at similar transmit powers. If you're using AP-based BLE for asset tracking, you need denser AP placement than what Wi-Fi alone would require. Design B Wi-Fi with the same APs becomes Design C BLE in practice. Plan for this in mixed-use deployments — or supplement with floor beacons in corridors and large rooms.
Cisco's recommended AP families for Spaces deployments today:
| AP Family | Best For | Key Capabilities |
|---|---|---|
| Catalyst 9136 / 9166 (Wi-Fi 6E/7) | High-density office, enterprise | Wi-Fi 6E/7, BLE 5, IoT IOx, FastLocate, AI/RRM |
| Catalyst 9164 (Wi-Fi 6E) | Standard enterprise, hospitality | Wi-Fi 6E, BLE 5, IoT IOx, indoor environments |
| Catalyst 9162 (Wi-Fi 6E) | Branch, smaller deployments | Wi-Fi 6E, BLE, lower port count |
| Catalyst 9130 (Wi-Fi 6) | Established Wi-Fi 6 deployments | Wi-Fi 6, BLE 5, IoT IOx, Hyperlocation module support |
| Catalyst 9120 (Wi-Fi 6) | Mid-tier offices | Wi-Fi 6, BLE 5, IoT IOx |
| Meraki CW9162 / CW9164 / CW9166 | Cloud-managed Meraki deployments | Wi-Fi 6E, BLE, MQTT location |
| Meraki MR46 / MR56 / MR57 | Cloud-managed Wi-Fi 6 | BLE, location, Spaces integration |
Avoid for IoT/BLE deployments: 9105, 9115, 9117, 1815, 1840, and the older 4800. They're functional for Wi-Fi but not recommended for BLE-based asset tracking — their BLE radios or IOx capability has limitations.
For Hyperlocation (sub-meter accuracy via Angle of Arrival), legacy 3700/3800/4800 with the Hyperlocation antenna module remain the deployment option, with 9130 supporting newer Hyperlocation methods. For UWB-based location (sub-meter without specialized AoA modules), look to the latest Cisco UWB-capable AP and tag combinations — this is the direction the platform is heading.
On the Catalyst 9800, every AP feeding location data into Spaces must be assigned to a custom site tag!!! The default site tag (default-site-tag) does not generate ranging data for Spaces. This is the single most common reason "all my APs are on the controller, why are they not in Spaces?" — they're in the default site tag.
Build a site tag per location (per building or per floor depending on size), assign every AP to one, and verify before going live.
After deployment, validate accuracy before handing over to operations:
If accuracy is poor, the corrective levers in priority order are: add perimeter APs → increase density toward Design B/C → fix AP placement on the map → add Inclusion/Exclusion zones → enable FastLocate → upgrade to Hyperlocation hardware.
Cisco Spaces is a portfolio, not a single app. Map the customer's business outcome to the right app, then size and design accordingly.
| Business Need | Spaces App | Type |
|---|---|---|
| How many people are in Building 7 right now? | Right Now | Real-time |
| How is the campus utilized this quarter? | Space Utilization | Historical |
| Where is my client/laptop/phone right now? | Detect & Locate (SEE) | Real-time |
| Show me where this device went yesterday | Detect & Locate (ACT) | Historical + API |
| Track 5,000 BLE asset tags with battery telemetry | Asset Locator + IoT Services | Both |
| Manage BLE floor beacons and 3rd-party sensors | IoT Services / IoT Explorer | Both |
| Onboard guests with a branded splash page | Captive Portal + Engagements | Real-time |
| Send a Webex notification when density > 80% | Density Rules / Engagements | Real-time |
| Hot-desking and room booking with Webex devices | Smart Workspaces | Both |
| Indoor wayfinding via mobile app | Indoor Navigation SDK + AI Maps | Real-time |
| Federate Wi-Fi onboarding across venues | OpenRoaming | Real-time |
| Stream raw events to my data lake / Splunk | Firehose API / Meta API | Real-time |
Right Now counts associated devices (not probing) over the last vertical-defined window: Workspace and Education verticals use 8–10 hour sessions; Retail uses 3 hours. The number you see is "associated devices in the last N hours" — this is close to a true headcount in workspaces (everyone's badged in and connected) but a rough proxy in retail (many visitors don't connect at all).
Space Utilization is historical only and only available for Workspaces and Education verticals. For retail/healthcare, you'd use Behavior Metrics + Right Now instead.
Behavior Metrics uses associated user IDs as a proxy for actual visitor counts. In workspaces this correlates strongly with badge data; in retail with low connection rates it's good for trends but limited for absolute numbers. Set this expectation in pre-sales conversations to avoid surprises later.
A successful Cisco Spaces design is fundamentally a wireless design problem with a cloud platform attached. The Connector sizing, license tier, and app selection are mostly mechanical decisions — the real design work is in AP density, placement, and validation.
Pick the design class that matches the use case (A for connectivity-led, B for standard location and zone analytics, C for high-precision asset tracking and wayfinding), validate with a predictive survey, build out perimeter APs to satisfy the convex hull rule, assign every AP to a custom site tag, and walk-test before handover. Get those things right, and Spaces becomes the platform the customer expected. Get them wrong, and no amount of cloud configuration will save the deployment.
Two configurators are available to help validate your design before you order hardware:
Stefan Mihajlov