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.

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 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).

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.