How I fell in love with personalization as a developer

Before we start, let's get on the same page about what I mean by personalization.

What is personalization, anyway?

Is this?"Hi, Jim"?in your email? Yeah, that's one of the examples. In a web experience context, I am explicitly referring to the ability to modify content and display on a component level and render contextualized pages based on visitor context. For example, hide the announcement bar for visitors from specific regions or show an alternative Hero component for loyal customers.

When I used to call myself a web developer, the topic of personalization was giving me a ton of stress.

In this post, I will shed some light on our journey at Uniform, where we solved the underlying technology constraints that were causing many top brands to abandon personalization programs, which also enabled me as a developer to not stress out about any personalization activation project, no matter how ambitious it is. It's worth reminding the reader that technology is one of the factors here, and people + process have much to do with running a successful personalization program. As a technologist, I will focus on tech and let other experts chime in on other aspects.

Looking back to the late 2000s

Heavy Digital Experience Platforms of the past decade made enabling server-side personalization and A/B testing a tricky proposition, especially if your solution wasn't built right to support it, or the infrastructure wasn't ready to handle it.

"Is our site built right to support personalization"?

"Can our <insert_cloud_here> handle the extra load"?

"What infrastructure changes do we need to make to enable this feature?"

"What would be the cost of running it all in our <insert_cloud_here> environment?"

Do these sound familiar to you as well, or am I getting old?

On the infrastructure side, you had to say "bah bai" to CDN caching since the personalization execution would need to happen server-side. It is still amazing how many CMS sites continue rendering pages on the server without any CDN caching. Then, you had to introduce a session state to handle visitor context availability and tracking & persistence of user state. All on one "box". The site became slower, more difficult to scale, and more expensive to operate. This was very, very messy. This is where I witnessed too many cases of "Phase 2" for personalization. It was actually quite sad. Business folks were buying into a vision, but technology could not properly support it.

But we made a ton of progress as an industry. When new exciting alternatives emerged that allowed simply adding a <script /> and run DOM manipulation of your web pages, this streamlined the activation process so much, and the scale and state weren't your problem anymore.

The issue sort of re-surfaced itself in the recent 3-5 years, with web performance being one of the top SEO concerns along with the proliferation of the modern JavaScript UI libraries (React, Vue to name a few) and frameworks based on Virtual DOM. Orchestrating "who owns the DOM" is a tricky sequencing process, and doing render-blocking personalization is not great for UX and performance. The Jamstack architecture that helps bring Static Site Generators into the enterprise further elevated this problem; as there is no visitor context at build-time, how will you contextualize a static page? By pre-rendering a page per each permutation of a variant for a given condition? That's, as my favorite TV character says, kooky talk. We needed a better solution.

Fun self-deprecating fact: as a non-native speaker, I thought that Kramer was saying "Cookie talk" until just recently ??

Personalization SDK and edge re-rendering

The pursuit for a better solution is one of the things that jump-started the founding of Uniform. We acknowledged two things that were happening back in late 2019:?

1) the edge computing capabilities started maturing to the point where you can offload transformation jobs to the CDN and have it take care of scale, and since the visitor context was either on the request or in browser storage/session, there was no need for a server-side state or server-side processing?

2) realization that to make the personalization and A/B testing work well with your React/Vue website/web app, we gotta bring these capabilities lower in the layer, straight into the rendering process, by providing UI library/framework-specific SDKs.

For React, it would look like this - you import a <Personalize /> component from our SDK and place it wherever you need personalization to take place, then you provide it with an array of variations (which could come from anywhere) and a reference to the actual component to render when the variant is selected, in this case, Hero:

We also did the same with A/B testing:

The elegance and simplicity of this approach guarantee that the act of personalization is native to the rendering process of your app, and it can happen no matter where and how you render - during Server-side rendering or during hydration.

The static site generation approach was still a challenge, though. How do you know which variant to render ahead of time? Well, you don't. This is where edge re-rendering came to the rescue, allowing the live transformation of the statically rendered HTML with variants and having the special edge worker/function/middleware leave out variants that do not match the current context. This approach turned out to be very efficient since the most expensive part of rendering was already done ahead of time, and fairly lightweight transformation at the CDN level allowed keeping the benefits of static and removing the drawbacks of static, turning static into dynamic.

You can learn about our personalization capabilities from our docs.

Evolution of this approach

This approach served us well for a while, and it was fairly agnostic of an underlying source and compatible with many emerging meta-frameworks for React and Vue. There were drawbacks of this approach: 1) you needed to think where to place this functionality ahead of time, and 2) you needed to model the personalization and tests in your headless CMS. This works for topical cases, but it was tedious at scale, and ended up requiring extra content types, which may impact the license costs of some headless CMS.?

We figured that a first-class experience layer was the missing piece of the puzzle.

This is where we invested in Uniform Canvas, which formalized the role of components and compositions along with personalization and A/B tests and offloaded the configuration layer from a headless CMS that was never designed to handle it. This enabled a "one-click" activation of personalization and removed any developer friction in the process. Find a component, click "Personalize This" or "A/B Test This", specify the criteria, update content and publish.

As a developer, I didn't have to worry anymore about where else to sprinkle in <Personalize /> after the one-time activation of Uniform SDK inside your React- or Vue-based app.

Edge-side rendering (SSR on the edge)

