Over the past 2 decades, businesses have invested in digital channels. The worldwide COVID-19 pandemic has limited access in the physical world, resulting in radically accelerated investment in the digital one. This is especially true with respect to making commerce an integrated part of customer journeys and breaking down the silos between offline and online customer experiences.

To accomplish this, an essential enabling tool is a Digital Experience Platform (DXP). Gartner, Inc. describes a DXP as:

“A digital experience platform (DXP) is an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.”

What got you here today won’t get you there tomorrow

Traditionally businesses have taken one of two approaches to building a DXP: adopt a suite or build-your-own.

The suite approach

Adopting a suite has been the dominant choice for many enterprises. The category of DXP was created by the dominant web content management system (CMS) vendors, starting around 2010. DXP evolved from these CMS vendors’ efforts to expand their platforms to include personalization, analytics and marketing automation.

Vendors chose different strategies to add these capabilities, but most accomplished it through R&D efforts or acquisition. The result was that vendors were able to sell a solution to meet all of the customer’s digital experience needs, packaged in a single, integrated product.

Organizations that adopted suites have found that:

• System complexity is greater than expected — Complexity translates directly into increased costs. The more complex a system is, the more resources are needed to cover development, maintenance, operations and support.
• Niche skillset required to build and maintain the system — Finding qualified resources is hard, and those limited resources demand a premium. Dependency on a system integrator (SI) can create another form of vendor lock-in. System complexity translates into a steep learning curve for organizations interested in building their own teams.
• “Best-of-need” functionality is not always sufficient — This is an especially great risk for more mature organizations. When an organization must go outside of the suite’s limited capabilities to meet their needs, the organization ends up having to deal with the limitations of both the suite and build-your-own approaches.
• Technology changes faster than the suite can evolve — Modern web technology develops at break-neck speeds. It is very difficult for suite vendors, whose products are complex and based on technology from the early 2010s, to keep up. As a result, customers depending on the suite to provide capabilities are not able to take advantage of the latest innovations.
• Architectural limitations may prevent requirements from being met –The technology architecture of many suites is simply unable to meet modern performance and scalability requirements. These suites were designed at a time when websites were much simpler and customer expectations were very different.

The build-your-own approach

Some organizations determined that the bespoke (or build-your-own) approach was more appropriate for them. These organizations settled to buy a few core capabilities (e.g. CMS, analytics, CRM), and then leveraged their own engineering teams to build the remaining pieces. Typically, the custom development effort focused on integration, building custom personalization, and creating custom UIs that allowed business users to interact with the systems.

Many modern and successful SaaS companies use this approach, as in many cases their web site is top-funnel for their SaaS product.

Organizations that built bespoke DXPs have found that:

• Significant ongoing involvement from engineering is required — A level of cooperation and coordination is needed between technology and business teams that many organizations are not designed to handle. Ownership is hard to pin down or is distributed in a way that complicates decision making. This results in frustration in both teams, and slows their ability to execute.
• Growing feature backlogs constrain business growth — Increasing demand for digital marketing hasn’t been matched by increased engineering budgets. This means that feature requirements get added to an increasingly long backlog of work. For businesses trying to transform to a digital-first approach, this presents a considerable obstacle.

Challenges remain

In short, organizations must be able to deliver fast digital experiences quickly, and in a rapidly changing and unpredictable economic environment. Both suite and bespoke DXP implementations struggle to meet these demands. Something else is needed.

The composable DXP approach

As opposed to the suite and bespoke DXP solutions, the Composable DXP is modular by nature. Best-of-breed technologies are easily connected through smart, cloud-based APIs that provide the capabilities to create engaging, contextual and relevant digital experiences.

This modularity offers concrete benefits. Gartner, Inc. predicts that by 2023 organizations that have adopted an intelligent composable approach will implement new features 80% faster than their competitors who have adopted suite or bespoke approaches.

Faster time-to-market gives organizations the ability to do more in less time. Since it takes less time to deliver new features, more features can be delivered in the same timeframe, enabling organizations to experiment with new ideas with less risk. Time that was previously spent on upgrades, re-platforming and other expensive activities that provide little-to-no business value can be redirected.

Components in a Composable DXP

A composable DXP divides architecture and functionality into what Gartner, Inc. calls PBCs: packaged business capabilities. A PBC represents a capability — or related set of capabilities — that is:

• Purpose built
• Task oriented
• Independently deployable

A composable DXP consists of PBCs from a variety of categories:

• Front-end — libraries (e.g. Vue, React) and static site generators (e.g. Nuxt, Next.js)
• Content — content management systems (e.g. Contentful, Contentstack, Sanity)
• Commerce — commerce engines (e.g. BigCommerce, CommerceTools)
• Search — search engine connectivity (e.g. Algolia)
• Analytics — site visitor activity collection and reporting (e.g. Google Analytics)
• Personalization — content personalization (e.g. Uniform)
• Customer data — collection of data and reporting on customers (e.g. Salesforce, HubSpot)
• Content delivery — a system that delivers sites to visitors’ browsers (e.g. Akamai, AWS, Cloudflare, Netlify, Vercel)

