Segmentation

Segment membership is currently not cross-device, except for segments which use external data imported into our Data Store.

For segments which use external data, if the imported join user identifier is device common, segments can target the visitor on any device where the identifier is seen based on a deterministic match. For instance, if a CRM gold customer’s dataset is imported keyed on user Ids, and these user Ids are common on mobile and desktop, the visitor will enter the segment on both devices.

In the Simple builder you’re restricted to the list of currently supported conditions. In a future release, support for custom QProtocol schema in the segment builder UI will be provided, and it will be possible to edit the underlying segment specification to have full flexibility on the segmentation fields.

For more advanced and custom segments, we recommend you use the Advanced builder.

Yes. It’s possible to use Qubit Import to upload a dataset containing external segment memberships. You can then target these users by selecting the Imports condition. See our tutorial Using Imported Data to Create Segments.

When visitors enter and leave segments, a segmentMembershipChangedEvent is generated, indicating which segment was entered or left, by which visitor, and in which context, e.g what was their state, what pages were they browsing, etc. This information can be joined to all other visitor events used for analysis, to answer questions such as:

This functionality is available to all customers who have access to QProtocol events via Live Tap.

When Adaptive Targeting is enabled, an additional piece of code is included in the Qubit SmartServe bundle to facilitate dynamic segmentation. This code will only execute if segments have been defined in either the Simple builder or Advanced builder. If segments haven’t been created there will be no observable change in the client-side runtime.

If segments are defined, we collect a tiny amount of state from the user’s activity related to the conditions in the active segments. This could include things like whether they have purchased relevant products or counts of how many times they have performed a particular action. The contents of this state is directly correlated with the number of segments defined and their complexity. If there are less than 20 segments, the content will be very small, if there are 100+ it will be much larger. A number of methods are used to ensure that this state is kept as small as possible.

Segment references, condition flags, and numbers each have their own encoding which should result in the smallest data size necessary for the required state. This state is primarily stored within the qb_permanent cookie.

For reporting purposes, it’s also sent to the Adaptive Targeting back-end on change. The number of changes is heavily dependent on the type of segments defined. In typical circumstances, the change is once per page load. The request is slightly delayed from the page load to avoid interfering with initial load and rendering times, and should be very small, less than 250B.

Depending on your licensing agreement with Qubit, it’s possible to upload a .csv file manually. We also provide the possibility to automate the upload process through a programmatic upload to GCS. See Importing Your Data for further details.

Each user’s segment membership is stored in their cookie for performance reasons. Depending on your licensing agreement with Qubit, it’s also possible to synchronize segment membership to our Data Store for server-side access.

For each visitor, a JSON object is saved, against their visitor Id in Stash. This object contains their segment membership, keyed on segment ID, available on app.qubit URLs.

This information can be retrieved by calling the Stash API.

For example:

https://stash.qubitproducts.com/stash/v1.1/kv/set/{propertyId}/public/current-memberships-{visitorId}

You must use a JSON parser library to convert the data field back into a queryable object.

Information on our standard SLAs can be found here.

We commit to SLAs regarding data collection uptimes and user interface uptimes as these are within our control. Any sort of round-trip time, or other latency, is outside of our control.

We have a dedicated export to meet this customer need. See Experiences - Customer Breakdown Export

We can use the membership state in the user’s cookie to query whether the user is a member of the segment that the experience is targeting.

By wrapping the request in the Qubit poller module, we can wait for the evaluation of that query before triggering the personalization.

Look at the following example:

Qubit’s Experiences uses an internal API, so you can immediately target an experience from segment membership.

Yes. It’s possible to use user.id from the QProtocol events generated in a browser and match based on that.

Refer to What’s the impact of Adaptive Targeting on site performance? and Where’s segment membership stored? Can it be accessed server side?.

We bit mask values into characters, so if we have conditions in segments like has spent more than $500 and visited a certain page, they can all be compressed into a single character.

When you create segments, we create a segment index that’s included in Smartserve. This is a hyper-optimized blob of what fields we care about in which events. Then, when running in Smartserve, we process that subset and set a tiny amount of state in a cookie.

When you create an experience, you can select which segments to include and exclude. If you upload data, we can create the segment in the UI and include this in the experience. Generally, this check is included in Smartserve, as we look for the events on site. This is why there’s no client-side request for segment membership.

We use a 3rd party solution. If you append ?qubit_debugger to the end of a live segment’s URL, you can use the debugger tool to look at the data coming through. The tooltip on the right of the page lists each event as it’s detected.

Segment definitions and the Segmentation Engine are held within the Smartserve script. As a visitor performs actions on a page, QProtocol events are emitted. The Segmentation Engine evaluates these events, in real time, and determines whether that visitor should fall into or out of a segment. A user’s segment membership is communicated to Qubit’s back end using segmentMembershipChanged QProtocol events.

Once per session. We look up geolocation and elements of visitor history, including:

What are the endpoints for the Segment Membership API?

We recommend using the PHP library for querying a user’s membership. Technically, it’s just calling into a specific area of Stash, but the keys may be subject to change and shouldn’t be considered a public API.

Yes, but it can be session limited.

No, the segment will not go live until smartserve.js is published.

In this scenario, the visitor will be immediately served the new experience.

The advanced editor is heavily secured to ensure that regardless of what’s entered as code, it can’t negatively impact a site. The worst case scenario is that a segment code is wrong or has conflicting conditions so no visitors enter the segment. This will be visible from the segment metrics page.

Tying changes to key metrics such as RPV and AOV over the lifetime of a segment that result from changes to a site, such as a sale, event, or personalized experience to discernible changes in visitor behavior is a real challenge.

By focusing on recent-past data, we’re able to more easily detect and report on positive and negative behavioral spikes than when basing our calculations on a relatively longer period of time.

Data shown in the vertical specific metrics modules, such as top products and categories comes straight from the QProtocol data we collect from a site. We do not clean the data so we have the most accurate view of what’s happening on your site and in the segment.

This is typically due to issues related to the collection of site data.

Your first port of call, when resolving data collection issues is the Validation dashboard, which will help you identify issues for speedy resolution.

Failing that, reach out to your CSM at Qubit.

This can be achieved by passing the list of region codes associated with each nation in the UK into your segment condition.

For example, to build a segment to target people in Wales, you could use the following XML code:

Refer to the following table: