If you run a WordPress site, read how to download and install our plugin.
Detailed and customized instructions are sent to each client once they agree to test CI on their site.
The specifics of configuration for your domain can always be found in the application, under Settings → Tracking code.
CI tracking code is asynchronous and it will not affect the speed of the website.
Before you start
- The code should be put only on article pages.
- It shouldn’t be on the homepage, category/tag/sections pages, etc.
- Make sure that your CMS does not load the tracking code in the preview mode or on any temporary pages.
- A proven best practice is to omit our code when staff members are logged in. Be careful not to omit the code from all logged-in users if you have a subscriptions system or any other option where you allow your readers to register on your website.
- If you have a staging/test server please let us know and we'll assist you.
- Setting up a tracking code means making sure that _ain object is populated with the correct metadata about the article.
This is an example of an empty tracking code that you should put on every article page. It should contain your domain ID.
If you put this code into some library on your page, make sure that the
_ain object is globally accessible.
This can be achieved by declaring it somewhere in the global scope before populating it in the library.
In most cases, sites use canonical URLs so you don’t have to specify this parameter: the tracker will add it automatically.
<link rel="canonical" href="https://contentinsights.com/blog/changing-the-way-we-approach-editorial-analytics/" />
If your site doesn’t have canonical links or og:url parameters, please specify it manually.
It needs to be a full URL, with the domain, like this:
It should be a unique, canonical link to the article.
Having variations in the URL of the same article can cause problems in calculations later.
The domain ID is a 4-digit number automatically created by the CI application after the domain registration.
You can always see it in the application URL, it's "1234" in this example:
Post ID is a unique identificator of the article. We will combine all the statistics for the articles with the same postid.
It doesn’t need to be numerical. You can use article ID from the CMS, slug, even the whole URL.
For example, WordPress sites have a shortlink tag with post ID:
<link rel='shortlink' href='https://contentinsights.com/blog/?p=123' />
In this case, postid parameters should have this value:
In Content Insights, we have a metric called Read depth.
To calculate how far through an article a reader got, we look where the content is, calculate its height, count the number of words, and then we measure the time and how far through the user scrolled while reading the article.
All these metrics are then put in the formula that tells us how much of the content is being read by the user for the given time.
To know where the content is so we can count the words and calculate the height and the position relative to the window, we need to know exactly what elements of the page contain the content of the article.
To identify those elements, you must specify CSS selectors of those elements in the maincontent parameter.
maincontent: "#article-title, .article-body"
This is the date when the article is published. It has to be in ISO 8601 format.
pubdate: "2017-03-22 13:24"
This is a simple article title.
You can use the value from the
og:title tag, but you should remove the site title if present.
If there are quotes in the title they need to be escaped.
title: "Did you watch new "Star Wars" movie?"
This is the author's name or comma-separated list of authors.
If authors sign articles differently each time (e.g. John Smith, J. Smith, J.S.) then it would be best if we find a way to always send us just one version. There is an option in the system to manually group them afterward, but it’s best if the data is clean from the start.
authors: "John Smith"
When multiple authors contributed to the article, it’s important that you send us authors as a comma-separated string. You cannot use a different separator.
authors: "Jack Black, Jane White"
Our system can work without authors, but valuable insights will be lost.
Sections are the primary way of organizing content in Content Insights.
We use sections as containers for comparing one article against each other. This parameter should be filled with a single section, sections with the hierarchy or multiple sections as comma-separated strings.
Sections in a hierarchy usually reflect the site structure, for example:
Sections can be grouped (nested) with the > separator.
For example, if an article belongs to section Football, which is part of the Sport section, you can send us this value:
If the article contains embedded video and, for example, you have Video section, you can send us this value:
sections: "Sport>Football, Video"
Values from the tags parameter are called Topics in Content Insights. Just like the sections, it should be a comma-separated string of topics.
tags: "Premier League, Chelsea, Antonio Conte"
This represents the article access level type. The value can be one of the following standardized options: “free”, “preview”, “paid”
Please read the Paywall setup for further explanation.
Represents the type of visitor/reader currently browsing your site.
The value can be one of the following standardized options: "anonymous", "registered", "subscribed"
Use "anonymous" for all guest visitors, "registered" for registered or logged-in visitors and "subscribed" for subscribed (premium) visitors.
Please read the Paywall setup for further explanation.
This represents the type of article as specified by publisher (e.g. "news", "gallery", "blog", "essay").
Still have a question? Feel free to drop us an email: firstname.lastname@example.org