Woopra Documentation

Generated Visit Properties

System-Generated Visit Properties

These are the Built in Fields or Properties of Visits (aka. Sessions). This data is associated with a visit, which is a set of actions considered to have occurred in the same session, ie: more or less continuously, without a large time gap in between. For more information on visits

Field Key

Field Name


City of ip address


Region/State/Province of ip address


Postal or Zip Code


Country of ip Address


Continent of ip Address


Timezone of the estimated location


Timezone Offset (ex: +08:00)


Estimated Longitude


Estimated Latitude


ip Address


Screen Size/Resolution


Language set in operating system/browser preferences on device.


Operating System of Device



Reported Organization (who owns the ip)


The browser if any, used by the client.


Time that visit began in UNIX Millisecond Time Format


Hour of the day of visit


Day of the month of visit.


Month of Visit


Quarter (3 month period) of Visit


Year of Visit


Duration of Visit in Milliseconds


Visit Referrer Type


Visit Referrer Query (for search referrals)


Visit Referrer URL


The path of the url of the first pageview of this visit


All of these visit fields are generated by the Woopra tracking engines when logging a visit. They cannot be overridden when sending real-time events. They can be sent, however, when running bulk visit imports using the Import API.

Location Data

(city, region, country, continent, timezone, offset, lng, lat)
Woopra uses an ip geolocation service to estimate the location of the device doing the actions that make up a given visit. Geolocation can be very precise in some cases, and very imprecise in others. Sometimes a visit is coming from a serverside tracking event, and the original client device's ip has not been passed along to Woopra. Woopra will then use the ip of whatever device sent us the track request, and that ip will belong to a server in a data center in Dallas, Texas while the user is sitting in a coffee shop in Milwaukee.

Note the longitude and latitude values are not precise. They will usually be the center point of a given city or neighborhood, and are most useful in calculating "nearby" users (as numbers that can be passed to geography API's, etc.)

Treat these fields as rough estimates of location that are sometimes correct, and sometimes for any number of reasons, largely privacy concerns and technical limitations, totally wrong. They are often useless at the individual visit level, but will likely approach truth when you report on these fields in aggregate.


This field is generated based on ip. It reports the organization that owns the ip. Often, the reported organization of a private visitor (on their home network, e.g.) will be their Internet Service Provider (e.g. Comcast). Woopra tries to not set this field if it thinks it is simply an ISP ip address.

However, when a customer comes to your site from a work computer, it is likely that the ip to organization mapping services will accurately report their employer as the owner of that ip.

Visit Duration

Visit duration is simple in concept, but can become very complex as you consider atypical cases. In its simplest form, Visit duration is the length of time between the first action, and the end of the timeout after the last action. This is calculated using event times and event durations.

The perfect example of this working is in a browser session tracked by our javascript tracking SDK. The browser tracker makes full use of server pinging, sane default event timeouts, etc. What this means is that every event tracked by our tracker has a duration, and the visit duration is quite simply the sum of the action durations of the actions that make up the visit.

It gets more complex with serverside events, events brought in by AppConnect apps from other services, and in general, anything not tracked by our tracker in the browser. Certain events have a 0 duration. Other times, it is easy to accidentally send explicit action durations with each action that are actually overlapping, and thus artificially inflating your visit duration. It is also worth noting that the /ping requests will automatically be applied to the latest active, non-system action. See Generated Action Properties for list of system actions.

If you are looking at a browser session as tracked by a clean implementation of our client side tracking SDK, then you can know for sure that visit duration is as accurate as possible, but unless you are carefully implementing your other tracking with this in mind, don't put too much credibility to this number for other types of visits.

Referrer information

(referrerurl, referrerquery, referrertype)
Note the legacy mis-spelling of the referer field in the HTTP specifications. Here's a wikipedia article about it. And note our lack of this mis-spelling here.

The referrer fields are taken from the referrer property of the first action of this visit. If the first action does not have referrer information in it, these fields will be blank.

If the action is passed with the referer property as a complete uri, the Woopra system will parse this uri and extract the domain to guess the type of the referrer, and the query used if it is a search engine referral, and this information is provided. However, this query information is not often provided by search engines anymore.

Referrer Types

  • Direct - A visitor that typed in the site directly, opened a desktop app, or had a bookmark.
  • Internal - The visitor came from a page within your site that isn’t tracked such as a sub-domain.
  • Search - The visitor has come from a search engine such as a Google search.
  • Backlink - The visitor came from an external link from another site such as a link in a blog post.
  • Social - The visitor came from a social platform such as Facebook.
  • Email - The visitor came from a link in an email such as a link in Gmail.
  • PPC - The visitor came from an ad link or some marketing campaign.


Using referrer can inaccurate

Please note that using referrer as a filter can be inaccurate. Please see our doc for more info

Landing Pages

The landing page from the scope of a visit is the url of the first pageview of a visit. This does not mean that this is one of your pages that you consider to be a landing page, it means it is the first page the visitor landed on to start this visit.

So this generated field is the url of the page that was first seen by the visitor in this visit specifically.

Updated 12 months ago

Generated Visit Properties

System-Generated Visit Properties

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.