In recent years, we've seen single-page web applications — applications that operate within the same web page — grow in popularity. These apps provide a fluid user experience, allowing the user to take many actions at once without the need to load multiple pages. Instead, specific sections of the page will update, or the page can exist in multiple different "states." They are popular for applications in which a user needs to heavily interact with the content on the page, rather than simply consume the content.
A good example of a popular single-page app is Gmail. Gmail will not usually load a new page as the user takes different actions. Instead, the page remains the same while various pieces of it update with new content.
So how does personalization work with single-page apps? Personalization campaigns on a regular website or inside a traditional web-based app are usually triggered when a new page loads. Without the trigger of a new page loading in the case of a single-page app, it can be challenging to set up personalization campaigns.
What are the personalization challenges with single-page apps?
A key aspect of effective personalization is that the tailored experience should not be perceptible to the user. The main obstacle with single-page apps is that you can't rely on a new page to trigger a personalized message or experience in time for a user not to notice a change.
For additive messages, such as pop-ups, it is OK for content to load immediately after the rest of the page without disturbing the user experience. However, when a section of the site is replaced by personalized content, it is critical that these areas load as fast as the main content of the page. The user should not see flashes (aka "flicker") of other content before the personalized areas are fully loaded, as this would be a very poor user experience.
So how can a personalization solution identify when to trigger a personalized experience? And how can it do it quickly enough for the experience to appear seamless? Even though new pages will not load, in many cases the app will update the URL as a user engages with the page. This allows users to bookmark a link to return directly to the section and state of the page they were in, share that page with others, or even navigate through their browser histories.
In the instances when the URL does change, some personalization solutions can detect those changes and target campaigns as they would for any multi-page site. However, if the URL does not change, most solutions will not know when to trigger a personalized experience. Preventing flicker while doing so is even more difficult.
How does Evergage address these situations?
For many single-page apps, Evergage works right out of the box by simply changing a single setting to track the URL changes.
But when the URL does not change, the settings can be configured to record user activity and trigger personalization at the appropriate times, without the need to get developers involved. For example, let's say you would like to display a help message the first time a user selects a specific area of your app but has not taken an action that would change the URL (such as selecting a message in Gmail before performing any action such as deleting or marking it as unread).
In this situation, Evergage will check several times a second to see if the app is in the right state for the message, and activate it when the time is right. In this case, the URL did not change, but Evergage is able to display the message at the right time.
In contrast, many other personalization solutions leave it to you and your engineering team to figure out how to trigger personalization when these changes happen.
Single-page apps have many advantages but also have various complexities that multi-page sites do not have. But that is no reason not to run personalization campaigns that you test and optimize frequently. Just make sure that you ask detailed questions about single-page app support when doing your research on personalization solutions.