The latest evolution of server-side rendering intersected with edge computing into a super sweet option called Edge-side Rendering. This combined the performance and elastic scale of static with the dynamic behavior of server-side rendering, as long as you can bring content into it fast enough.

We completely reworked our Next.js SDK to support this approach that leverages React Server Components and App Router. See our announcement from earlier this week?here. Alongside with the edge runtime support, the one-time activation approach became even easier.

This approach allows serving dynamic contextualized web experiences with the speed of static sites. Check out this personalized page built with Next.js Commerce rendered dynamically from the edge (you are seeing a different product due to the ?utm_audience=hipsters query string):

What else can you do with this?

Now that the boring plumbing bits are taken care of, developers can focus on building more compelling solutions and elevate the role of personalization even further.

Activate your customer data platform (CDP)

Personalization engines are like V8 engines - they need some high-octane fuel, and customer data is that fuel.

CDPs with Profile API, like Twilio Segment, can provide fast access to customer data, so all you need to do is set Uniform quirks based on the traits in the response, and the Uniform tracker will handle the rest. All components with personalizations using traits from CDP will automatically render the most relevant variant.

You can also set these values edge-side and server-side. A more detailed blog on how to do this is?here.

ABM marketing

Account-Based marketing technique is often empowered by tools like 6sense, Clearbit, and Demandbase. They provide intelligence data via API, which, similar to the CDP scenario above, can be used to fuel your marketing team's ABM campaigns. Imagine how effective it is to render relevant customer content fast to a visitor from the enterprise network.

Learn more about how these integrations work in our docs?here.

Tracker plugins

The Uniform Context tracker is built to be pluggable. As Uniform doesn't collect any visitor data, you can easily enable tracker plugins to send data about personalization or A/B testing anywhere you'd like. If you are using an exotic web analytics tool, you can help your team analyze the effectiveness of tests with just a few lines of code. Sync the scoring of visitors based on signals and push this into your data layer.

The docs with more details on how to create your own plugin are?here.

Behavioral personalization with privacy-first

Don't have a CDP to use for profile-based personalization? Not a problem! Uniform allows taking advantage of?Enrichments, which can be set programmatically based on external taxonomy (think product categories) or explicitly inside your CMS or Uniform compositions. Think about it as more advanced behavior content tagging where you can attach scores to each enrichment and collect aggregate interest scores as visitors browse content on your site. All this data never leaves the customer browser, unless you implement a sync with a user profile storage of your choice by adding your own tracker plugin.

There are different ways to set the enrichments.

1) You can wrap your component into the <Track /> component, pass the an array or a single enrichment object that will classify the visitor if the component enters the viewport and set the strength score 50 fir the audience = developer enrichment:

2. You can also set enrichments reactively on any event firing:

Build hyper-personalized web experiences

The signal- and intent-based system that Uniform personalization is built on allows you to implement unique contextual experiences.

A signal can be triggered with something like a query string, the presence of a Geo context (quirk), a cookie, or any event, such as a page visit, but you can also trigger signals programmatically.

Imagine some interactive component that engages your visitor, and based on the user interactions, you can interface with the Uniform Context with our React SDK (same with Vue) and mutate the state of the signals, quirks, enrichments, and influence what the visitor's experience without page reloading. This is where the Virtual DOM-based UI libraries shine. Update the context and instantly see the app re-render with the latest context.

Learn more about signals?here?and programmatic classification?here.

Influencing search relevance

For example, Algolia provides a cool capability called?Filter scoring, allowing you to add extra nuance to your ranking by?specifying scores?for different optional filters. The scores can be supplied by the Uniform Context SDK and passed to Algolia's instant search SDK. This will influence the sort order of search results based on real-time user?interests collected by Uniform tracker:

What's around the corner?

As a developer, this makes me seriously excited. I can spend more time engineering bespoke, interesting, contextualized web experiences and not worry about infrastructure, scaling, performance, refactoring my CMS implementation, or being distracted by plumbing work and glue code.

I am also looking forward to continuous innovations of the edge capabilities. Fast personalization based on user context requires fast access to visitor data, so edge databases like?Turso?are going to play an important role in keeping visitor data-dependent personalization efforts fast, no matter what the use case is.

And, of course, no blog post by the end of 2023 should be published without mentioning AI. Besides the technology constraints around the "execution" part of the personalization, which I hope this post made it clear that we solved this problem, two more aspects are worth considering.

The first one is the content volume problem. At the risk of stating the obvious, the more you run personalization, the more content you need. With generative AI infiltrating our lives more and more, content volume is less of a problem these days. At Uniform, we recently announced the support for the ability to bring your own generative AI models of your choice directly into Uniform's Visual Workspace. Access to pre-configured prompts is at your marketer's fingertips in any content field, and your technical teams can decide what AI models and prompts are appropriate and where they can be used. Besides text content, you get access to desired image-generation models. Learn more about our AI-assisted content creation and management in Adam Conn's recent blog post?here.

The second aspect is the automation of the personalization criteria setup. Portable AI models running at the edge are a game changer here. If you have yet to see where?Cloudflare is going with Workers AI, check it out.

Perhaps marketers will soon be comfortable running personalization on auto-pilot and sit back, relax, and enjoy?the 10 to 25% revenue lift, and we, the developers, can spend more time fine-tuning the animations.

Oh wait… that is handled by AI as well.