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

City of ip address

region

Region/State/Province of ip address

post

Postal or Zip Code

country

Country of ip Address

continent

Continent of ip Address

timezone

Timezone of the estimated location

offset

Timezone Offset (ex: +08:00)

lng

Estimated Longitude

lat

Estimated Latitude

ip

ip Address

screen

Screen Size/Resolution

language

Language set in operating system/browser preferences on device.

os

Operating System of Device

domain

org

Reported Organization (who owns the ip)

browser

The browser if any, used by the client.

time

Time that visit began in UNIX Millisecond Time Format

hour

Hour of the day of visit

day

Day of the month of visit.

month

Month of Visit

quarter

Quarter (3 month period) of Visit

year

Year of Visit

duration

Duration of Visit in Milliseconds

referrertype

Visit Referrer Type

referrerquery

Visit Referrer Query (for search referrals)

referrerurl

Visit Referrer URL

landingpage

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

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.

Organization

(org)
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

(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 Action Properties

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

(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 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 about a year 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.