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, i.e.: more or less continuously, without a large time gap in between. For more information on visit properties, see the table below:

Discussion

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.

📘

We use Maxmind to determine geolocation based on IP addresses

This data is updated in our system every two weeks. You can check geolocation based on IP here: https://www.maxmind.com/en/home

Visit Duration

(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 user that typed in the site directly, opened a desktop app, or had a bookmark.
• Internal - The user came from a page within your site that isn’t tracked, such as a sub-domain. Or, the session times out, and they start a new session causing the referrer URL to be an internal page.
• Search - The user has come from a search engine such as a Google search.
• Backlink - The user came from an external link from another site such as a link in a blog post.
• Social - The user came from a social platform such as Facebook.
• Email - The user came from a link in an email such as a link in Gmail.
• PPC - The user came from an ad link or some marketing campaign.

🚧

Using referrer can be inaccurate

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

Read more on Campaign and Referrer Data. What's the difference?

Landing Pages

(landingpage)
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 user landed on to start this visit.

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