Katie Lawson

Aug 21, 2018

Personalization and Hybrid Support for Single Page Applications

Part 4 of a 4 part series.

Previously in this series we discussed SPA 101, why SPAs and CMSs have historically not been friends, how BloomReach offers SPA ease for developers and marketers, and now we’ll wrap it up with a look at two very important features when using SPAs at an enterprise level: personalization and hybrid support.

Relevance/Personalization for SPAs

This is where BloomReach’s server-side, component-based personalization really comes in clutch. BloomReach personalization is done by

  • creating variants of content and components,
  • gathering the right data natively and via APIs, and
  • segmenting visitors to determine who sees what.

For example, let's say you are an outdoor equipment company and your most profitable customers fall in two camps (no pun intended), the “extreme adventurers” and the “casual campers”. Now, you have a new line of tents you want to sell to both groups - and you want to get a little creative doing this.

Because you have two different audiences that value different things, you decide to make two different  banners. One for the extreme adventurers that highlights how light and versatile the tent is and and one for the casual campers, where you show the tent in a way more casual setting, like an image of a group of friends making s’mores in front of the tent.

But you do not have to stop there. With BloomReach Experience, it is very easy to spice things up a bit. So, you make another variant showing the (clearly incredibly durable) tent in extreme weather, and for the casual campers you show a cozy view from inside the tent while it gently rains outside.

Now you have 5 variants, the normal banner, extreme adventurer sunny, extreme adventurer rainy, casual camper sunny, casual camper rainy.

Let’s take a look at what happens when a visitor enters the site and how BloomReach Experience personalizes the page in real-time:

  1. The browser (or in this case the SPA) does the request for the home page.
  2. The BloomReach server receives the request and the BloomReach Experience Relevance module kicks in.
  3. The Relevance module will fetch all the information and load the right content based on the relevance profile that is created.

In a way, this conversation goes something like this:

The correct page is loaded and presented to the SPA. It is important to realize that this happens every time a page is requested, ensuring that the BloomReach Experience Relevance Module will constantly update the information that is known about the visitor.

This is best explained if we take a look at what happens when the visitor goes back to the homepage after browsing several pages.

The SPA renders the page, the visitor thinks “Ya know, I do need a tent that can survive storms”, he buys the tent, has an amazing adventures. All is well.

Determining the right content to deliver is done on the back-end, so the map the Page Model API delivers to the SPA already has personalization in there. This means that there is no javascript, front-end personalization tool fighting with your SPA when rendering the page. And you can test all the different variations as well, by leveraging the Experiments feature.

Our CMS already did personalization this way, so we really didn’t change anything about it to be SPA compatible - we simply apply relevance to our new Page Model API to make it readable for SPAs.

So what can you personalize on with an SPA? Literally anything you can collect - browser behavior, time of day, day of the week, information from your other tools like marketing or e-commerce platforms.

A common ways we see our customers start using relevance (with or without an SPA) is with inbound marketing campaigns. If a customer clicks an ad about “how to start saving for retirement in your 20s” their view of the homepage will show information on 401Ks, buying your first home, and more bold investing options. If a customer comes in through an add on “how to start a college fund for your baby” they will see a homepage that has information on life insurance, budgeting tips, and more low-risk investing options.

Hybrid Support for SPAs

Many companies will use SPAs on one part of their site while keeping other parts as a more traditional server-side page. To make this a cohesive experience - for both your visitors and your marketing team - your platform needs to support both forms of presentation to reduce data silos and fragmentation of the experience.

BloomReach’s core separation of content and presentation is what makes this possible. We dove more into the benefits of decoupled content in Part 3, but a quick summary is that because BloomReach stores content independent of how it’s viewed on a page, that content can be used across channels, including SPAs.

Another key aspect of this hybrid support is to be able to link within and between SPAs and traditional pages. In BloomReach, this is handled by the ability to map each piece of content can to an individual URL. When creating content, you’ll have a choice to make an “internal” or “external” link. An internal link means the content can be represented within the current SPA, and the SPA will only do a partial page update instead of making a full page request. An external link is used to navigate to content outside of the SPA.

This linking is communicated through the Page Model API, which outputs links for:

  • The current URL (the page)
  • Per component
  • Per component model (eg a menu)
  • For each content item
  • For rich content links

For example, let’s say your blog is done via and SPA while your homepage is a traditional server side page. In the setup, you can say that everything below “/blog” has the same application ID so is part of the blog app, aka an inherited child item.

Now if you are linking between blogs that is an “internal” link, and your SPA will only call for the new blog text and images. Linking from the blog to the homepage will be an “external” link and a traditional page load (non-SPA) will be made. 

With this link set up, and the decoupling of content and code, you can combine an SPA with server side pages, or multiple SPAs, or server side pages and a Reach App and an Angular App, or a combination of any of the above.

Your architecture is more scalable, content and logic can be shared, and marketing teams don’t need to worry if their content is in an SPA or not, they can create and link as usual.

Ultimately, with this Hybrid Setup, server-side personalization, and the editing features discussed in Part 3,

  • Developers can use SPAs at an Enterprise level,
  • Marketers are happy to use SPAs because editing works exactly how they are used to,
  • Your visitors get a incredibly engaging experience that feels cohesive at all times.

It is a win win win.

How to Use Single Page Applications with a CMS

Prefer PDF? Read the full SPA story here. 

download the guide
How to Use Single Page Applications with a CMS