Verizon Connect Platform Help > Business Tools >

Introducing the Verizon Connect Analytics Server

What is the Analytics Server?

The Verizon Connect analytics server is a 'big data' repository containing information about trips carried out by vehicles and drivers within a given business, as recorded using GPS-enabled tracking modules and vehicle sensors.

In essence, the analytics server acts as a data 'warehouse', containing data about every aspect of your fleet's vehicle and driver operations while out in the field and at their home depots. This information is accessed via an HTTP request message containing simple SQL-based objects to a REST API, or by using the Verizon Connect SQL Connector.

From these queries, data about routes (distances, times, speeds, violations detected etc.), drivers and vehicle are immediately supplied for any time period for which data is available.

Returned data can be used to generate custom dashboards, to populate reports, or to supply external tools such as spreadsheets (when using the Verizon Connect SQL Connector).  

How Does it Work?

The analytics server stores vehicle trip data (that is, processed metrics about ‘trips’ recorded by vehicles, triggered by vehicle events and changes to vehicle status) in databases nested within customer 'zones'. Each zone contains one database. The tables contained in these databases are described here.

Typically, each customer will have access to a single zone. However, it is possible to set up several zones for customers. This allows different database versions to operate simultaneously; for example when developing a new dashboard, or if you want to provide access to data to service-providers you collaborate with (for example, for those also using Verizon Connect Share).


Before discussing the structure of the analytics server, server authentication, requesting metadata or the methods used to query table data using the REST API or the SQL Connector, let's first discuss some of the concepts that are fundamental to understanding the analytics server. These include trips, events and zones. Once you understand the meanings of these terms as they relate to this system, you will be in a position to better visualize how the analytics server functions.

What is a 'Trip'?

A trip is a vehicle activity typically initiated and ended by an event transition. Typically this event is a change in vehicle status; for example from idling to moving. In many ways, a Verizon Connect 'trip' parallels the common notion of a trip that one might make in your own personal vehicle: for example to the store to buy some milk.

In the analytics server, this outing would be treated as two trips, assuming that the vehicle's engine was started at your home, stopped at the store, then started again at the store when returning home with your milk, and finally turned off when you got home and parked your vehicle.

The first trip would be from your home to the store, and the second trip from the store back to your home. Of course, as the analytics server stores details of commercial vehicle 'trips', a vehicle is likely to make many trips delivering and collecting goods at customer sites, and time idling at various locations. If the vehicle is used to perform other tasks, such as clearing fallen trees or, these trips also need to accommodate the vehicle remaining stationary while using attached Power Take Off devices (winches, booms, wood chippers, etc) to perform various tasks, rather than simply being turned on and off at every site.

It is for this reason that trips are generally, but not always, bookmarked by vehicle event transitions.

What is an 'Event'?

Vehicle 'events' are based on movements or actions detected by a GPS-enabled device installed in a vehicle, and diagnostic messages read by sensors fitted on a vehicle (whether installed after purchase, or using sensors installed from the factory).

These signals cover a huge range of vehicle parameters, from the vehicle’s odometer reading to whether the windscreen wipers or headlights are on. Event transitions that will trigger a new 'trip' include:

The vehicle's status changing from Stopped to Moving, for example when leaving a customer site or depot after the vehicle had previously been turned off.
The vehicle status changing from Stopped to Idling, for example when arriving at a customer site or depot but not turning the vehicle off.
Vehicle status changing from PostIdle to Moving, for example when leaving a customer site after goods were unloaded, during which time the vehicle engine was left idling.
Vehicle passing through midnight in the vehicle’s time zone.

The last trip trigger, ending any previous trip and starting a new trip at midnight at the vehicle's location, ensures that trip data can be explicitly queried for a given day (24-hour period).

This event is triggered using the vehicle's time and time zone (unit time). It is for this reason that all times returned by the analytics server are in unit time (that is, from the vehicle's perspective). In other words, if you are on the East Coast of the US and you request time values from a trip recorded in Los Angeles, on the West Coast, this information will be returned in PST/PDT, not in EST/EDT time.

Another important concept when understanding trips is that there are typically no gaps between trips. The date-time at which a given trip ends, we shall call it trip 'A' for convenience sake, automatically marks the date-time of the start of the next trip, trip 'B'. The time between a vehicle’s ignition turning off  (for example while parked at its home depot after a shift) and the ignition being turned on at the start of the next shift (marking the commencement of trip 'B'), is treated as the end of trip 'A'. This ensures there is a continuous string of uninterrupted trips, regardless of what the vehicle is doing or being used for.

If our hypothetical vehicle is parked in a yard overnight, a new trip will also be triggered automatically at midnight, resulting in trip 'A' containing the time between the vehicle stopping and midnight, followed by a new trip, trip 'B' between midnight and the vehicle starting the following day, which triggers a third trip, 'C'.

If our vehicle then sits unused for the next two weeks, we would record a string of uninterrupted 24-hour trips every day from vehicle midnight to vehicle midnight over those two weeks, for a total of 14 trips in which no movement is recorded. Only if the vehicle lost power, or was moved under cover preventing the GPS device acquiring a satellite signal, would this string of trips be interrupted (as trips require a start and end point: without these points, trips cannot be recorded).

What is a 'Zone'?

A zone is merely a location used to store one dataset of trip data for a customer. In effect, the separation provided by zones allows different datasets for a given customer to be accessed independently of one another by separate deployments, or to allow a single dataset to be shared by several customers.

For example, data in one zone could be used for the production, or 'live', version of a dashboard to present live vehicle data, while another zone is used for a staging, or development, version that is being used to test a new dashboard or for quality assurance purposes. This ensures that test data and live data can be kept separate from one another.