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:
|Field Key||Field Name|
|City of ip address|
|Region/State/Province of ip address|
|Country of ip Address|
|Continent of ip Address|
|Timezone of the estimated location|
|Timezone Offset (ex: +08:00)|
|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|
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.
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
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 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.
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.
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.
- 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. Or, the session times out, and they start a new session causing the referrer URL to be an internal page.
- 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 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?
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 2 months ago