Configure Social proof experiences

Goals enable you to define the criteria that you will use to evaluate whether an experience's variations have been successful compared to your control. Which goals you choose will depend on the reason for running the experience.

For example, you might want to check that a visitor is creating a basket. You could do this by adding the relevant QP event as a goal:

You could take this 1 step further and check whether a visitor adds a product from the category shoes to their basket:

TIP: If you would like to learn a bit more about QP goals, you might be interested in our product video.

All experience goals consist of a primary goal and secondary goals. The default primary goal is Conversion Rate, which you can change, if necessary.

An experience is considered complete when the primary goal has reached statistical significance. This simply means that we have collected enough data to be certain that the observed change in, for example, Conversion Rate, is due to the experience being shown to visitors and not some unknown factor.

INFO: Secondary goals are measured but do not define whether the experience is successful or not.

See Goals and success for more information and Testing and Evaluating Experiences for a more in-depth look at A/B testing and Qubit's stats engine.

Select Edit in Goals. Then select a goal from the Add new goal combo box

Select Save to finish

INFO: Depending on the goal you select, you will be required to enter additional information. For example, if you select the goal Page URL, you will have to select either contains or matches regex and then enter the page URL you wish to track for the goal.

Select against the goal you wish to make the primary goal

will display against the primary goal

WARNING: You cannot change the primary once you have published an experience, even if you subsequently pause it. If you want to change the primary goal for an experience that is or has been live, we recommend duplicating it and then setting the desired primary goal.

You can use the emitCustomGoal function to add custom goals to an experience. A custom goal might be linked to the firing of a particular QP event or an interaction with a button or similar UI element.

This function is typically added to triggers.js, where your want the goal to apply to both the control and any variations in an experience, but could equally be added to variation.js if you want the goal to be emitted when the visitor interacts with something you built specifically for the experience variation, for example, a button or similar UI element. See Emitting Custom Goals for more details.

What can you achieve with QP goals? Well, let's look at some examples:

• You can send a goal based on a user purchasing a certain product after seeing an experience:

• You can set a goal based on a user having a certain amount in their basket after seeing an experience:

• Or, you could set a goal for a certain defined depth of user journey, such as a second pageview in the session:

Integrations are developed using Node.js functions inside the Qubit platform and then deployed into Qubit managed infrastructure. Once deployed, they can be invoked from experiences and experience templates.

Select Edit in Integrations and then select an integration from the Add new integration combo box

See Qubit Integrations for more information and Building Integrations if you want to jump straight in and starting building an integration.

By selecting segments you can determine which groups of visitors will be exposed to the experience.

When targeting segments with an experience, you can combine segments using AND, OR, and OR/AND conditions to target more specific and business relevant groups of visitors.

WARNING: The percentage of visitors in an included segment that actually see the experience will depend on the traffic allocation split.

A focus on location-based segmentation

It is important to recognize that the accuracy of location-based segmentation is dependent on IP geolocation, a method that employs an approach called whois to obtain an Internet Protocol address (IP)-a unique identifier-to resolve a device's or network location against a maintained database of physical locations.

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 and at both ends of the spectrum, accuracy is entirely dependent on efforts to ensure the databases storing location details are up-to-date.

The issue of accuracy is clouded somewhat when targeting mobile visitors, on devices that rely on mobile connections for internet connectivity. This is because the device's IP will typically be resolved to the location of the carrier's mobile switching center rather than the location of the device itself.

Select Edit in Segments and either the Include OR Exclude tab

Select one or more segments from the Select one or more multiple segments... combo box and select Save to finish

• Target visitors in a segment AND in another segment
• Target visitors not in a segment AND not in another segment

Select a segment from the Include people who are part of at least one of the following segments combo box and then select Add another group of segments

Select a segment from the as well as at least one of these combo box and then Save to finish

In the following example, the user has chosen to serve an experience to visitors in the VIP segment AND in the Not purchased in the last 2 weeks segment:

In this scenario, only the visitors that belong to both segments would be served any linked experiences.

• Target visitors in a segment OR in another segment
• Target visitors not in a segment OR not in another segment

Select 1 or more segments from the Include people who are part of at least one of the following segments combo box

In the following example, the user has chosen to serve an experience to visitors in the English Speakers OR French Speakers segments:

In this scenario, visitors that belong to either segment would be served any linked experiences.

• Target visitors in a segment OR in another segment AND in another segment
• Target visitors not in a segment OR not in another segment AND not in another segment

Select 1 or more segments from the Include people who are part of at least one of the following segments combo box and then select Add another group of segments

Select a segment from the as well as at least one of these combo box and then Save to finish

In the following example, the user has chosen to serve an experience to visitors in the English Speakers OR in the French Speakers segments AND in the VIP segment:

In this scenario, only visitors that belong to either the French Speakers OR the English speakers segment AND the VIP segment would be served any linked experiences.

These settings allow you to define the percentage of visitors that will see the experience control vs the experience variation(s).

Those visitors that do not see any of the experience variations will see the same page or pages but without the experience. This is referred to as the control.