Each of these categories could contain individual PBCs that could be derived and extracted, depending on the needs of the business.

New approach, old problems

While the promise of the composable DXP is attractive, it is important to realize that while integration has become much easier over the past several years, it is still required, even if it is not obvious early on.

For example, building a site with Contentful (content), React (front-end), Next.js (front-end) and Netlify (content delivery) can be accomplished with a few clicks. Each of these systems is self-contained. One feeds very nicely and cleanly into the next.

But what happens when you start to take advantage of this approach and start adding more capabilities? Adding personalization may create a connection between content, the front-end and the personalization system. Adding analytics may add its own connection to the content, the front-end and personalization systems. This requires integration.

Even though these systems are designed to work together, often times “work together” means that developers can easily connect these systems. The value of this reduced complexity is significant, but it is important to remember that there is a difference between connected and integrated. Connected means data can move between systems. Integrated means multiple systems work together as one. With this approach, connectivity is free, but integration is not.

New approach, old problems new solution

Additionally, something more than integration is needed: a system that can coordinate the communication between systems. Integration enables one system to work with another system as if they were a single system. Orchestration takes this concept and applies it across multiple systems.

You might already have a website, and now you want to incorporate commerce. Your stack consists of a number of systems: CMS, CDN, front-end, static site generator, personalization, analytics, etc. Adding commerce to the mix is more than just adding a view of the product catalog and a shopping cart. You need to be able to incorporate personalized content into the product catalog and check-out process. You need to capture analytics during the shopping process. Orchestration is needed across these systems.

Uniform is the orchestration layer for the composable DXP.

Real-world composable DXP

For this year’s MACHathon, we built a blazing fast personalized commerce site complete with analytics, and we built it in 5 days.

Uniform is a MACH Alliance member. We participated in the 2021 MACHathon. This was a 5-day hackathon challenge to build a solution on the theme of “getting unstuck”:

“Due to COVID-19’s grip on the world, most of us have experienced what it means to be stuck at home. While that experience is new to many, it has always been the routine for those with health challenges and disabilities — with or without COVID-19. For our MACHathon, show up with your ideas how to help people get virtually un-stuck.”

Our 5-person MACHathon team bended the brief a little and built a solution that demonstrates the benefits of a composable DXP enabled using Uniform, helping businesses to become digitally unstuck.

We used the following technologies:

Below is a 4-minute video demonstrating the digital experience, showing how these technologies come together to form a composable DXP.

Learn more about what we did in the MACHathon here.

As COVID-19 forced every business to rethink their business model, as customers and consumers were forced to work from home and practice social distancing, businesses became digital-first overnight.

Businesses with complex and expensive monolithic architectures are held back from quickly adapting to the rapid shifts in customer behaviour created by the pandemic. Such businesses have become digitally stuck — both now and in the future.

Our MACHathon project focuses on helping businesses break free and become digitally unstuck while creating digital business value faster, by taking advantage of a composable DXP architecture based on MACH principles.

In just six days, our Uniform MACHathon team provided a fully functional combination of Content, Commerce, Search and decoupled personalization with lightning-fast performance and perfect lighthouse score.

Besides helping businesses becoming digitally unstuck, using a Composable DXP approach, we also wanted to integrate Big Commerce with Uniform and through Uniform provide contextual digital experiences on front-end of choice with CDN of choice, as well as showcase the benefits of a composable DXP over a monolithic suite approach.

Day 1 Kickoff (Friday)

We started from the customer (aka the site visitor) perspective, what would be the ultimate digital experience?

The current state for many businesses is that the storefront (driven by Commerce) is separated for the brand site and in most use cases, content (driven by CMS) helps drive conversions, why it should be a blended approach with content+commerce.

Personalization is naturally the backbone for providing relevant digital experiences, rendering the right content and recommendations, based on the visitor’s in-the-moment intent.

Since it was a MACHathon, we wanted to utilize MACH technologies for headless CMS, headless commerce, headless search, naturally Uniform and a composed architecture. After some exploration of different storefronts, we settled on React and Next.js. We also decided to utilize our existing starter kit for Uniform (a fictive conference site call UniformConf), which didn’t have commerce integrated.

Our scope for the front-end was to expand to a storefront, but with a blended approach of content+commerce.

We made initial technology choices to fuel our composable architecture:

• Contentful (headless CMS)
• BigCommerce (headless commerce)
• Uniform (headless personalization and orchestration)
• Algolia (search + Uniform-powered personalization)
• Netlify (hosting)
• Uniform’s Next.js starter + elements from Next Commerce (frontend)
• Google Analytics (insights and tracking)

Day 2 (Saturday)

After we decided on the stack and we had the scope, we split the tasks like this:

• 2 team members to focus on front-end (adding shopping capabilities to Next.js on our fictive UniformConf site)
• 1 team member to focus on personalization, leveraging Uniform across the different technologies
• 1 team member to integrate products from BigCommerce, which we did not have any experience with prior to MACHathon.
• 1 team member to manage overall architecture, coordination, and general development

