Developer tools for personalization
Personalization is often thought of as a marketing team (or merchandising team) endeavor.
However, when personalization gets ‘serious’, (and by that I mean customized, fully integrated, and dealing with high-volume, low-latency data) developers have to be involved.
Qubit has tools making it easier for developers to get on with doing a great job, saving time, effort and stress.
The Qubit Command Line Interface — building personalizations your way.
When dev teams are working on personalization… well, let’s be honest, we’re never going to be using a WYSIWYG tool. There’s a whole host of tools and version control systems that we’re already familiar with, and almost certainly our own preferred setup.
Having to get up to speed with a new one slows the process down. But with Qubit, you don’t have to. With our CLI, we let you keep your code in your own repo, your own ecosystem, and environment, and work with whatever tools fit in most with your day-to-day, then just push it up to Qubit.
There’s a host of benefits from doing the dev effort locally, like integrating personalization code into your CI/CD processes, applying your own style guide, hot reloading efficiency gains… It’s so good, it’s what our own internal teams use.
NPM packages mean no duplication of work.
So, you’ve written your code for a personalized experience and pushed it live. If it works (sometimes even if it doesn’t) marketing teams will probably ask you for the same thing again, maybe on another of your properties.
No one likes doing work twice.
So, you can release your code as a package and re-use it across your Qubit properties. We give you the choice of either releasing it to the public NPM repository, or to your own secure scope in our private registry. You can even make use of existing packages that other people have released on NPM, allowing you to get your work done just that little bit faster! As well as making your life easier, re-using code through packages helps to reduce the size of the Qubit client-side script. Win-win!
Templates — more scale, even less duplication of work.
Good news (at least to your marketing team!), the personalization you just pushed live was a wild success, and there are so many possibilities — for the same experience to different customer segments, or a slightly tweaked version with different creative or wording.
If that’s the case, then one of our most useful tools opens up a world of cross-team collaboration and efficiency. Devs can use the CLI (or UI) to create a template, defining configurable content that the marketer can control with a simple UI to feed the data back to the code.
Once the template’s tested, the developers can move onto the next project, while the marketers use and re-use the code, tailoring the content, imagery, trigger rules, or targeted customer segments.
Automatic updates with programmatic imports.
Segmentation is another area where Qubit sets out to improve efficiency. That’s because our segmentation is dynamic. Segments that are defined based on customer behavior include new visitors (and evict old ones) as they meet the criteria.
But there are other segments, not based on on-site behavior. Perhaps ones based on CRM data, or the outputs your data science team provide. Using programmatic imports, you can upload datasets into Google Cloud Storage on a regular schedule, which we will then ingest into our platform.
You can then use Qubit to define segments based on the dataset, with a simple UI to target a column in the dataset, or using advanced mode with XML syntax to apply logic. You can also query back the data in an experience with our API, or combine it with the on-site behavioral data to supercharge your segments.
Derive insights for even more advanced segmentation.
You can get even more nuanced with your segmentation, combining your Qubit data with information from other systems (more on this in a bit) to derive insight from multiple datasets and make them actionable as segments or experiences.
That lets you do things like combine the average “lifecycle” of a product (e.g. how long a tube of mascara usually lasts), with segments (customers who have bought that mascara), calculate the time elapsed since purchase, and at the appropriate moment, target those customers with reminders that they are about to run out of mascara.
Head into omni-channel with Integrations.
Most of the previous developer tools have been website-oriented. However, personalization should be an omni-channel proposition, reaching customers at the right time, in the right place and in the right way.
This might include SMS, or email or set-top-boxes. It might mean combining experiences together like an abandonment recovery experience with product recommendations included in the email.
With Qubit you can schedule personalized experiences for the future, write some code to get disparate elements together. When the code runs, (say, 20 minutes after a visitor left the site, leaving some items in their basket) an integration executes on the server to (for example) hit up the Qubit API for relevant recommendations and uses packages to pull in the ESPs NPM library and send the email.
You could even query your own proprietary internal stock API (if you have such a thing), for up to date inventory management, or send off an alert to your merchandisers’ internal slack chat, telling them that the top trending product on-site has changed.
Qubit API — the foundation of omni-channel personalization.
The Qubit API underpins everything that is possible in Qubit, and opens up the word of omni-channel personalization. All our experience types, every recommendation strategy, everything, is accessible via API, anywhere in Qubit that you write code, for any channel.
Genuinely, you can hook up anything with an API endpoint to provide data for creating personalizations, or as a channel to deliver personalization.
The limits here, really are your own imagination.
Another channel: going server-side.
In certain businesses, and with certain use cases (like if you want absolute control of the code or are conducting really large scale website testing and personalization) you can implement the experiences in your own code base, and call our server-side experience API to find out whether to show the control or variant.
This even supports templates, meaning that marketers can create personalizations with the safety, security and performance benefits of doing it on the server. And Qubit has first class support for React and Angular. So you won’t need to tell marketing they can’t A/B test or personalize now they’ve got their shiny new website.
A final thought for implementing a personalization project.
You don’t get something for nothing. If you’re doing personalization (or A/B testing) you’re going to take a performance hit somewhere. It’s important to manage these expectations with non-technical teams up front and present the options for mitigating the performance hit.
There are two options for how to add personalization scripts to a page, and it is a balancing act between pageload and flicker. An asynchronous setup, with the tag at the head of the page, minimizes pageload, but may expose the visitor to a small amount of perceived flicker. The alternative, synchronous, setup (again with the tag at the head of the page) minimizes flicker, but the trade-off is increased page latency.
Picking the right option for you depends on what your personalizations are doing, with considerations as to whether there’s a round trip — like talking to the Qubit API — involved, and what’s most important for your brand. Of course, if the risks of both of these options weigh heavily, you can think about server-side testing. (However, that also has its own set of risks… like requiring internal dev resource, and committing to Qubit becoming part of your critical path.)
You don’t get something for nothing.
But Qubit is committed to making it as easy as we can to give you as much as possible.
For more on personalization in practice, visit Qubit here.