DANGER: We prevent changes to traffic splits that flip users from a variation into the control once the experience has been published. See Traffic Allocation Modes for more information.

We offer 4 standard traffic allocation modes: Pilot, Split, Supervised, All traffic, and the possibility to set your own custom traffic allocations.

Select Edit in Traffic Allocation and then either select one of the standard modes or select the Custom split toggle and assign your own allocations to the control and variation(s)

INFO: The percentage of visitors that will see a variation will change according to the number of experience variations you create. For example, if you select the option Pilot, with a single variation and control, the percentage will be 20% variation and 80% control. With 2 variations, the split will be 10% variation 1, 10% variation 2, and 80% control.

WARNING: In a custom allocation, the percentage total must be equal to 100. Each variation must be allocated a percentage value between 1 and 99.

In the following example, the user has chosen to use a custom traffic allocation:

Select Save to finish

As mentioned, for many reasons, but principally in the interests of statistical robustness, we do not allow changes to splits that will result in users flipping from the variation into the control. Instead, we recommend duplicating the experience and re-running it with the desired split.

For readers looking for more information about standard modes and the answers to more FAQs, head over to our Traffic Allocation Modes article.

These settings allow you to define where and when the experience will fire. Triggers only become relevant if the visitor has met the rules for any segments included or excluded in the experience.

Triggers are checked every pageview. If no triggers are set, the experience will fire on every pageview.

When selecting triggers, you can filter the list by entering a search term in the Add new condition combo box.

Select Edit in Triggers and then select a trigger from the Add new condition combo box

Select Save to finish

See Experience Triggers for information about each trigger.

For those with JavaScript experience, triggers can also be written in JavaScript using an in-browser editor. See triggers.js for more information.

Select Edit in Triggers and then next to Custom JavaScript

In triggers.js, add your triggers as necessary and select Save to finish

There are two ways of implementing this function, the callback based method or the promise based method.

Both methods allow you to provide a boolean value to determine whether or not the experience should fire.

However, the promise method has the additional advantage that any asynchronous errors that cause the promise chain to be rejected will be captured and reported in the UI.

Callback based syntax:

module.exports = function triggers (options, cb) {
  cb(true)
}

Promise based syntax:

const Promise = require('sync-p/extra')

// The following are equivalent:

module.exports = function triggers (options) {
  return Promise.resolve()
}

module.exports = function triggers (options) {
  return Promise.resolve(true)
}

module.exports = function triggers (options) {
  return Promise.resolve({ execute: true })
}

In this section we will look at a few examples that you can use to get started.

This can be used to poll for certain elements to ensure they are on the page before the variation JS is ran. It can poll for an array of elements or an outcome of functions within the array:

module.exports = function triggers (options) {
  return require('@qubit/poller')([/* array of elements and / or functions */], cb)
}

Example:

module.exports = function triggers (options, cb) {
  return require('@qubit/poller')([
    '.product_image',
    '.product_title',
    function () {
      var active = a === 0
      return active
    }
  ])
}

Within experiences, we expose the options object. Within this there are the getVisitorState and getBrowserState functions. The following can be used to return the pageview number in the user's current session.

Example:

options.getVisitorState().then(function (data) {
  console.log(data.viewNumber)
})

This can be used to return the total session count for a visitor.

Example:

options.getVisitorState().then(function (data) {
  console.log(data.sessionNumber)
})

DANGER: We strongly advise against changing the winning threshold percentage or effect size percentage whilst an experience is running.

WARNING: By default, Qubit will declare an experience a winner if there is a 95% probability (credible interval) of a 5% uplift (effect size), 80% of the time (power).

WARNING: You cannot edit custom statistical thresholds once you have published an experience, even if you subsequently pause it. If you want to change the thresholds for an experience that is or has been live, we recommend duplicating it and then setting the desired custom thresholds.

INFO: Since the release of Statistical Power, it is not necessary to set an effect size. It is no longer used to determine if we have reached 'sample based on the observed number of visitors.

Make changes to the winning threshold and outlier removal as required, referring to the following explanations:

• Winning threshold - The default winning threshold for all Qubit Experiences is 95%. This is the standard in web-analytics

  By lowering the threshold, you will reduce the required sample size and therefore the time it takes for the experience to complete and get a result. Doing so is therefore often seen as an acceptable method of getting results quicker.

  As an example, with the default threshold, approximately 6000 converters are required to get a statistically significant result. The number of converters required reduces linearly with each percentage reduction:

  • 90% - approx 5000 converters
  • 85% - approx 4000 converters
  • 80% - approx 3000 converters

  However, we do not recommend changing the default winning threshold percentage, principally because you will increase the probability of getting a false positive result. Stated simply, the less converters you test against, the less robust your test results.

• Outlier removal - You can ignore the data generated by outliers by selecting the Outlier removal toggle

  This will remove the top 0.1% of spenders from the sample size to prevent the data from outliers interfering with the statistical analysis of an experience.

Select Save to confirm your changes

