Woopra – website analytics¶
Woopra generates live detailed statistics about the visitors to your website. You can watch your visitors navigate live and interact with them via chat. The service features notifications, campaigns, funnels and more.
Installation¶
To start using the Woopra integration, you must have installed the
django-analytical package and have added the analytical
application
to INSTALLED_APPS
in your project settings.py
file.
See Installation and configuration for details.
Next you need to add the Woopra template tag to your templates. This
step is only needed if you are not using the generic
analytical.*
tags. If you are, skip to
Configuration.
The Woopra tracking code is inserted into templates using a template
tag. Load the woopra
template tag library and insert the
woopra
tag. Because every page that you want to track must
have the tag, it is useful to add it to your base template. Insert
the tag at the bottom of the HTML head:
{% load woopra %}
<html>
<head>
...
{% woopra %}
</head>
...
Because Javascript code is asynchronous, putting the tag in the head section increases the chances that a page view is going to be tracked before the visitor leaves the page. See for details the Asynchronous JavaScript Developer’s Guide on the Woopra website.
Configuration¶
Before you can use the Woopra integration, you must first set the website domain. You can also customize the data that Woopra tracks and identify authenticated users.
Setting the domain¶
A Woopra account is tied to a website domain. Set
WOOPRA_DOMAIN
in the project settings.py
file:
WOOPRA_DOMAIN = 'XXXXXXXX.XXX'
If you do not set a domain, the tracking code will not be rendered.
(In theory, the django-analytical application could get the website
domain from the current Site
or the request
object, but this
setting also works as a sign that the Woopra integration should be
enabled for the analytical.*
template tags.)
Visitor timeout¶
The default Woopra visitor timeout – the time after which Woopra ignores inactive visitors on a website – is set at 4 minutes. This means that if a user opens your Web page and then leaves it open in another browser window, Woopra will report that the visitor has gone away after 4 minutes of inactivity on that page (no page scrolling, clicking or other action).
If you would like to increase or decrease the idle timeout setting you
can set WOOPRA_IDLE_TIMEOUT
to a time in milliseconds. For
example, to set the default timout to 10 minutes:
WOOPRA_IDLE_TIMEOUT = 10 * 60 * 1000
Keep in mind that increasing this number will not only show you more visitors on your site at a time, but will also skew your average time on a page reporting. So it’s important to keep the number reasonable in order to accurately make predictions.
Internal IP addresses¶
Usually you do not want to track clicks from your development or
internal IP addresses. By default, if the tags detect that the client
comes from any address in the WOOPRA_INTERNAL_IPS
setting,
the tracking code is commented out. It takes the value of
ANALYTICAL_INTERNAL_IPS
by default (which in turn is
INTERNAL_IPS
by default). See Identifying authenticated users for
important information about detecting the visitor IP address.
Custom data¶
As described in the Woopra documentation on custom visitor data,
the data that is tracked by Woopra can be customized. Using template
context variables, you can let the woopra
tag pass custom data
to Woopra automatically. You can set the context variables in your view
when your render a template containing the tracking code:
context = RequestContext({'woopra_cart_value': cart.total_price})
return some_template.render(context)
For some data, it is annoying to do this for every view, so you may want
to set variables in a context processor that you add to the
TEMPLATE_CONTEXT_PROCESSORS
list in settings.py
:
from django.utils.hashcompat import md5_constructor as md5
GRAVATAR_URL = 'http://www.gravatar.com/avatar/'
def woopra_custom_data(request):
try:
email = request.user.email
except AttributeError:
return {}
email_hash = md5(email).hexdigest()
avatar_url = "%s%s" % (GRAVATAR_URL, email_hash)
return {'woopra_avatar': avatar_url}
Just remember that if you set the same context variable in the
RequestContext
constructor and in a
context processor, the latter clobbers the former.
Standard variables that will be displayed in the Woopra live visitor
data are listed in the table below, but you can define any woopra_*
variable you like and have that detail passed from within the visitor
live stream data when viewing Woopra.
Context variable | Description |
---|---|
woopra_name |
The visitor’s full name. |
woopra_email |
The visitor’s email address. |
woopra_avatar |
A URL link to a visitor avatar. |
Identifying authenticated users¶
If you have not set the woopra_name
or woopra_email
variables
explicitly, the username and email address of an authenticated user are
passed to Woopra automatically. See Identifying authenticated users.
Thanks go to Woopra for their support with the development of this application.