FAQ: BlueConic JavaScript tag

Step one of using BlueConic is to get a JavaScript tag placed on all the pages where you’re going to want to collect data and interact with your visitors (documentation and step-by-step instructions on that can be found here). Have questions about the BlueConic JavaScript tag? We've got answers!

How big is your code and will it slow down our site?

From your standpoint, the BlueConic code snippet is two lines long. That’s all you’ll need to give your developers. We’ve compressed the file that has all of the power of the platform to make it as small as possible. On a person’s first visit to the site, the end user downloads the BlueConic library (‘blueconic. min.js’) and the ‘Big Library’, containing all interaction type definitions (JavaScript code) and external libraries needed.

Can I deploy the BlueConic tag with our tag management tool?

When placing the tag in or near the header in the HTML, the page in the browser is not rendered yet, which allows BlueConic to execute personalization in the page before the position on the page where that unique interaction will occur is rendered.

If a personalization tag (from BlueConic or from others, for that matter) is loaded through a tag manager, there will be a long enough delay that there is a risk that the page is already rendered, so then the user sees the original content in a part of the page first, and then that page gets overwritten by the personalized content.

Here’s our way of ensuring the load is as fast as possible:

  • The BlueConic tag contains all libraries needed to do personalization, and is loaded only once for a first-time visitor. After that first visit, those libraries are cached in the browser and not reloaded over the network again.

  • The tag is minimized and gzip compressed (for comparison: at about 40kb, the tag is smaller than most pictures on a website)

  • The tag is placed on CloudFront CDN from Amazon to ensure the tag is always loaded as fast as possible

    If you’re not using BlueConic for personalization, then this is all moot and you can deploy through your tag manager and call it a day.

Our CMS is old/highly customized/monstrous/complex. Can we still use BlueConic?

You bet. A CMS takes care of rendering the HTML for a website server-side, meaning the browser asks the webserver for a page, and the CMS creates the HTML and other assets for a page and sends it back to the browser.

Like other types of web-based tools, BlueConic work completely in the browser. We do not interfere or integrate with the CMS itself, only with the resulting HTML that the CMS spits out. For that reason, it doesn’t really matter what kind of CMS you have: BlueConic can always work with your website.

OK, but what about flicker?

After years of working in web tech, we built in smart mechanisms to prevent flicker effect even when loading is slow; for example, whitening out the part of the webpage where personalization will take place immediately while rendering the page, until BlueConic is sure that it is going to personalize that placement, or revert to the original content.

We have an SPI/SPA site. Still fine?

For 95% of our customers, embedding the code gets everything working out-of-the-box and you just have to go, go, go! For the other 5% of our customers, which typically are SPI/SPA, they can require some additional configuration and/or development on BlueConic’s part to get things working. This usually means deploying a plugin, which will handle the dynamic page transitions.