In addition to these tasks, the team also had to balance content creation, image production, and performance optimisation between them.

We did some stack setup: creating accounts, repositories, wiring up Netlify deployment, environment variables, etc. By the time we were done, we had a working continuous deployment setup.

We also started stubbing out static React components that we knew we’d need, and executing a PoC within Uniform to support a feature we wanted: personalization based on product attribute selection history (colors).

Day 3 (Monday)

On Monday we divided and conquered, tackling tasks from product content entry to API integration. We accomplished a lot:

• Product and CMS content entry
• Algolia integrated and serving personalized search results based on Uniform for products and sessions
• BigCommerce cart integrated
• Cart-based personalization using Uniform

Day 4 (Tuesday)

Tuesday continued what Monday started; as technical features stabilized we started to consider our endgame strategy.

• Components implemented and cleaned up
• Personalization using Uniform based on apparel color selection history implemented
• Integrated with BigCommerce checkout process
• Prepared and edited MACHathon demo script

Day 5 (Wednesday)

Wednesday was a day of cleanup and optimization. Our MACHathon script called for “perfect lighthouse scores,” so we didn’t have a choice but to get them.

• Bug fixes
• More Uniform personalization added (talk-based behavior personalization, more variants)
• Lighthouse went from decent to perfect
• Finalized the last remaining issues with components
• Prepared nicer architectural artifacts and docs

Day 6 (Thursday)

Thursday we made final tweaks and produced our hackathon deliverables:

• Video production
• Final bug fixes, no really
• Wrote documents like this one

The results

The final stack architecture:

Watch our project below:

It’s worth calling out the site performance:

We are proud of the work and had a lot of fun participating in the MACHathon, what we achieved in six days were:

• Create a new Next.js storefront
• Create a connected digital shopping experience, connecting commerce and content
• Use Uniform as the glue between the selected technologies and be able to change the components, as needed, e.g. change CMS, CDN etc.
• Demonstrate that a Composable DXP approach, based on MACH architecture is not only fast time-to-market, it also offers contextual capabilities that are known from expensive DXP suites.

Try for yourself: machdemouniform.netlify.app

Keep updated on our work at Uniform.dev.

• Build a fast website without personalization.
• Build a website with personalization, which made is slow, and personalization just added complexity to make it even slower.

The reason is that personalization is typically a part of the monolithic Digital Experience Platform suites, which makes it easier for marketers to control personalized experiences, but from a developer and architecture point of view, it relies on outdated technologies build on the need to query an origin that is typically slow to fetch the results and also imposes overhead to maintenance.

We believe the future of the (enterprise) Digital Experience Platform (DXP) is giving the enterprise the most flexible foundation to connect, maintain and evolve their DXP, where the DXP is made up of the different technologies that are crucial to help them manage personalized experiences at scale, across the different channels their customers are using.

The benefit for the enterprise is that they can focus on evolving their DXP, focused on value generation, rather than having big re-platform projects every 4–6 years.

With Uniform, we already help connect the different technologies that combined makes the enterprise DXP, examples:

• How Uniform connects Enterprise technologies to modern tools, that are API-first and build on microservices, examples are how Nationwide Building Society uses Uniform as the glue to empower “Google-fast” experiences and how Klepierre has 98 sites focused on being fast and personalized.
• How Uniform brings blazing-fast headless personalization that empowers headless CMSs, like Contentful, decoupled architecture and edge of choice.

Today, we at Uniform, are proud to join the MACH Alliance, founded by Commercetools, Contentstack, EPAM Systems, and Valtech, who advocates for an open and best-of-breed enterprise technology ecosystem; Microservices based, API-first, Cloud-native SaaS and Headless.

“Today, there are hundreds of proven SaaS vendors that solve specific business problems (content, commerce, personalization, etc.) much better than the basic functionality offered in suites. Due to the near-ubiquity of support for MACH principles and how modern SaaS software works, it’s easier than ever to discover, evaluate, purchase, and integrate these vendors. As needs evolve, vendors can be easily added or swapped. We, as members of the MACH Alliance, represent the present and future of enterprise software and services and aim to be the catalyst for even more change.”
Kelly Goetsch, President of the MACH Alliance board

Our vision of a better world with easier choice and less bloat for the enterprises is aligned and Uniform already have connectors and strong collaboration with other MACH members.

In a world where transforming to change faster than the competition, having fast performant sites and empathy for the customer are key for success, applying the MACH Architecture as the foundation will not only help the enterprise develop faster, have fast sites that are personalized, it will also give the foundation to evolve the platform and respond to future needs faster than a monolithic approach.

How Uniform adds value to the MACH architecture

Uniform adds value to the MACH architecture in 2 ways:

1. When the platform is not established, Uniform provides the platform that helps connect multiple (MACH) technologies and compliment with decoupled services in connection with those technologies. An example is using Uniform to connect CMS, Data, Front-end of choice and CDNs. The result is a blazing fast personalized site, build on MACH architecture, which can be deployed for a fraction of the time, compared to a monolithic approach.
2. When the platform is established, Uniform can add headless decoupled personalization that works with front-end of choice and edge of choice. The result is blazing fast personalization that can render in 50ms.

