The nitty gritty technical details behind Prodlytic's 'auto-track everything' feature.

In this document:
Part one: collecting data
Part two: what data are collected?

-Page views
-Hash views
-URL wildcarding
-GDPR compliance: removing personally identifiable information (PII)

-Control Type
-Overriding Control Type
-Removing Personally Identifiable Information (PII)
-Overriding the Text Value
-Ignoring Clicks
-Do Not Track

Users and sessions

Part three: how are data presented?

There are three different parts to understanding how auto-tracking everything works:

Part one: collecting data

The Prodlytic Collector is a small JavaScript element that looks like this:

<script src="" charset="utf-8" data-pid="your-product-id"></script>

Here's what happens when you add this snippet:

Unlike some other analytics tools Prodlytic requires only a single piece of tracking code. In contrast, tools like GA require multiple snippets of code to track different actions like clicks or form submissions.

So what does Prodlytic actually collect?

Part two: what data are collected?

Prodlytic collects three different types of user behavior data:

Page views

Each time someone visits a new page on your site the Collector logs that a new page has been loaded. Each new page visit counts as a single page view. Page data is displayed under the "Pages" tab:

Modern apps and websites are a little more complicated than simple page views. To handle this complexity Prodlytic acounts for:

Hash views

Many Single Page Applications (SPAs) use hash URLs to identify different parts of the application. Prodlytic logs any hash URLs and treats these just like normal page views.

URL wildcarding

Prodlytic identifies parts of any page URL that appear to be parameters and groups those page view events in its interface. For example, say Prodlytic sees a series of page view events that look like this:


It'll group those page views under the URL:


The * is referred to as a wildcard. Prodlytic wildcards parts of a URL if:

Wildcards look like so in the Prodlytic dashboard:

GDPR compliance: removing personally identifiable information (PII)

May 25th 2018 saw GDPR roll out accompanied by plenty of confusion about what it actually means for people, especially when it comes to analytics. Prodlytic helps you stay GDPR-compliant by technically prohibiting you from sending PII in pages to Prodlytic:

This, along with the other steps we take, help you comply with the new GDPR regulations.

Notify your users that Prodlytic is collecting by including this copy in your product Terms & Conditions:

Prodlytic Collector – we use Prodlytic to measure how our site is used by visitors and to generate reports for our own use. Prodlytic does not collect any personally identifiable information about you.


The Prodlytic Collector records every click event (or tap on touch screen devices) that occurs on your website or webapp. The logged click event stores information about what was clicked including the full DOM path of the HTML element and the X and Y coordinates. This information is compiled and presented in the “Clicks” tab in the Prodlytic dashboard:

Prodlytic does all the hard work of identifying clicks so you don't need to instrument hundreds of individual events in your analytics. But that means clicks are much more complicated than page views. To give you an overview of how click tracking works, here's the six main things Prodlytic takes into consideration:

Control Type

When Prodlytics logs a click event each event is assigned a “Control Type” value. The control type value describes what kind of UI control Prodlytic thinks a user clicked on.

To determine what the control type is Prodlytic checks if the clicked HTML element contained a link, a button, or a dropdown list.

However, from a user’s point of view, it’s obvious they a link, a button, or a dropdown.

Once the main target of the click is identified Prodlytic defines the control type as follows:

Overriding Control Type

You can specify a custom control type for any HTML element by adding the “data-prodlytic-controltype=’{control-type}’” attribute to that element.

For example, any clicks on the following element are recorded as having a control type of “Date Picker”:

<div data-prodlytic-controltype=”Date Picker”>...</div>

Any clicks on elements inside an element with the “data-prodlytic-controltype” attribute (up to five levels down) will be recorded as being a click on that element.

You can see this in the snippet below. Any clicks on the <button> element in the are logged with a control type of “Date Picker”:

<div data-prodlytic-controltype=”Date Picker”>
 <div class=”header”>...</div>
 <div class=”date-grid”>...</div>
 <div class=”footer”>


When logging a click event Prodlytic logs a “text” value for the clicked element. This value depends on the type of HTML element that was clicked. The following rules are used:

Removing Personally Identifiable Information (PII)

Webapps often have clickable elements that contain user email addresses. As with page URLs and titles, any email addresses found in the clicked element’s text value will automatically be replaced with “”. 

Overriding the Text Value

You can specify a custom text value for any HTML element by adding the “data-prodlytic-text” attribute to that element. The value of that attribute overrides the controls text value.

To prevent other kinds of PII being transmitted to Prodlytic as part of the “Text” value associated with a click event, you must add the “data-prodlytic-text” attribute to any clickable element that might include PII in their default text value. The following examples illustrate the kinds of scenarios where this approach should be used:

The Prodlytic collector still overrides any email addresses it finds in the “data-prodlytic-text” attribute values and replaces them with the value

Ignoring Clicks

You can tell Prodlytic to ignore any clicks on certain elements by adding the “prodlytic-ignore” CSS class to that element. This approach can also be used to prevent PII being sent to Prodlytic. But it should be used with care as it will prevent any record of the element being clicked on at all.

Do Not Track

By default, Prodlytic doesn’t track user behaviour across multiple websites or webapps. However, it will track the same user between multiple sessions on the same site. If user’s would prefer this not to happen they can use their browser’s “ingonito” or “private” mode or the Do Not Track setting. Both achieve the same thing, forcing Prodlytic to forget about their user ID after each session and assign them a new user ID at the start of their next session.

Users and sessions

The core numbers that make up any analytics software is the number of users and their sessions. Prodlytic is no different. Each time someone visits your site or app the Prodltic Collector checks their brower's local storage to see if they're a returning user. It'll also check the browser’s session storage to see if they're already in a Prodlytic session.

If two sites are using Prodlytic and the same person visits both sites, they are assigned a different user ID for each site. This happens on their device and Prodlytic’s servers are not aware that their actions on the two differents websites come from the same person. User IDs are unique, but are not traceable back to a real person. They are therefore not considered personally identifiable information (PII).

User IDs are linked only to a user’s browser. The same person using a different device or browser appears to be a different person to Prodlytic. Clearing a browser’s local storage or using a browser’s incognito mode  also means someone appears to Prodlytic as a new user.

Part three: how are data presented?

 Once Prodlytic is collecting data three types of information will automatically be displayed in the dashboard under "Pages" and "Clicks":

The great thing about the Pages and Clicks tabs is that you instantly understand the overall health of your app, how people are using it, and whether there are under-utilised parts of it you can improve.

Contact us to get started with Prodlytic

Get Started