Changing the threshold to 90% is a good option, if you're interested in reaching sample size faster. The trade-off is that by moving faster, you increase the potential for false-positive test results.

Making this change would mean that you'd have 1/10 winners potentially being a statistical fluctuation instead of 1/20 with the 95%. This would mean that you would be 90% sure, instead of 95%, when the dashboard reports a winner.

By enabling our Google Analytics integration, you can send experience interaction data directly to your GA dashboard for tracking and analysis.

To turn on GA integration, select the Google Analytics integration toggle

INFO: You can enable the GA integration before or after publishing an experience. There is no need to republish or create a new experience iteration if you do it afterwards. However, you should be aware that events emitted before enabling the integration will not be sent to GA.

INFO: When a visitor is served an experience, Qubit will send a single custom event to GA and, for tags implemented via Google Tag Manager, a single GTM event. These events are only sent once per session when the visitor is served the experience.

WARNING: These events are only sent for published experiences.

Before you can use the data in Google Analytics, you must set it up to receive the data sent by Qubit and process it into a standard format. How you do this depends on how you have implemented the GA tag on your site.

If the tag has been hard coded, you only need to set up a segment in GA and pass the experience Event action Id and Event Label Id as advanced conditions.

See Creating Segments in Google Analytics for more information.

So that you can correctly identify the experience when creating the segment in GA, the card includes the Event action Id and Event label Id for the experience control and any experience variations:

INFO: To help you easily identify the experience control and variation in third-party integrations such as GA, we provide a method, via your prescript, to send a custom label rather than an Id. See our example for details.

If the tag has been implemented via GTM, you will need to set up the trigger, variable, and tag in GTM.

See Setting up GTM to send data to Google Analytics for more information.

For an in-depth discussion about GA integration with Qubit's Experiences, see Integrating Experiences with Google Analytics.

Scheduling is a good option if you would like to time an experience to automatically start and end in line with weekend messages, late night cut-offs, Black Friday messaging, campaigns, or promotions.

TIP: We give you the flexibility to start an experience ahead of its scheduled start and end an experience ahead of its scheduled end. See Modifying a schedule for details.

Before adding a schedule to an experience, please review the following points:

• The timezone used for scheduling is taken from the current timezone for the device used to set the schedule. As an example, if a user in London sets a schedule to end at 13:00 GMT, for visitors in Rome, which is in the time zone GMT + 1, the experience will end at 14:00

• All schedules must have a start date/time-by default this is the current date/time +1 hr
• There needs to be a minimum of 15 mins between the current time and the scheduled start time

• By default, the end date/time is the current date/start time +1hr
• There needs to be a minimum of 15 mins between the scheduled start time and the end time
• If you clear the end date/time, the experience will run continuously until you pause it
• When the end date/time is reached, the experience will be paused and visible in the Paused view

Open your experience and switch to the Settings tab. Select Edit in the Details card

Select a start date using the date picker and use the up, down, right, and left arrow keys on your keyboard to set the start time

Select an end date using the date picker and use the up, down, right, and left arrow keys on your keyboard to set the end time

In the following example, the user has scheduled the experience to start at 9 AM on Tuesday 14 November 2017 and end on Friday 17 November at 11:30 PM:

Select Save to confirm

The experience will now display in the Scheduled view in Experiences.

To give you a heads-up prior to going live, we'll notify you 30 minutes before the scheduled start date/time. You can see this notification in the Settings view:

INFO: We'll also notify you 30 minutes before the scheduled end date/time.

When the scheduled start date/time is reached, the experience will be automatically published and shown also in the Live view.

If your experience is scheduled to go live and you want to start it earlier, open the experience, select Publish experience and then Start schedule now

INFO: Bringing the schedule forward, ahead of its planned start date/time, does not affect the scheduled end date.

If your experience is scheduled to end and you want to end it earlier, open the experience, select Pause experience and then End schedule now

You can remove a schedule at any time, even if your experience is live.

Open your experience, switch to the Settings tab and select Edit in the Details card

Clear the scheduled start date and / or end date and select Save and then Save again to confirm

INFO: Removing the start date by itself means that you will have to publish the experience manually. It will still end automatically according to the scheduled end date.

INFO: Removing the end date by itself means that you will have to pause the experience manually. It will still start automatically according to the scheduled start date.

With the basic setup and configuration done, you are ready to hand the experience over to an engineer to complete the technical implementation.

When you click Save changes, the system will generate a link to the experience, which you can provide to the engineer responsible for performing this task. You can copy this link by selecting Copy link.

Once the experience has been completed, the final step will be to publish the experience. You can do this by selecting Publish experience. Before doing this, we recommend that you preview it on site to ensure that it fires correctly according to the designed triggers, displays correctly, and crucially that it functions according to your expectations. See Going Live With Your Experience.

When you publish an experience it will be pushed live onto your site or mobile platform. Visitors will be served the experience, of course depending on the conditions established for the experience, including triggers, segmentation, and traffic allocation.

Once an experience is live it will start to generate data, which you will use to interpret the success of the experience against its defined goals. See for details.