We are looking forward to joining the alliance and help present and advocate for how the enterprise can evolve their DXP based on the MACH Architecture.

Traditionally DXP and Jamstack come from two different worlds: DXP from the marketing world and Jamstack from the IT world. While building engaging sites requires cooperation between the marketing and IT worlds, the technology focuses on one or the other. We believe there’s another way, that DXP can be reimagined with Jamstack so that organizations can get the best of both worlds.

What is a Digital Experience Platform?

Digital Experience Platforms aim to connect the various tools involved in designing, building, deploying and maintaining the experiences customers have in an organization’s digital channels. This includes things ranging from content management to digital asset management to content marketing to personalization and beyond. Both technical and business users work in a DXP.

The Digital Experience Platform is a $12 billion annual market. DXP is often described as a key enabler for companies interested in digital transformation. It allows brands to deliver personalized experiences to their customers. Personalization increases visitor engagement. Visitor engagement increases conversions. Conversions increase revenue.

Is it a platform or a product?

The word platform in Digital Experience Platform is significant. A platform is something that connects different systems or services for the sake of having those systems or services work together as a single unit. In reality, however, most DXP systems act more like Digital Experience Products rather than Digital Experience Platforms.

With a product from a single technology vendor, you expect the product itself to provide the functionality you need. For example, an essential feature of DXP is web content management (WCM). With a DXP that acts as a product, the DXP itself provides WCM functionality. The WCM functionality is considered to be tightly coupled with the DXP, meaning the WCM functionality cannot be separated from the DXP. It’s a black box.

On the other hand, with a DXP that acts as a platform, the DXP might provide its own WCM functionality, but the DXP would also allow you to replace that native WCM functionality with your own. Whether you use the native WCM functionality or bring your own, the DXP that acts as a platform works the same way.

What is the value of a platform?

While the current generation of product-like DXP systems meets the needs of many of the organizations that have invested in them, the need for platform-like DXP systems is growing rapidly. The following are some of the scenarios that are driving this need:

• Sub-second page load times for personalized pages
• Support for modern front-end development technologies
• Global scalability with no downtime and outstanding security
• DevOps efficiencies, such as instant rollbacks and deployment previews

If you are familiar with Jamstack, you may immediately identify these scenarios as being among Jamstack’s strengths. Jamstack is a specific kind of architecture that handles these scenarios well.

The current generation of product-like DXP systems does not use a Jamstack architecture. Ironically, these products evolved as alternatives to the publish-oriented design of the previous generation of products. This publish-oriented design is very similar to Jamstack architecture. The difference is that Jamstack overcomes the limitations of the publish-oriented design thanks to improvements in browser engines, JavaScript and CDN technology, and the advent of the API economy.

It is very difficult — and in some cases impossible — for the current generation of product-like DXP systems to handle these scenarios. Often they depend on heavy origin-based request processing and slow server-side rendering that is often mixed with proprietary CMS templating technologies. This creates a bottleneck for performance and scaling. Sites that are highly distributed, or that involve large amounts of dynamically generated content are especially susceptible to these limitations.

DXP inspired by Jamstack

One reason why Jamstack is exploding in popularity is that it offers flexibility, choice, performance and operational simplicity. Developers can use whatever content management system, static site generator, APIs, etc. they want. Jamstack lets developers use the right tool for the job. A DXP inspired by Jamstack would bring the same kind of flexibility and choice to digital experience management.

We are proud to announce Jamstack DXP by Uniform, the world’s first headless decoupled DXP inspired by and built for Jamstack. You get the benefits of Jamstack:

• Use your preferred static site generator, including Next.js, Gatsby and NuxtJS.
• Deploy to your preferred CDN, including Netlify, Akamai, Azure, AWS and Tencent.
• Use modern DevOps tools and practices.

…without losing the benefits of your current DXP:

• Decouple DXP functionality such as personalization and tracking so they are configured by business users in their current DXP but are executed in an origin-less manner (e.g. using Uniform’s edge-based personalization functionality).
• Keep business user functions such as contextual content authoring and preview, workflow, publishing, translation, and campaign management in place.

Jamstack inspired by DXP

Traditional DXPs are not going anywhere. These are systems that were designed for the largest brands and organizations in the world. They are used on a daily basis by marketers and other business users, not developers. These systems power and are powered by line-of-business applications that are not going to be replaced just because a new website architecture is available.

Jamstack DXP by Uniform enables customers to continue using their existing DXP and business applications. It enables the parts of those systems that are working well for a customer — such as the business user tools — to work with Jamstack tools, while enabling customers to decouple the parts that aren’t in order to leverage better solutions.

In addition, for customers without an existing DXP, Jamstack DXP by Uniform brings enterprise-grade personalization to headless CMS products. This is another example of bringing the best of DXP to Jamstack.

Making re-platforming a thing of the past

Jamstack DXP by Uniform enables customers to build their own DXP by using features from the systems and tools they prefer. Customers can add new products to their DXP and replace existing products. They never have to throw everything out and start from scratch.

