- Capacity planning — see which applications drive the most traffic and size uplinks accordingly.
- Policy tuning — if a single class of traffic dominates, consider adjusting Access Policies or bandwidth controls at the network layer.
- Abuse detection — unexpected long-running sessions for categories you don’t expect at a venue (peer-to-peer file sharing in an office, for example).

Requirements
- Service Gateway deployment. Application Visibility reads its classification data from the Service Gateway’s deep-packet inspection. Meraki-only integrations do not produce this data.
- Licensing on the Service Gateway. The underlying Cisco platform may require specific feature licenses to perform traffic classification. Coordinate with your Service Gateway provisioning.
What it shows
Application Visibility dashboards typically show:- Top applications by volume over a configurable time window.
- Category breakdowns — web, video, audio, cloud storage, social, etc.
- Per-venue splits when combined with Site-based redirects or multi-site deployments.
- Time-of-day patterns — when traffic peaks.
What it doesn’t do
Application Visibility is observational, not enforcement:- It does not block applications. That’s a Service Gateway policy layer, configured separately.
- It does not identify individual users — it aggregates traffic across active sessions.
- It does not replace a SIEM or a dedicated traffic analytics tool for security investigations.
Relationship to Statistics and Exports
The broader Statistics and Exports feature tracks who signed in. Application Visibility tracks what they did with the connection. The two complement each other.Related
Statistics and Exports
Login-level aggregates and reporting.
Cisco Service Gateway
The integration Application Visibility depends on.

