Vemco and Power BI: Bringing Footfall and Occupancy Data into Business Intelligence

Most retail BI teams already have a conversion metric in Power BI. The problem is where the denominator comes from. In a surprising number of organizations, footfall still arrives as a weekly CSV that someone downloads from a vendor portal, renames, drops into SharePoint, and hopes the column headers haven't changed. The revenue side of the conversion ratio refreshes automatically from the ERP every night; the traffic side depends on a person remembering to click a button. That asymmetry is the real reason footfall reporting breaks down — not sensor quality, not dashboard design.

This is the gap the Vemco and Power BI integration is built to close. It is deliberately an export integration: data flows from Vemco out to Power BI, into models your analysts own. Vemco does not try to become your BI tool. Your footfall data belongs in your BI stack, alongside revenue, staffing rosters and marketing spend — not locked in a separate silo with its own login and its own charts nobody reconciles against finance.

Three ways the data gets into Power BI

There are three practical routes, and the right one depends on your team's tooling maturity rather than on Vemco.

• VemFusion / REST API at api.vemcount.com. This is the route most IT teams end up on. Power BI can call the REST endpoints directly through Power Query, or — more commonly at scale — a lightweight pipeline (Azure Data Factory, Fabric Dataflows, a scheduled Python job) pulls from the API into a lakehouse or SQL layer that Power BI reads. Endpoints cover footfall, occupancy, heatmaps, zones, events and full historical data, so you can backfill years of traffic on day one rather than starting your trend lines from the integration date.
• Scheduled API exports. If you would rather receive than fetch, Vemco pushes data on a schedule you define. Useful when your BI environment sits behind network restrictions that make outbound polling awkward.
• Scheduled CSV exports. The pragmatic option for teams without engineering capacity. Automated CSVs land in a location Power BI already reads from. Not glamorous, but it removes the manual download step, which is the step that actually fails.

The division of responsibility is clean: Vemco guarantees data quality at the source, and your analysts keep full control of modelling, joins and visuals inside Power BI. No black-box transformations between the sensor and your semantic model.

What changes when footfall sits in your own data model

The interesting analysis never happens inside a footfall dashboard. It happens at the joins. Once traffic and occupancy live as fact tables in your Power BI model, sharing a date dimension and a location dimension with everything else you report on, questions that used to require a spreadsheet exercise become measures:

• Conversion by hour and store — transactions divided by entries, sliced by the same store hierarchy finance already uses, so nobody argues about which store list is correct.
• Staff-to-traffic alignment — join footfall to rostering data and you can see, per store, the hours where traffic peaks and staffing doesn't. This is usually the fastest payback of the whole integration.
• Marketing attribution with a denominator — did the campaign raise traffic, or just conversion among the traffic you already had? Without footfall in the model, you can't tell the difference.
• Zone and heatmap analysis against category sales — zone-level counts joined to category revenue show whether a low-performing category has a demand problem or a placement problem.
• Occupancy for property teams — for landlords and mixed-use operators, occupancy data feeds tenant reporting, lease negotiations and facility planning from the same model, with row-level security controlling who sees which tenant.

Danish department store chain Magasin runs exactly this pattern — Vemco data exports feeding its business intelligence reporting — which is a useful reference point if you need to convince stakeholders that this is an established approach rather than an experiment.

A practitioner's note on modelling occupancy

One thing implementers learn quickly: footfall and occupancy are not the same shape of data, and treating them the same in your model causes wrong numbers that look plausible. Footfall is additive — you can sum entries across hours, days and stores. Occupancy is a point-in-time state. If you drop occupancy into a matrix and let Power BI's default SUM aggregation run, a store that held 40 people all day will show an "occupancy" of several hundred. You need explicit DAX measures — average, peak, or occupancy at a specific timestamp — and ideally a semantic model annotation so self-service users don't sum it by accident. Decide this at design time, not after an executive has screenshotted the wrong number.

Similarly, agree your grain up front. Pulling data at 15-minute or hourly grain and aggregating up in the model is almost always better than pulling daily totals, because staffing and queue analysis need intraday resolution and you cannot reconstruct it later. Full historical data is available through the API, but re-ingesting at a finer grain months into a project is avoidable rework.

Can you trust the numbers enough to budget against them?

This is the question executives actually ask, and it deserves an honest answer. Vemco commits to a contractual minimum of 96% counting accuracy, and in practice achieves 98–99% when conditions — lighting, store layout, visitor behaviour — allow. That contractual floor matters more than the headline figure: it means accuracy is a commitment you can hold the vendor to, not a marketing claim. For BI teams, it also means the input data has a defined quality baseline, which is more than can be said for plenty of sources already feeding your dashboards.

Scale is the other trust factor. Vemco Group, founded in Denmark in 2005, processes more than 85 million counts per day across 2000+ customers in 95+ countries. The platform is sensor-agnostic and built as an open data platform, which has a concrete consequence for IT teams: if you switch or mix sensor hardware across your estate, your Power BI integration and data model don't change. The API contract stays stable while the hardware layer underneath can vary by site.

A realistic rollout sequence

• Week one: connect to api.vemcount.com or set up a scheduled export for two or three pilot stores; land raw footfall and occupancy at hourly grain.
• Week two: conform the location dimension to your existing store master, build the occupancy measures correctly, and backfill history.
• Week three onward: add the joins — POS, rosters, marketing calendar — and put one conversion-by-hour page in front of a district manager. Iterate from their questions, not from a requirements document.

The value here isn't a new dashboard. It's removing manual downloads and copy-paste entirely, so traffic data flows into the reporting environment your organization already runs on, at the same cadence and reliability as your financial data. Once that's true, footfall stops being a separate report someone circulates and becomes a dimension of every decision the business already makes in Power BI.

Want footfall and occupancy in your Power BI dashboards? Talk to us about API and export options — whether that's VemFusion, the REST API or scheduled CSV feeds for your environment — at vemcogroup.com/contact-us.