Web Personalization: By Humans, for Humans
You can’t spell “personalization” without “person.”
Digital marketers are no strangers to machine learning, especially when it comes to personalization. Machine learning, after all, powers product and content recommendations, next-best-offer campaigns, marketing automation, and countless other tasks that were once tedious and manual. This familiarity should comfort us as influencers flood LinkedIn with content about ChatGPT, the expanding reach of artificial intelligence, and executive eagerness to replace employees with emerging technologies: we already know that machines, on their own, can only do so much.
Yes, AI programs can spit out functioning web HTML code in response to a simple text prompt, but setting that new website up as an activation target for personalization campaigns still demands human knowledge and guidance. After all, the code-generating bots don’t (yet) know your organization’s marketing strategy, which MarTech tools make up your team’s stack, or even how many other websites are part of your marketing portfolio.
Applying this knowledge, along with some supportive web development work, can help keep a newly implemented personalization tool from getting in its own way, interfering with other software programs, and degrading the browsing experience for your customers.
Don’t pit your tools against each other
The heart of personalization is the affirmation of human individuality — the idea that each consumer is truly unique in their behaviors and characteristics. Bringing that to life through an HTML document in a web browser requires more than simply plugging in a tracking pixel and letting the algorithms work their magic. In fact, doing just that can create tangible conflict for IT, marketers, and customers.
Take, for example, the following scenario: a retail company is running tests on their homepage hero banner using a legacy A/B testing tool, experimenting with variations on images and text copy. They then decide to run a campaign in their new personalization tool to dynamically update that same homepage hero banner text with copy targeted specifically to visitors sourced from a paid media campaign.
The site starts to behave strangely. Some of the paid media visitors see text from the personalization campaign render over a banner image that is part of a separate A/B experiment, creating a disjointed experience. Other paid media visitors only see the A/B test experience render without any of the personalized copy. The experiments are overlapping and visitors are seeing different combinations of content appear as they land on the homepage. This confusion further frustrates the business, as the metrics for both the A/B tests and the personalization campaign are now incomprehensible.
What is the root cause? A lack of planning for the use of competing technologies. With two different tools targeting the same site elements for experimentation, conflicts with precedence and loading times inevitably arise. Before tackling web personalization, it’s crucial that your marketing team first take stock of their MarTech stack, identify overlapping capabilities, and decide which tools will deliver specific features. Web personalization software can easily conflict with A/B testing products, email marketing workflows, and other critical marketing functions. In planning for a new implementation, marketers should align on their testing goals and work to ensure that personalization efforts do not hinder the customer experience or frustrate internal stakeholders.
Take inventory of your domains
Whether the installation process involves a client-side or server-side implementation, web personalization tools typically require ownership of the websites on which they run. This means that only the developers and marketers who have some level of advanced permissions for a given website will have the ability to run personalization software there — either completing the implementation by native installation in the codebase or through tools like tag managers.
This may seem intuitive, but the restrictions become more apparent when considering complex use cases that span unauthenticated and authenticated applications. An organization’s IT department may have full control over an unauthenticated marketing site, but their logged-in experience could live in a third-party service, which is responsible for serving the authenticated customer portal. In this scenario, the third party may have limitations on custom integrations and software installations, potentially restricting the scope of personalization capabilities.
All personalization tools treat cross-domain tracking differently. Even if an organization’s application on a third-party service permits the installation of a personalization solution, the software’s ability to track visitors across domains could still be limited. Does the personalization tool rely on the use of third-party cookies? Does identity resolution require users to self-authenticate across domains with a consistent, unique identifier? Is identity management directly built into the personalization tool, or is it decoupled as a stand-alone service?
As you assess a tool’s cross-domain tracking capabilities, you should consider the web properties where your personalization campaigns will be most impactful and whether they even require accurate cross-domain tracking to succeed. Furthermore, you may take an iterative approach that begins by targeting anonymous site users based on visit behavior and gradually working up to personalizing to known customers across domains as you resolve dependencies.
Make your web pages accessible to personalization developers
The ecosystem for front-end web technologies is expansive, bordering on intimidating. There is no shortage of solutions for building single-page applications, writing scalable CSS, and bundling code for production environments. However your team tackles these problems, there is one simple thing that a front-end web developer can do to support personalization in your applications: write semantic classes and IDs manually in the client-side HTML code.
That’s not to say that developers shouldn’t use CSS-in-JS libraries and bundlers like Webpack, which often produce HTML full of machine-generated class names. Those tools serve a clear purpose, but the unreliable selectors they produce can harm personalization efforts. Personalization software may rely on consistent CSS selectors to target an element for a web use case. Selectors may also be necessary for attaching event listeners that track buttons and forms. If every fresh build of a website or app regenerates those selectors, personalization will break. Front-end developers should keep this in mind and use hard-coded, human-readable class names in their HTML code, especially when other libraries and tools are also generating their own classes.
Additionally, personalization tools that rely on client-side JavaScript to track user interactions on the web will largely be restricted to tracking only those elements that exist natively on the page. Standard use of client-side JavaScript code will prevent tracking in iframes — that is, YouTube videos and embedded forms. If any KPIs are attached to interactions with specific page elements, those elements should be built directly into the web page — not in an iframe — to ensure reliable tracking capabilities.
Conclusion
Yes, ML and AI will grow ever more important to personalization as the technologies continue to evolve. Still, you can’t spell “personalization” without “person,” and that remains especially true when it comes to implementation. While machines can handle the complex calculations and decisioning models, there’s no substitute for real people thinking and working behind the scenes to enable these tools to succeed with careful planning and deliberate technical choices.
Slalom is a global consulting firm that helps people and organizations dream bigger, move faster, and build better tomorrows for all. Learn more and reach out today.
