Video Analytics: What Procurement Teams Need to Know

Procurement teams often treat video analytics as a single line item. This approach leads to budget overruns and failed projects. Analytics is a set of distinct capabilities. Each capability solves a different operational problem. A system that detects a person crossing a fence line differs significantly from a system that recognizes a specific vehicle. The gap between these two functions affects hardware selection, network design, and data storage.

This guide breaks down video analytics into practical categories. It explains how each capability influences sourcing decisions. The focus remains on what procurement teams need to verify. The goal is to translate vendor marketing into specific technical requirements.

What does video analytics actually do

Video analytics processes video streams to identify objects, events, or patterns. It moves beyond simple recording. Traditional cameras capture an image. Analytics software interprets that image. The output is a trigger. A trigger might be an alarm, a log entry, or a notification to an operator.

The core distinction lies in the level of intelligence required. Basic analytics rely on pixel changes. Advanced analytics rely on computer vision models. Basic methods detect movement. They flag any change in a defined zone. Advanced methods classify what moved. They identify cars, trucks, people, or bags.

Procurement teams must identify which level is required for the site. A parking lot may only need vehicle presence detection. A high-security perimeter may need to distinguish a worker from an intruder. The answer changes the total cost of ownership.

How to define your specific use case

Before contacting vendors, define the exact event you need to catch. “Find suspicious activity” is not a use case. “Alert an officer when a vehicle stops at the gate for more than three minutes” is a use case.

Write down the following details for each site:

1. The object to detect.
2. The specific action or state.
3. The location or zone.
4. The required response time.
5. The acceptable error rate.

A specific use case prevents scope creep. It also helps vendors price the solution accurately. Vendors can match their analytics engine to the requirement. If the requirement is vague, vendors will propose their most expensive package. This includes features the site will never use.

Edge versus cloud processing

The processing location affects the procurement structure. Edge processing runs the analytics engine on the camera or a local server. Cloud processing sends video to a remote data center for analysis.

Edge processing reduces bandwidth consumption. It also lowers latency. The system reacts faster. This matters for real-time alarm scenarios. Cloud processing offers centralization. It allows easy updates and scalability across many sites. However, it requires a stable internet connection. It also raises privacy concerns regarding data transmission.

When sourcing, ask where the model runs. If the vendor says “hybrid,” ask which tasks run where. Do not assume the camera handles all processing. Some systems send raw video to the cloud for complex recognition. This increases the monthly service cost.

Evaluating vendor claims and terminology

Vendors use terms like “AI,” “smart,” and “intelligent” without definition. These terms hide the actual capability. You need to ask for the specific algorithm type.

Common terms and what they imply:

Term	Typical Capability	Procurement Question
Motion Detection	Pixel change in a zone	Does it trigger on shadows or leaves?
Object Classification	Identifies cars, people, animals	What object classes are supported?
Attribute Detection	Color, size, direction	Can it detect a red car moving north?
Face Recognition	Identity matching	What is the accuracy rate in low light?
Loitering Detection	Duration based alert	How is the dwell time calculated?
License Plate Reading	Text extraction from plates	What is the minimum distance for accuracy?

Ask for sample reports. Request a test video of a similar environment. Ask the vendor to run their engine on your footage. If they refuse or cannot provide a demo, treat the claim with caution.

Hardware and network requirements

Analytics features place specific demands on hardware. A camera that runs heavy object classification consumes more processing power. It may generate higher heat levels. It may require more power than a standard recording camera.

Network bandwidth is the next factor. If the system processes video locally, the network only carries the stream to the recorder. If it sends video to a cloud service, the network carries the full resolution stream. This can double or triple the bandwidth requirement.

Check the camera specifications. Look for the number of streams it can output. Some cameras output one stream for recording and a second for analytics. Some output only one. The analytics engine needs a clear, high-quality image. Blurry footage reduces accuracy.

Consider the storage implications. Analytics systems often store event clips rather than continuous video. This saves space. But it requires the system to trigger and save the correct clip. If the trigger fails, the event is lost. Define how long event clips must be retained.

A worked example: Perimeter security

Imagine a warehouse with a long fence line. The goal is to detect unauthorized entry. The site uses a row of cameras along the fence.

The procurement team defines the use case. They want to detect a person crossing the fence line. They do not want to detect cars driving on the public road next to the fence. They need an alert within ten seconds. They can tolerate a few false alarms per week, but not more.

They ask vendors for a solution. Vendor A offers a camera with built-in motion detection. The motion detector flags any change in the zone. This includes trees swaying in the wind. The team rejects this. The false alarm rate is too high.

Vendor B offers a camera with person detection. The system filters out cars and animals. It only triggers when a human figure crosses the line. The team reviews the specs. The camera processes the video locally. The alert goes to a local server. The network load is low.

The team asks for a demo. They provide a video of the fence line at night with rain. Vendor B runs the analytics engine. The system correctly identifies a person in the rain. It ignores a dog walking on the sidewalk. The team approves the proposal.

The difference here is specific. The first option was too general. The second option matched the use case. The procurement team avoided paying for cloud services they did not need. They also avoided false alarms that would distract security staff.

Contract and compliance considerations

Include performance requirements in the contract. State the minimum accuracy rate. Define the test conditions. Specify the lighting levels and weather conditions used for testing.

Check data privacy laws. If the system processes faces or plates, it must comply with local regulations. Some jurisdictions require consent for biometric data collection. Ask the vendor how they handle data deletion. Ask who has access to the analytics logs.

Define the update policy. Analytics models improve over time. Software updates can change accuracy. Ask how the vendor communicates updates. Ask if updates require downtime. Ask if you can roll back an update that causes false alarms.

Procurement teams often overlook the support model. Who fixes the algorithm? If the system starts missing objects after a firmware update, who is responsible? A camera manufacturer may not support the analytics engine. The analytics provider may not support the camera. Clarify the support chain before signing.

Final sourcing checklist

Use this checklist when reviewing proposals:

1. The use case is defined in writing.
2. The processing location is specified.
3. The object classes are listed.
4. The accuracy rate is defined under test conditions.
5. The network bandwidth impact is calculated.
6. The data retention and privacy compliance are addressed.
7. The support and update policy is clear.

This process turns vague marketing into concrete requirements. It helps procurement teams compare vendors on equal footing. It reduces the risk of buying features that never get used. It ensures the system delivers the specific value the site needs.