How does the Insights tracking script work?

A detailed explanation of how the Insights tracking code works

Page View request

Article Read request

Attention Time request

Android request

iOS request

For information on how to implement the Insights tracking script please follow this guide.

How the tracking code collects this information depends on the way the code is implemented. This can vary from case to case.

There are two types of requests sent by the Insights tracking script: p-request and a-request. Here is a detailed explanation of each.

1. Page View and Article Read

The Page View request should be fired immediately after the Insights script has been triggered. 

For the Article Read request to be fired, the smartocto Insights tracker waits for 10 seconds after the page has been loaded. The browser tab needs to be open for 10 seconds and there has to be some activity on the page (e.g. mouse click, scroll or move).

1.1. Page View request

This request is sent in the form of a GET request for the image on our servers. The endpoint URL is:

Here is the list of all parameters that can be sent in a single Page View request (p-request):

  a - comma-separated list of authors
b - referral URL
c - article title
d - article URL
e - comma-separated list of sections (categories)
f - domain ID
g - article’s publish date in ISO 8601 format (2020-02-20T12:34:56+00:00)

h - comma-separated list of tags [optional]
i - comments [deprecated]
j - access level: "free" or "paid" [optional]
k - article type [optional]
l - image URL [deprecated]
m - reader type: "anonymous", "registered" or "subscribed" [optional]
n - page type: "article" (default) or "landing" [optional]

pid - unique article ID (can be canonical URL or the ID from internal CMS)

u - session cookie identifier
ul - lifetime cookie identifier
x - request identifier (random number)
t - request type identifier (t=0)

ver - version indicator, automatically assigned by the tracker
err - error code, automatically assigned

ch - (values: AMP, Android or iOS)
os_ver - only from mobile SDK requests (system version)
manuf - only from mobile SDK requests (device manufacturer)

utm_source - source
utm_medium - link type (email, cpc)
utm_campaign - campaign name
utm_term - search terms
utm_content - identifies what was clicked (banner, logo, textlink)

UTM parameters are optional, they are automatically sent by the standard implementation of the Insights tracker if the visited URL contains UTM tags.

On standard website implementations, we can see some legacy parameters with empty values that are automatically added by the tracker. They are not sent through the mobile SDKs, AMP and FIA requests and can be completely omitted in custom implementations. Optional parameters can also be omitted, but please consult our Support Team for details and special cases (e.g. paywall setup).

Please note that mobile SDK and custom-built app requests don't have to contain all parameters. For any custom implementation, here is the minimum set of parameters to make a valid p-request:

  d - URL
f - domain ID
pid - unique article ID (can be canonical URL or the ID from internal CMS)
u - session cookie identifier
ul - lifetime cookie identifier
x - request identifier (random number)
t - request type identifier (0 or 1)
ch - AMP, Android or iOS

This is because for a given article the system normally receives standard requests from the website and those requests contain all meta-data.

Mobile app or custom-built requests can have a reduced number of parameters because the system will process the data and attribute the statistics to the corresponding article by matching the domain ID, URL, and article ID.

However, if for any reason mobile app content can't be found on the website (e.g. specially promoted or premium content), additional parameters must be set (title, authors, pubdate, sections, etc) because the system will not have any other source to match. Please refer to the examples at the bottom of this page.

Cookie values

There are two cookies added by the Insights tracker on standard website implementations:

 u - a session cookie (identifier) that lasts for 30 minutes.
ul - a lifetime cookie that expires two years after the last visit.

Please note that ul is mandatory, while u is not.

In the original JavaScript tracker code, the session cookie is generated like this:

_ain.generateCID = function() {
return new Date().getTime() + "." + Math.random() * 1000000000;

On websites running the Insights script these values can be found in the browser cookies with their corresponding values:

_ain_cid =  u = 1627474831382.483214541.3665818
_ain_uid = ul = 1627474831383.862881286.4191326

If the value of the ul format doesn't correspond with the abovementioned, the system will parse it with the timestamp of the received request.

x parameter

The x-parameter is a random number whose main purpose is to prevent caching, but all p- and a-requests should have the same x value during a single article visit from a single visitor.

JavaScript example:

x = Math.random(); // 0.10776367005369303

1.2. Article Read request

This request is sent to the same address as the Page View request with one important difference (t=1) and a couple of additional parameters:

 t - request type identifier (t=1)
wc - word count, the number of words in the article, including the title, description, image caption... [optional]

ln_count - the number of LinkedIn reactions for a given article [optional]
pn_count - the number of Pinterest reactions for a given article [optional]


2. Attention time tracking

After the page is loaded, the code starts tracking active attention time. Active time means there is a person behind the screen whom we detect the help of tab focus and page activity (e.g. mouse movements, keyboard clicks, scrolling, etc.)

Attention Time request

The tracking is done by sending one Attention Time request every 5 seconds to smartocto Insights’ servers via GET parameters. The address is:

Here is the list of all parameters that can be sent in a single Attention Time request (a-request):

  d - URL
f - domain ID
pid - article ID
b - referrer
ch - (values: AMP, Android or iOS)
u - session cookie
ul - lifetime cookie
at - current attention time, accumulated
ar - a difference in seconds between the two consecutive requests
sp - scroll position, considering only the article's true content
ts - current timestamp
seq - sequence number, the request counter for the current page visit
x - request identifier
err - error code, used for internal debugging
ver - tracker version

Please note that matching parameters from a-request should have the same value as a corresponding p-request parameter for a given article in a single page load.


  f - domain ID
d - URL
b - referrer
pid - article ID
ch - channel identifier (AMP, Android or iOS)
x - request identifier (random number)
u - session cookie
ul - lifetime cookie
err - error code
ver - tracker version

Scroll Position calculation

Here's an example of how the scroll position could be calculated (the result should be in percentages, 0-100):

sp = 100 * (viewportHeight + scrollTop) / scrollHeight


Request examples

Here are a few example requests from a single session (on a single article):

Android requests

The following parameters were sent through the tracker:


Page View - fires immediately after opening an article (0 seconds):


Article Read - fires if the user reads an article for 10 seconds:


Attention Time - fires every 5 seconds when the user reads an article:





iOS requests





Testing the Insights tracker

When you implement the script on the web page you can inspect if the tracker properly sends requests to our ingestion server.

Please follow this guide for more details.



If you have any additional questions or concerns feel free to contact our Support Team.