General FAQs

This is for:


How can I optimize our setup?

Whether smartserve.js is added synchronously or asynchronously on a page depends on the balance between minimizing page load and minimizing flicker.

Minimizing page load

For the best user experience, and to minimize page load, we recommend an asynchronous setup:

<script src='//<YOUR_PROPERTY_ID>.js' async></script>

Observe the following recommendations:

  • The tag should be loaded at the head of the page

  • The tag should be loaded asynchronously

  • The tag can be loaded with in tag manager, although this is not recommended as it could potentially add flicker

In our experience, this is a suitable setup for campaigns that deliver additional messaging to a page such as personalized content, pointers, toggle sliders, and modal boxes.

With this setup, experiments designed to change the content of a landing page or home page banners, may expose the visitor to small amounts of perceived ‘flicker’.

Minimizing flicker

For clients that intend on running a full-site testing optimization program that includes landing pages, home page takeovers, and other areas of the site where the user experience is sensitive to perceived user flicker, then we recommend the following setup:

<script src='//'></script>

Observe the following recommendations:

  • The tag should be loaded at the head of the page

  • The tag should be loaded synchronously

  • The tag should be loaded outside of a tag manager

It is important to understand that this setup comes with a trade-off of increased page latency. Our testing shows that this increased latency is largely imperceptible to the end-user, but this of course depends on the connection used.

Improving performance

Clients often express concerns about the impact of Smartserve on page loading and overall site performance.

Whilst we have released a number of changes in the past year to minimize loading time, it is worth pointing our that the solution is typically custom to the site itself and often related to other site issues.

We do have a number of recommendations, however, that you might consider to further minimize Smartserve loading time:

  • Archiving un-used experiences and segments

It is important to understand that each live and recently paused experience and each segment injects logic into Smartserve and therefore contributes to its weight and the number of CPU cycles need to execute it

Leading practice

For this reason, we recommend archiving any live experiences you are no longer using and deleting any un-used segments.

  • Removing jQuery - this is an option for clients that are able to ensure jQuery is loaded on a page before Smartserve runs

  • Using packages - for common functionality used across experiences, using packages can have a significant positive impact on Smartserve performance. Refer to our Developers section and in particular Packages for more information

Is Smartserve required on a main and any subdomains, or just the main domain?

The Smartserve script is required on the main domain and any subdomains for a property.

What is the difference between a session and an entrance?

Why avoid visits and entries?

Visits and entries are both commonly used in the web analytics industry to report site metrics. Visits is defined as set of page views for a visitor and an entry constitutes the page on which that visit starts.

Unfortunately, there is much disagreement as to what constitutes a valid entry, with some definitions including a significant time period since the last page view, or being referred from an external web page. This is further complicated by some external web pages not implying a new visit. For example, if a visitor makes a payment via Paypal, it should not break a visit, nor should selecting a button to share or 'like' web content.

It can also happen that the browser may block the referrer url, making a succession of pageviews within a visit look like a series of direct entries.

Entrance and session

To avoid this confusion, we avoid the concept of visits, with its ambiguous definitions and complications, and instead concentrate on entrances and sessions.

An entrance is defined as any sequence of pageviews where the first page comes from an external link, entered URL, or bookmark and where all subsequent pageviews are triggered by a selection within the site.

A focus on direct entrance

A view in the same session as the previous view that lacks a referrer url, and therefore might be considered a direct entrance, is not treated as a new entrance but as a continuation of the previous one. The view will only be treated as a new entrance if it has UTM parameters that suggest it really is a new entrance.

A session is defined as any sequence of pageviews with less than 30 minutes between each view.

A good example of how we apply the concepts of entrances and sessions can be seen in our Behavioral Attribution. We count the purchase time from the start of the session in which the visitor purchases. But because a session may have multiple entrances, it can appear as though the visitor entered after the purchase happened, when in reality there were multiple entrances. We calculate last click value, and true last click value based on this fact.

What is Conversion Rate?

We use the commonly-used and widely-accepted definition of Conversion Rate: "Number of distinct visitors that convert (converters) over the total number of visitors." The measure of converters is much more robust that conversions, which can be heavily influenced by resellers or visitors that many transactions.

Conversions are usually purchases, for example, transactions, bookings, or bets, but it’s equally possible to define conversions as form interactions, clicks, or calls.

Vendors such as Google Analytics use the same definition but also employ a slightly different session-based Ecommerce Conversion Rate definition: "Proportion of sessions in which a transaction occurs."

A simple example illustrates the limitations of this definition when compared to the more widely-accepted definition used by Qubit.

Compare the behavior of the following visitors:

Visitor 1

Date of visit Action taken

November 29

Visits 3 product pages

December 1

Adds 1 product to the basket - doesn’t convert

December 4

Adds 2 products to the basket - doesn’t convert

December 6

Adds 1 product to the basket and buys 4 products

Visitor 2

Date of visit Action taken

November 29

Adds 1 product to the basket and purchases it

December 1

Adds 1 product to the basket and purchases it

December 4

Adds 1 product to the basket and purchases it

Only visitor 2 has a CR of 100% according to both definitions. We treat both visitor 1 and visitor 2 as converters without making any distinction about the timing of their conversions.

Now consider a 3rd and 4th visitor with with 17 sessions and no purchases, 2 sessions and no purchases respectively. We would be treat both as non-converters.

In an experience where visitors behave like users 1 and 3, the CR, according to Qubit’s definition would be 50%. In an experience with the fast-decision making behavior of visitors 2 and 4, the CR would also be 50%.

However, using Google’s ecommerce definition, the CR for visitors 1 and 3 would be 5%, compared to 60% for visitors 2 and 4.

In this simplified example, we see that the standard Qubit definition measures whether visitors convert, whereas the ecommerce definition measures speed to purchase.

For a further discussion about the differences seen in the Qubit platform and Google Analytics, see Why do we sometimes see very different Conversion Rates between the Qubit dashboard and Google Analytics?

How do we define the difference between a new and returning visitor?

Once you’ve been onboarded with Qubit, each time a visitor comes to your website, we will look for our tracking cookie, qb_permanent in the browser.

If the cookie is found, we will count the visitor as a returning visitor and increment their session and entrance numbers appropriately.


The session might not necessarily be counted as a new session, as sessions within thirty minutes of one another are counted as a single session.

If the cookie is not found, we will try to set one, count them as a new visitor and initiate their first session.


There are a few reasons why we might not be able to find our tracking cookie. Firstly, because this is a new visitor, secondly, because the cookie has expired—​currently qb_permanent expires 365 days after a visitor’s previous visit, and lastly because the user has cleared the cookie.

It is worth remembering the following points:

  • if the user has blocked first-party tracking cookies, they will be treated as a new visitor each time they come to your site

  • if the user has blocked tracking, we will not collect any of their data at all

How do we determine a users' location based on IP address?

Qubit uses a Media Rating Council accredited third-party service called NetAcuity from digitalelement for geolocation. As with all geolocation services, this uses an Internet Protocol address (IP) as a unique identifier to lookup a computer or computer network location.

With varying degrees of accuracy, at its most precise, this method can map an IP address to a house. At its least precise, the same method may only map an address to a country.