The Realities Of Modern Personalization

Personalization with Ninetailed
or: here's why we're bullish on the Stackbit+Ninetailed partnership

Anyone who’s worked with personalization knows that it’s great in theory, but very difficult to succeed at in practice. Typically, there are both organizational and technical factors at play, leading to friction and frustration.

We can provide the guidance necessary for your personalization program to achieve its goals, by contextualizing the conversation individually for each stakeholder in your organization.

The 2 Biggest Challenges with Personalization

Personalization for your website: Everyone says they’re doing it. Everyone says you should do it, too. Your bosses want to see it happen. It’s money on the table! Perhaps you’ve even tried to do it before.

And if you have, you know that it’s a labor-intensive process, fraught with technical issues, and integrating personalization providers with your website(s) is a pain. There are just too many moving pieces and frustrating constraints.

There are two main reasons this process is so challenging: the organizational push and tech woes.

The Organizational Push

There’s no denying that it takes a tremendous amount of effort for a personalization program to materialize. You may be able to swing your first few wins easily, but only with significant help from the personalization vendor. Eventually, the reality of the massive effort required will sink in.

To be successful, you need to be creative, take risks, and be willing to coordinate and sell your initiatives with multiple stakeholders, many of whom may not be fully engaged until they see hard proof of the ROI (a classic Catch-22). And sometimes, a promising test will just fail to show the meaningful results you’ve been hoping for.

The Tech Woes

The prosaic technical reality of implementing personalization often conspires against successful execution.

Often, it’s page performance and annoying visual artifacts that suffer as a result of integrating a personalization tool. Then there are also browser constraints and new regulations to consider. And of course, there could always be (and usually is…) something incorrectly wired in the implementation.

The classic approach of client-side personalization did have its upside: once you’ve injected that pesky JavaScript file onto your site, you’re relatively free to create and preview personalized experiences. It was never a completely smooth integration, but it kinda worked.

But, while the emergence of APIs and web frameworks helped solve many of the technical and performance issues, the actual user experience of creating and maintaining personalized experiences has taken a big step backwards.

Implementing personalization doesn’t have to be a power play

Content Ops (marketing, digital, and personalization teams) usually get the raw end of technical tooling. As a result, many of these folks have become too skeptical to believe that a better experience is possible. While developers tend to be vocal and picky, content folks often make do with mediocre tools.

This imbalance leads to friction among these internal groups, which can result in a major reshuffling of tools any time one side (content vs. developers) gets the upper hand.

I’ve seen it, and it’s not healthy. Personalization tooling decisions should never be about who has more power.

Can Personalization Really be Different?

The short answer: Yes!

Even as we’re just starting down the path of what this collaboration can offer, we’ve identified two primary areas of focus to address the challenges mentioned above:

  • Provide a superior authoring experience: Velocity and independence to content creators should be considered table stakes. Just as it used to be with classic tools, but even better by leveraging current technological capabilities. Creating and editing experiences should be both visual and tightly integrated into the website’s content editing UI — not a bolted-on feature.

  • Maintain developer happiness: we must maintain (or ideally: increase) the developer experience of today’s personalization tools, which means providing minimal code requirements. Developers should never have to make code changes for each and every new personalized interaction. Developers don’t want that, and neither do editors.

Managing to keep both sides productive and happy means actually being able to move from ideation to execution to iteration in short intervals, without ongoing developer intervention.

Ninetailed Provides the Personalization 

Ninetailed has honed in on what a personalization tool should do in a modern web environment (and beyond) by providing a composable experience.

Admittedly, this word (composable) seems to be everywhere these days — all too often in a vague context. In this context, the composability of Ninetailed means:

  • Meet editors where they are: It should not make you learn yet another UI that you have to log into and use on a daily basis. It is better to integrate with established headless CMS systems.

  • Leverage established analytics tools: It should not try to have its own data collection and analytics silo. You’re going to be more trusting of the analytics tools you already use (and pay for), and should be able to continue to use these tools, even after adding personalization capabilities to your team.

  • Respond in real-time: It should be fast to respond and process user events in near-real-time, including merging profiles from multiple devices. When it comes to personalization, lags mean missed opportunities in a user’s session.

  • Provide an API-first service: It should have first-class APIs and SDKs so developers can make decisions and load data from anywhere. The more it stays out of your way, the more effective it is to your team.

These points mean that Ninetailed can focus on the core tasks of a better personalization product, while not getting bogged down by complex peripheral tasks that other tools in your stack are already dedicated to providing. As an added benefit, this also translates to Ninetailed’s ability to offer competitive pricing.

Stackbit Brings the Content Editing Experience

At Stackbit, we’re ultra-focused on balancing the quality of life for both content ops and dev teams. We do this by providing a world-class editing experience for content ops, while allowing developers to bring their own stack.

Let’s explore how the combination of Stackbit and Ninetailed provides an optimized experience for both content ops teams and developers.

Making Personalization Changes in Context and in Real-Time

This integration brings Ninetailed’s capabilities straight into Stackbit’s visual editor. Instead of editing in a CMS interface (which can be intimidating and confusing) and waiting long periods of time for changes to appear in some internal environment, the effect of a personalization-driven content change is immediate — you see exactly what you’re doing as you’re doing it.

The video below shows this process in action.

The Developer Experience

For developers, enabling this integrated experience is easy and unobtrusive to a website’s code. And it is enabled in the same way across any component using personalized content.

In the example Next.js (React) site used in the demo above, we made enabling personalization for a component as easy as wrapping the component code in a withPersonalization helper. (View the source code on GitHub.) You could also roll your own for any other web framework.

The Next Generation of Personalization on the Web

We’re confident that we can provide concrete guidance on the challenges of personalization for the multiple stakeholders in your organization.

We understand the jobs to be done for each team. And we’re used to working with organizations in the process of a major overhaul of team structure, a massive tech stack retooling, or (often) both.

We’re ready to be partners on your journey.