File: woopra.rst

package info (click to toggle)
python-django-analytical 3.2.0-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 720 kB
  • sloc: python: 4,693; makefile: 7
file content (204 lines) | stat: -rw-r--r-- 6,961 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
===========================
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.

.. _Woopra: http://www.woopra.com/


Installation
============

To start using the Woopra integration, you must have installed the
django-analytical package and have added the ``analytical`` application
to :const:`INSTALLED_APPS` in your project :file:`settings.py` file.
See :doc:`../install` 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
:ttag:`analytical.*` tags.  If you are, skip to
:ref:`woopra-configuration`.

The Woopra tracking code is inserted into templates using a template
tag.  Load the :mod:`woopra` template tag library and insert the
:ttag:`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.

.. _`Asynchronous JavaScript Developer’s Guide`: http://www.woopra.com/docs/async/



.. _woopra-configuration:

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
:const:`WOOPRA_DOMAIN` in the project :file:`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 :ttag:`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 :const:`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.


Cookie control
--------------

Optional settings that influence the cookie behavior::

    WOOPRA_COOKIE_NAME = "wooTracker"
    WOOPRA_COOKIE_DOMAIN = ".example.com"
    WOOPRA_COOKIE_PATH = "/"
    WOOPRA_COOKIE_EXPIRE = "Fri Jan 01 2027 15:00:00 GMT+0000"

See the `Woopra documentation`_ for more specific details.


Tracking control
----------------

Optional settings that influence the tracking as such::

    WOOPRA_CLICK_TRACKING = False
    WOOPRA_DOWNLOAD_TRACKING = False
    WOOPRA_OUTGOING_TRACKING = False
    WOOPRA_OUTGOING_IGNORE_SUBDOMAIN = True
    WOOPRA_IGNORE_QUERY_URL = True
    WOOPRA_HIDE_CAMPAIGN = False

See the `Woopra documentation`_ for more specific details.


.. _`Woopra documentation`:
    https://docs.woopra.com/reference/woopraconfig#configuring-your-tracker


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 :const:`WOOPRA_INTERNAL_IPS` setting,
the tracking code is commented out.  It takes the value of
:const:`ANALYTICAL_INTERNAL_IPS` by default (which in turn is
:const:`INTERNAL_IPS` by default).  See :ref:`identifying-visitors` 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 :ttag:`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
:data:`TEMPLATE_CONTEXT_PROCESSORS` list in :file:`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
:class:`~django.template.context.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.
====================  ===================================


.. _`custom visitor data`: http://www.woopra.com/docs/tracking/custom-visitor-data/


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 :ref:`identifying-visitors`.


----

Thanks go to Woopra for their support with the development of this
application.