Experiences FAQs

This is for:

Developer

When building an experience, what’s the best way to review and QA each version?

When you click the Preview button in the dashboard it opens your site with some querystring parameters. These tell our script to fetch the preview mode script and which experience variants are being previewed.

You can share this URL for QA purposes. When previewing, you’ll always see the most recent version of a variant. An experience can have multiple variants and the preview URL contains the Id of the variant you’re previewing.

How are experiences deployed?

Experiences are deployed onto the client site through the smartserve.js script.

When a new experience is published or paused, smartserve.js is re-published to the client site through our CDN. This can take up to 10 minutes.

When loaded, smartserve.js assesses whether a visitor meets the conditions for any segments linked to the experience. If true, smartserve.js then assesses whether triggers conditions have been met. Only then will the visitor be served the experience.

How can I optimize an experience for performance?

When optimizing for performance, we recommend that customers are creative in the use of images and use CSS, where possible, in place of images. Where images are required, use the compressed or progressive JPEG file types.

How can I optimize an experience for flicker-sensitive areas

For experiences with a requirement to minimize flicker and page load times, such as home page takeover and landing pages, we recommend implementing Smartserve synchronously.

Where possible, builds should:

  • Use compressed or progressive JPEG file types to minimize file size

  • Where possible, use CSS as an alternative to images

  • Use an optimal polling strategy to check for elements. See Polling For Elements for more information.

As there’s no audit trail displayed on the web interface, how can we track which changes have been made and by whom?

Qubit’s Professional Services team has access to an internal bookmark that has details about when and by whom changed were made. This data is available on request.

What level of testing should be included to detect regressions when adding new or editing existing experiences?

We recommend using the Qubit Explorer to check the state of each experience, jump into specific experiences, or preview multiple experiences simultaneously.

See Previewing single experiences and Previewing multiple experiences for details.

Advanced users might also be interested in previewing experiences by entering the preview and URL and experience Id(s) directly into a browser window. See Previewing by entering the preview URL

qb_session has a rolling 30 minute expiry. This means the cookie expires after 30 minutes of inactivity.

Is anything executed upon the control group being selected? Or more generally, does something always get executed after the group is selected (variation/control)?

You’ll only be rendering the correct HTML when the qubit.experience QProtocol event is fired. That event will contain information about the experience, such as its Id and the variation you’re in. This event is only sent when the cb trigger function is executed.

For experiences that don’t trigger on page-load, this approach would be problematic as the associated area of the page wouldn’t render. The only flag you have before cb is executed to check which variant the user is in, is the options.meta.variationMasterId, which is accessible in the triggers of each test.

This gives you the variation Id of the variation that the visitor is bucketed into. This is scoped to each trigger and will obviously be different for each experience that the visitor is exposed to.

Is it possible to implement a personalization test by collating events per visitor and ordering by frequency? For example, 'the last items the visitor has selected, most recent first'

Strategically, doing something like this is complex, and you would want more than just a list of recently selected items. For example, we would recommend also building in some upsell/cross-sell too. Utilizing our data imports tool, it’s possible to use a user_id JSON, where the JSON contains what you want to show to that visitor.

If you did want to do something simple like recently selected items by not using cookies/local storage, you could do one of the following:

  • Based on visitor history Create bespoke visitor history profiles in Qubit visitor history. This involves utilizing one part of our Data Store as quick storage.

  • Based on Social proof

Keying the social proof API to a single visitor, keying against a user_id rather than visitor_id and making it cross device.

Qubit can deliver training to take you through the algorithms and APIs, but you could set up events to get sent to this endpoint for real-time querying.

See Social proof Messaging for more information.

Specifically for Apple’s Safari and Private Browsing Mode, is it possible to check if localStorage is available before using it in an experience trigger?

The following snippet can be used to check if localStorage is available before trying to use it in our triggers:

function storageIsAvailable () {
  try {
    window.localStorage.setItem('_qb_test', '1')
    window.localStorage.getItem('_qb_test')
    window.localStorage.removeItem('_qb_test')
   return true
  } catch (e) {
    return false
  }
}

if (storageIsAvailable()) {
  // safe to use window.localStorage
}

This will exclude those users who are on private safari mobile from seeing the experience.

If a visitor has cleared their browsing history and cookies but has previously been on a site and added to a segment, will they see the same experience if they log in?

No, they will be treated as a new visitor.

Why do we sometimes see very different Conversion Rates between the Qubit dashboard and Google Analytics?

Qubit treats a conversion after a visitor has been exposed to an experience as one influenced by that experience, whether it’s immediate or in a later session. So for comparisons, the corresponding Google Analytics (GA) segments must be user-based, not session-based.

The Qubit dashboard bases the Conversion Rate (CR) on the proportion of visitors who subsequently convert. GA has both that CR measure and a rather different ecommerce Conversion Rate, which counts the proportion of sessions in which there’s a conversion.

The essential difference comes down to the definition used by Qubit for Conversion Rate and the additional ecommerce definition used by Google:

Qubit’s definition measures whether visitors convert, whereas the ecommerce definition measures speed to purchase.

What’s the Qubit poller?

Qubit has developed a ‘poller’ that can be used to poll for elements on the page that are used as requisites for building personalizations.

See Polling for elements.

I’ve paused an experience but I continue to see conversions, why is that?

Any conversions that occurred before the experience was paused will be counted for two weeks after the experience was paused.

Will visitors continue to see experiences after it has been paused?

Yes, this is possible. Qubit re-publishes the Smartserve script when an experience is paused. However, since we have no control over the browser, it’s possible that a cached version of Smartserve will continue to be used. Until the browser cache is cleared, whether manually or automatically, visitors may continue to be served an experience.

What’s the difference between user_id and Qubit’s visitor ID

context_id is the unique visitorId that’s held in the qubitTracker on the visitor’s browser—​it’s how Qubit maintains continuity for a visitor. If a site has its own visitor identifier, and that’s available in the browser, it can also be set to take the value of a client-specific identifier for visitors.

Note

When on a Android or iOS device, context_id is the deviceId.

user_id is an identifier designed for logged-in visitors; Qubit receives this via User events alongside other relevant user info such as name, loyalty data, and demographics. Because it’s only available for logged-in visitors, it’s comparatively rare.

A client’s site can use its own cookies to infer a previous user_id for a visitor and share that with Qubit in the User event. This may be deemed a "soft login".

An individual user (person) may access a website using multiple devices or browsers. Cookies can’t be shared between those devices/browsers, so the individual will have multiple context_ids.

Qubit can, of course, link user_ids and context_ids, but this is complicated, so it must be done with care because the relationships can be:

  • 1 to 1

  • 1 to many (when a person uses different devices/browsers)

  • many to 1 (a shared device such as an internet café or a family computer)