It’s hard to think of a digital experience management project that is more expensive or riskier to an organization than re-platforming. It can be fairly easy to identify what isn’t working in a solution. It is much harder to know whether re-platforming will actually resolve those issues and what new issues will arise.

Re-platforming represents a revolution. You dismantle the old and replace it with something new. With Jamstack DXP by Uniform, re-platforming becomes a choice rather than a requirement. By enabling systems and tools to be added and removed from the DXP whenever the customer wants, the DXP becomes able to change over time. Re-platforming and migrations can be done incrementally. This is why we at Uniform say “evolution, not revolution”.

Interested in Jamstack DXP by Uniform?

Announced at the Jamstack Conference October 6th 2020, Jamstack DXP by Uniform is available for select technologies immediately and will be expanded with more connectors.

For more information about how Jamstack DXP can serve as the backbone of your marketing technology stack and enable you to meet the demands of the modern web, contact hi@uniform.dev.

Limitations of traditional DXP architectures

The impact on site performance is mainly due to the architecture used by most “enterprise-grade” Digital Experience Platforms (DXP). These systems often require the DXP to act as the site “origin”. In web architecture, the origin is the name given to the system responsible for delivering content to the visitor.

In order for the DXP to deliver a personalized experience to a visitor, the DXP must execute logic in order to determine the appropriate content for the visitor and to package that content into HTML that the visitor’s browser can display. Individual page components are personalized in this way, so pages with multiple page components have more logic that needs to run.

In order for this to work at scale, the DXP must be able to handle a large number of visits. This often requires scaling up (increasing the power of a specific instance) or scaling out (increasing the number of instances). If visitors are distributed around the world, instances of the DXP must run in data centers around the world, as the visitor’s physical distance from the DXP has a large impact on performance.

Even when the DXP is scaled in this way, there is still a requirement that each DXP instance is able to handle requests quickly. If an instance can’t do this, visitors will either have to wait a long time for the site to load or, in the worst case, be unable to access the site at all. This helps explain why many large brands have tried turning on personalization, only to turn it off when they realized personalization resulted in poor performance and site outages.

Improving performance with a CDN

The fastest sites do not depend on their DXP to act as the origin. They use a CDN (content delivery network) as the origin. A CDN is a globally distributed, high-performance delivery network that is able to scale automatically to handle changes in traffic load. The CDN sits in front of the DXP, only making calls back to the DXP when absolutely necessary.

In the past, this presented a challenge for sites with personalization and other kinds of dynamic content. If this dynamic content is generated by the DXP, it was necessary for every request to be handled by the DXP. The benefit of the CDN was limited to handling static files like images.

Today, brands have several options for decoupling personalization functionality. Marketing technologist and business users can continue to use their DXP to enable and control personalization, but the execution of that personalization can be separated, or decoupled, from its configuration. Personalization can be executed on the CDN, also called “the edge”.

(In case you’re curious about why the CDN is called “the edge”, it’s because of the way the CDN is a globally distributed network. The CDN is just as fast for someone in San Francisco as it is for someone in Berlin. That’s because the person in San Francisco is served by the part of the CDN located geographically close to San Francisco. That is the “edge” of the CDN. Similarly, the person in Berlin is served by the edge of the CDN closest to Berlin.)

Personalization on the edge

From a marketing technologist or business user’s perspective, nothing changes. The way personalization is enabled remains the same. But moving the execution of personalization from the DXP to a CDN means the way that personalization works changes. Understanding these changes is important in order to design a site that can be as fast as possible. Getting the fastest possible performance means realizing the difference between things you can do and things you should do.

Just like with DXP-based personalization, CDN-based personalization depends on data being available when the personalization logic runs. When thinking about CDN-based personalization, it is helpful to organize the data that drives this logic into three categories:

These categories are not only differentiated by the kinds of data they represent. They are also differentiated by something called “potential reach”. Potential reach is a relative measure of how many visitors can be targetted, or reached when personalization is based on that kind of data. Large (or high) reach means a large number of visitors can be reached. Small (or low) reach means a small number of visitors can be reached.

Reach also reflects the quality of the data insights that are gathered as a result of the personalization. Personalizing using data with high reach will, by definition, apply to a larger population. It’s not as precise as personalizing using data with low reach which, while it applies to fewer visitors, provides a more relevant experience for those visitors.

There are advantages and disadvantages to personalizing with low, medium and high reach data. In most cases, you will get the best results when you personalize using data from all three categories.

Category 1: Data available at the edge when the visitor arrives

When a visitor views a page, certain data is passed along with the request. This is the data included in the HTTP request. It includes the following:

• Device information — Browser type, browser version, operating system, etc.
• URL — Hostname, query string parameters, etc. Inbound marketing campaign ids are typically included in the URL.
• Cookies — Information collected as the visitor has viewed the site, either during the current session or a previous one.
• Language
• Visitor IP address
• Date/time

In addition, the CDN may provide data based on the HTTP request. Some common examples include:

• Location — This can be determined from the visitor’s IP address.
• Device capabilities — This can be determined using a variety of device details, including the visitor’s browser type and operating system.
• Third-party data — Insights from DMP, ABM, etc. can be matched using the visitor’s IP address or a third-party cookie.

This kind of data is the easiest to personalize with because it is available automatically and without any additional configuration or custom development.

Category 2: Data based on real-time behavior

As a visitor navigates a site, the visitor’s session behavior can be collected. Examples of this kind of data include:

• Specific pages viewed
• Number of pages viewed
• Goals/events triggered — For example, adding a product to a shopping cart or signing up for a newsletter.
• Scoring based on behavioral profiles — For example, interest in a particular product category or lead scoring.

The component that collects this behavior is called a tracker. When a DXP is the origin, it can run a tracker itself. This means all of the visitor activity is collected on the DXP, which is convenient because it requires little-to-no addition configuration.

That convenience comes at the price of performance and scalability. Activity for each visitor must be stored in the DXP, usually in memory, at least temporarily. Sites with a lot of visitors end up having to store a lot of data, which reduces the performance of each instance and increases the need to either scale up or out.

But trackers can run on the client, too. Google Analytics tracker is an example of this. If a client-side tracker is used, that significantly reduces the amount of work the DXP needs to do when it handles visitor requests. A tracker can store visitor behavior on the browser, which means the visitor remains in control of all of his or her data.

If visitor behavior data is captured in a client-side tracker, that information can be made available to the CDN using options available in category 1. For example, the tracker may store the number of pages viewed in a cookie. Doing this means the visitor behavior is available to the CDN.

Category 3: Data based on visitor information

The final category of data describes an individual visitor. This data usually comes from a customer database or the DXP. Common examples include:

• Gender
• Age
• Contact relation (e.g. customer, partner, etc.)
• Orders
• Products/services purchased
• Opportunities

While this data might be stored on the client (and, therefore, an example of category 2 data), more often the data must be retrieved from the system of record. This requires an API call to the system of record.

The amount of time it takes for this API call to complete depends on the health, location and scale of the system of record. If visitors cannot view your site until this data is available, that can create performance problems for your site. As a result, this type of personalization should be implemented in a way that does not prevent the visitor from interacting with your site. Techniques such as “lazy loading”, positioning this type of personalization below the fold, or including it on second page-views offer solutions.

How to minimize the need for category 3 personalization

Getting the best possible personalization performance and minimizing the cost of DXP infrastructure usually involves reducing the use of personalization that requires additional API calls. You also get the benefit of easier compliance with privacy legislation like GDPR and CPA.

To be fair, personalizing on the data that uniquely identifies a visitor is compelling. This article is not trying to portray this type of personalization as something that is incompatible with good site performance. But it is worth considering how important this type of personalization is, especially since studies show that site performance has a much greater impact on customer engagement than personalization.

In cases where personalizing on this kind of data is required, you want to minimize the number of API calls needed to collect the data used for personalization. Consider personalization based on the visitor’s contact relation (whether the visitor is a customer or a partner).

In this example, the data is stored in the DXP. Upon visitor login, this value can be stored in a cookie. This way the data can be handled like category 1 data. Or, if you are sending an email campaign to all partners, you can use a parameter in the URL to classify the visitor is a partner. URL parameters are category 1 data. And you can store the value in a cookie for future personalization needs.

Real performance benefits of CDN-based personalization

The image below highlights the difference in performance between DXP-based personalization and CDN-based personalization. In this example, the personalization is based on the visitor’s country. The CDN used was Akamai.

TTFB (time to first byte) is the amount of time it takes before the visitor’s browser start receiving any data from the origin. Sub-second TTFB is what engineers aim for. In this simple personalization example, TTFB for DXP-based personalization is 1.6s, while TTFB for CDN-based personalization is 45ms. CDN-based personalization is more than 35x faster.

Using the same example, the page load time for DXP-based personalization is 3.2s compared with 0.69s for CDN-based personalization.

Fast, scalable personalization with the systems you have with Uniform

Edge-based personalization is possible with your existing DXP. This approach gives you the best of all possible worlds:

• All personalization is enabled through the DXP — The processes used by marketing technologists and business users do not change at all. They continue to use the tools offered by the DXP to configure and control personalization.
• Visitor activity data is stored where it’s needed — Data collected can still be stored in the DXP if desired, but the data can also be stored in other systems, such as Google Analytics. This also creates the opportunity to report on personalization using tools like Google Data Studio and Microsoft Power BI.
• Infrastructure costs are optimized — Optimize your infrastructure cost by moving more logic (also known as “compute”) to a CDN, which is more cost-efficient than scaling the DXP infrastructure.
• Custom integrations are eliminated — Third-party data sources don’t have to be integrated with the DXP. All data that is needed is either already available or is provided to the edge from the client.

Uniform enables edge-based personalization with the platforms and products you choose. For example, with Sitecore Experience Platform, you can deploy edge-based personalization on a variety of CDNs, including Akamai, AWS, Azure CDN, Cloudflare and Netlify.

Once upon a time…

Beginning around 2010, content management system (CMS) vendors began to tell a story of a fascinating future that was now within reach for brands. In this future, brands could create unique, personalized experiences for each and every one of their customers. This was going to increase the level of engagement between the brand and its customers, which would increase customer loyalty and lead to more profits.

This would be possible because vendors offered suites that provided everything the customer needed to make this happen. CMS, personalization, testing, analytics, marketing automation, etc. were all parts of the suite. This was a new category of products that would become known as the digital experience platform (DXP).

And they both lived happily ever after…

The suite approach was a good fit for many brands. Many brands in the mid-market were not already heavily invested in separate best-of-breed technologies. Additionally, most of the purchasing decisions were driven by marketing budgets, so focusing on a single-platform strategy could reduce technical complexity and dependence on IT resources.

But life was not as perfect as it seemed…

Many brands learned that using technology to optimize experiences requires much more than a DXP. It requires people, process and organizational commitment. This is such a significant impediment that most brands end up using only a few of the capabilities they bought in the first place.

In addition, marketers often found the tools available in the suite to be unsuited for their needs. The compromise of the suite is that you get a wide variety of features, but those features aren’t best-in-breed. They are good enough.

But often they weren’t. They were too complicated or too simplistic. Marketers were unable to get their work done with them, so marketers looked elsewhere and found tools that worked for them. Ironically, this created the exact kind of complexity the suite was supposed to eliminate.

Then new challenges arose that were not anticipated…

In 2020, brands are faced with challenges that suites were never designed to face.

• Performance — Site delivery for most DXPs requires an expensive (i.e. slow) call to an application server. Not only is this call slow, but as the number of visitors accessing the site increases, the load on the server increases, compounding the slowness.
• Scalability — Most DXPs allow you to add servers to handle increases in load, but this kind of scaling is often complex, difficult and/or costly. In addition, automatic scaling may not happen quickly enough to handle a traffic spike as it happens.
• Integration — Most brands are using additional tools, if not to completely replace the tools offered by the suite, to supplement them. This often creates the kinds of data silos DXPs were supposed to eliminate.
• Privacy — Legislation like GDPR and CPA are changing the way experiences are optimized. Many DXPs were designed to collect all possible information. Essential concepts of trust and value-exchange simply don’t exist in those systems.
• Technology changes — The technology used to build a suite may have been popular 10 years ago. Back then, finding people with experience with that technology would not be hard. Today, that technology may be much less popular. Finding people with experience may be much more difficult.

New opportunities arose that suites cannot exploit…

In 2020, brands are faced with opportunities that were unavailable when the DXP suites were designed.

• JavaScript won the web — Proprietary scripting languages built on .NET and Java have given way to front-end frameworks built on JavaScript. Server-side logic can also be written using JavaScript.
• Static sites do not have to compromise on visitor experience — The browser is a powerful application engine. Dynamic content and personalization can be handled on the browser, instead of on the origin. The need for an expensive, slow, insecure application server that generates dynamic content for each visitor is largely eliminated.
• CDNs enable global, fast, cheap deployment — CDNs are incorporated into DevOps processes, freeing brands from having to configure their own change management processes. CDNs also free brands from having to manage most aspects of scaling, which are among the most complex and difficult parts of web application management.

This is the JAMstack…

These opportunities are often described using the name JAMstack. Sites built using a JAMstack approach take advantage of the benefits of the modern web.

• JavaScript — website logic is written using JavaScript.
• APIs — website incorporates functionality from services using APIs.
• Markup — website markup is generated at build time (as opposed to markup being generated on the origin at runtime).

Developers have recognized JAMstack as a solution to problems related to performance, scalability and DevOps. JAMstack doesn’t require any specific product or vendor. This means developers can use the right tool for the job. These are just some of the factors that drive JAMstack’s popularity.

Brands in small and mid-markets have been adopting JAMstack with success. It offers them clear benefits in terms of fast time-to-market and low operational costs. This is largely the world of Wordpress sites.

Enterprise brands have been unable to embrace JAMstack fully…

Brands using DXP products from vendors like Adobe, Salesforce, IBM, Sitecore, Oracle, Open Text, Acquia and Episerver are still in the “kicking the tires” stage of adopting JAMstack. They see that JAMstack can solve some real problems they have today, but they also see some major obstacles to its widespread adoption.

• Essential tools aren’t supported — The average enterprise organization currently uses 90 different marketing technologies. Few of these tools are natively compatible with JAMstack. These are tools that marketers depend on to do their jobs.
• Re-platforming isn’t an option — Even with everyone onboard, re-platforming is an expensive, multi-year effort. Getting everyone on board is often a delicate, highly political endeavor.

Enterprise brands need something different…

The pendulum has been swinging back and forth between IT-focused solutions and marketing-focused solutions for a long time. IT-focused solutions do a good job of providing tools to address IT responsibilities, including things like content delivery, DevOps, and developer experience. This put more control in the hands of IT and developers, rather than marketers.

Marketing-focused solutions do the opposite. These solutions enable marketers to take more control over tasks like personalization, content marketing and analytics, but they are much harder to fit into the parameters established by IT to keep control over technology.

JAMstack landscape from Christian Reid provides a great description of the IT-focused JAMstack perspective. Omnichannel stack from Tony Byrne provides the same for the marketing-focused perspective.

Both perspectives are correct, and there is overlap. But each is focused on different audiences and different objectives.

The conflict between these perspectives is leading to the emerging role of a MarTech leader, such as VP of Marketing Technology or VP of Marketing Operations. This role combines elements of IT and Marketing. This role is poised to take ownership of CMS and DXP initiatives.

A MarTech leader looks at the challenges from the perspectives of both IT and marketing. This person understands that the problems won’t be solved by making more marketing functionality available to developers, or by making marketing tools less dependent on developers. That approach was tried repeatedly over the past decade. It failed to deliver on its promises.

The problems must be solved by taking the best from IT’s world and combining it with the best from the marketer’s world. This is a solution that caters to the needs of both IT and marketing, without forcing either to compromise.

This is what we call the Digital Experience Stack powered by the JAMstack.

Uniform lets you build your own Digital Experience Stack on JAMstack…

A digital experience stack is almost defined by the idea that the different components that make up the stack are able to coordinate with each other. JAMstack components are already able to do this. The challenge is that the digital experience components are not.

This orchestration is the problem that we solve with Uniform. Without Uniform, a brand must integrate each component in the stack separately. With Uniform, each component connects to Uniform, and, through Uniform components, are able to communicate with each other.

For example, imagine a brand with 6 systems to connect. Without Uniform, 15 connections would be needed to ensure all systems can communicate. Each system must be connected with each other system. Add a new system, and you have to create 6 new connections.

With Uniform, only 6 connections are needed. Add a new system, you have to add 1 new connection. Keeping the number of connections low is especially important when you are dealing with systems that were not designed to be integrated in the first place, as is the case with many of the systems that make up a large brand’s digital experience stack.

Uniform isn’t a connector. It is the connectivity between the systems. Yes, Uniform offers connectors. Connectors enable systems to hook into that connectivity. But Uniform is more than just a set of connectors.

For example, Uniform makes it possible for the personalization, analytics, build and CDN systems to know that content has changed in the CMS without each of those systems having to be notified individually. With Uniform, the build system can communicate back to the CMS to notify the content author that the change that was made resulted in a reduced Lighthouse performance score.

This kind of orchestration is possible because Uniform is the “connective tissue” between all of the components of the stack. Uniform is able to provide cross-system features and insights that are rare even within tightly coupled digital experience suites.

Decoupling is the key…

DXP products, by definition, do a lot of different things. But they don’t do all of those things equally well. Uniform makes the distinction and decouples the things a DXP product does well from the things it doesn’t do well, and provides a brand with options for other products to fill the gaps.

For example, a DXP may be good at allowing business users to configure personalization, but not very good at delivering personalized experiences at scale. In this case, Uniform decouples the configuration of personalization from the delivery of the personalization. The DXP continues to handle the configuration of personalization, but the brand can select from different options to deliver personalization much faster and at scale, such as edge-based personalization from a CDN, such as Akamai, Netlify etc.

The advantages of decoupling are huge:

• No interruption to business users — They can continue to use the tools they are already using.
• Leverage existing technology investments — Systems that are already in place can stay in place as long as needed.
• Improved performance and reduced cost — Brands can replace inefficient components with efficient ones.

A future without re-platforming…

Today, re-platforming is revolutionary. A re-platforming effort requires wholesale replacement of one system with another. It is a process that is undertaken after the brand has tried repeatedly and unsuccessfully to make a platform work. The brand decides to replace the old with something new.

In reality, the decision to re-platform is a complicated and difficult one. It is unusual for a customer to have completely outgrown a particular platform. More often, there are certain parts of a platform that don’t meet the customer’s requirements, but those parts are important enough that the customer is willing to lose the parts that do work well.

With Uniform, re-platforming changes from a revolutionary act to an evolutionary one. Uniform allows a brand to make changes to its stack as soon as an issue is identified. The brand doesn’t need to wait until the issue is a critical problem to act. And Uniform enables a brand to introduce stack changes without the major interruptions that come with re-platforming.

Incremental re-platforming is possible because this is precisely what Uniform is designed to do: let customers add/remove/change their stack on their own terms.

Uniform makes the (business) world a better place

At Uniform, we have a bold vision of uniting the tools IT and marketing depend on. The question changes from whether a brand wants a solution that caters to IT or one that caters to marketing, to determine the best tool to get the job done.

Arguably, even more important than giving organizations the ability to choose their own tools is giving them the ability to more effectively communicate across technical and business concerns. Anyone who has spent time working on digital experience projects with large brands has seen how disconnected these teams can be.

By uniting their tools, Uniform enables IT and marketing to use the same information to make decisions. They see how their work affects each other. They learn a shared vocabulary for describing challenges and finding solutions. It’s not just the tools that work together more efficiently. It’s the people, as well.

Feel free to reach out, our email is hi@unfrm.io.