A Digital Experience Platform (DXP) is a set of services that when combined together provide the most essential services to building a digital experience and distributes this information to a wide range of stakeholders within a common platform. DXPs are founded on the idea that all of the services needed to build a digital product should be closely linked together, but recognize that there are a wide range of digital products that are relevant to consumers. DXPs enable teams to build not only websites, but also mobile applications, eCommerce shops, and Internet of Things (IOT) applications. In bringing all of these services together under one roof, the workflows benefit from a more continuous stream of content and more efficient workflows.
As customer expectations rose around receiving high quality, engaging digital experiences, companies adapted by gathering more data on customer needs and wants, and integrating them into their existing systems and workflows. The term DXP was originally coined by Gartner and Forrester to define a movement occurring within technology platforms where the architectures were becoming more complex and tools like Content Management Systems (CMS) began integrating a broader range of tools to satisfy the needs of their projects.
In the initial iterations of DXPs, an entire project could live in a single platform and have access to all of the functionalities provided by a single provider. Over time, there has been a rise in the best-of-breed approach to architecture building with teams having strong opinions on which software to use for which use case. This has led to a rise in DXPs which allow more integrations with external services to provide a flexible, composable DXP.
#The Evolution of DXPs
In order to better understand where DXPs began and what their roots tell us about how they will continue to grow. Essentially, the goal of a DXPis to continue to bring unified, engaging customer centric experiences to the end user built on data and understanding. The evolution of these technologies demonstrate their core competencies but also the ways in which customer expectations have changed.
Content Management Systems (CMS)
Content Management Systems (CMS) organize, store, and deliver the content that is critical to a digital product. This content can be anything from marketing copy, to metadata, to product information depending on the use case. Instead of content being hard-coded for a website, CMS offer editors the opportunity to create, edit, and format content that can be pushed to the final project. Creating this simple workflow was the foundation of the desire to create more content that required less work from the development team to push live.
There are two main types of CMS, traditional CMS and headless CMS. Traditional CMS, also known as a monolith CMS, dictate the presentation layer of the end user and often provide templates in order to provide a custom look and feel. Platforms like Wordpress and Magnolia are some examples of popular monolith CMS. While they offer more control of the content to the marketers, they still require significant work from the developers and often require development resources to push their content live. In use cases where only websites and mobile websites are considered, they can help get a project up and running quickly; however, teams must use the out-of-the-box functionality or spend time building custom work arounds.
Headless CMS remove the suggested presentation layer, aka “The Head” and leave project members with a powerful CMS with an API that can be connected to the frontend of their choice. Instead of relying on the system-provided templates and having to build work-arounds, project leaders are able to choose which of the many frontend technologies are relevant to their use case. Headless CMS help future-proof a team’s stack as it is possible to connect new frontends where relevant while using a similar set of data.
Web Experience Management (WEM)
Web Experience Management grew out of the traditional CMS approach of creating a central hub of content. Web Experience Management, however, keeps the customer at the center of its mission. WEM considers all of the online touchpoints of a customer and helps ensure that content distributed across various channels remains aligned and consistent. By having a single content repository, teams are able to ensure that the branding and messaging are aligned across channels. These platforms consider all of the customer data gathered to help build personalized, custom-feeling experiences.
Digital Experience Platform (DXP)
Digital Experience Platforms are defined by Gartner as, “an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.” DXPs grew out of the desire to build more data-rich user experiences and grew out of CMS and WEM systems. Typically, DXPs were housed in a single, monolith platform, tying a company to a particular vendor. These were a vast improvement to previous systems because they removed the issue of data silos and optimized workflows to empower more creativity and agility.
Composable DXPs take the same basic principles of a DXP and apply a modern, best-of-breed approach to architecture building. With monolith DXPs, all of the functionality typically comes from a single vendor or an integration that is built by that vendor or a custom integration from the team itself. This can lead to cost intensive workarounds or roadblocks. In composable DXPs, teams choose the tooling that they would like based on their use case and connect them together via API. Data flows seamlessly between the systems and there is a custom feel of a DXP without having to reinvent the wheel. Composable DXPs typically have a headless CMS at their core with additional best-of-breed tooling to round out the architecture.
With a composable DXP, the stack that best meets their needs without adding additional dead weight that is not relevant to their case. As their needs change over time, it is easy to continue to refine the DXP stack. This strikes a balance of getting the benefits of a DXP in terms of having content readily available and not building a reliance on a single vendor for all functionality.
#Benefits of DXPs
To better understand why people implement DXPs, we will take a look at the benefits to both the companies behind a project as well as the end user. In this section, we will not make a distinction between a composable DXP and a traditional DXP as they provide many of the same benefits. At the end of this section, we will take a closer look at the specific benefits of composable DXPs.
Holistic Visibility of Customer Data
With a DXP, data flows seamlessly through a single system. Information gathered in regards to a customer is housed in a single place, rather than spread across multiple systems. This enables teams to power their customer interactions with data and enables them to create memorable digital experiences or other customer interactions.
Ridding an architecture of data silos is a critical element of ensuring that data remains accurate and up-to-date. It becomes easier to automate changes to data and ensure that it is reflected across the project. In the past, this process was reliant on manual work in multiple systems. This could lead to data not being updated as often, human errors in regards to the data, and makes data less readily available across the project. DXPs ensure that customer interactions are driven with data that can help level up the experience and that no customer is left by the wayside.
Increased Operational Efficiency
Teams are able to live largely within a single system when they have implemented a DXP, whether it be a composable or traditional DXP. In creating a seamless flow of content between various elements of the architecture, from CMS to Data Analytics, it is easy to create new interactions without the need for time consuming data migrations. Individual stakeholders have access to the most current information and are sure that the data is consistent across all of the systems without the need for manual work.
In reducing the amount of manual work needed to ensure data is accurate and available at all points of creating a digital experience, workflows are able to be more efficient and reduce the amount of tedious data entry. This helps ensure that time is used most effectively and enables more room for creativity and experimentation in creating new digital experiences.
Rich and Personalized Digital Experience
Because of the better availability of data and systems such as A/B testing, and Data Analytics being in one place, teams are able to deliver a personalized digital experience with ease. Consumers of today expect a high degree of personalization and want digital interactions to be performed with ease. DXPs make this possible by creating a single content repository where data can easily be harnessed for a wide range of purposes.
Instead needing to migrate data from one system to another to add an additional functionality, with a DXP the data is available from the get-go and it is consistent throughout the system. It is easy to take advantage of a more efficient workflow which enables them to be more experimental with their approach to providing new and engaging digital experiences. If they prove successful, it is easy to expand this approach. If not, it can be helpful to use the data gathered from what was not successful to provide a clear starting point for the next experiment without migrating data from one system to another.
Accelerated Digital Transformation Initiatives
In creating a single place where all content lives, it is easy to distribute this data between multiple presentation layers depending on the use case. As teams want to experiment with new channels, they can rely on the existing structured content in the backend and provide supplemental information that is relevant to the particular use case. This expedited workflow enables more agility. Instead of taking time to migrate data between systems and evaluating whether the extensive time investment is worth accessing the new channel, project leaders are able to create a simple POC with existing data and existing functionality within the DXP.
Digital transformation has changed the customer expectation around many interactions, from eCommerce to customer support. This will only continue to grow, so having a central repository of this data gathered from all customer interactions, helps ensure that information is not lost due to data silos. DXPs help teams create a future oriented approach when it comes to digital transformation while creating workflows that are efficient for existing use cases as well.
At the heart of providing more data-centric approaches is providing more interactions that bring the most value to customers. In keeping customers at the core, teams are able to build more meaningful interactions and use the data gathered to continue to improve in further experiments.
While it is common to claim that putting customers first is a goal of a business, by implementing a DXP, companies put this into action. Building more engaging interactions, becoming more experimental, and retaining data around all of these approaches helps ensure that companies are delivering the most engaging customer experiences possible.
#Where does CMS fit into the DXP Approach?
Having CMS functionality within a DXP is a critical component of a DXP. Depending on the DXP, the system may have even began as a CMS and grown into an all-encompassing DXP. CMS ensure that data is well organized and offer essential functionality to the teams that are building digital experiences. Being able to model structured content in a flexible way that can be used in a broad set of contexts to enrich content with information from other elements of the architecture, such as a CRM or Data Analytics tools.
The CMS component of a DXP should have enough flexibility to explore new channels easily. Data should be stored as structured content to easily stream data between different elements of the DXP and that this data is reusable without any additional manual work.
Choosing DXPs that integrate well with additional systems can be critical to ensuring that the architecture scales and ages well. A composable DXP can be a great choice in this context because it has the ability to integrate with external systems via API and gives more room to build a custom stack, while still benefiting from the DXP approach.
What is the Difference Between a CMS and a DXP?
The best answer here is, it depends. In many circumstances, the CMS is a critical element of a broader DXP system. Organizing and managing structured content within a monolith DXP ensures that the data can be easily distributed between the various elements of the DXP. The biggest difference is that while all DXPs will have a CMS element, not every CMS will have all of the other functionality inherent to a DXP. Some CMS will be extensible enough to integrate external systems in the form of a composable DXP.
In a composable DXP, various services are connected via API to create a customizable DXP. Teams are able to choose the best-of-breed technologies that are most relevant to their use case and integrate them together to build a DXP. The CMS in this circumstance becomes the central content repository. Content federation enables teams to bring in data from remote sources and provide an up-to-date, consistent picture of the content that is used throughout the DXP.
#When do you need a DXP?
DXPs can be helpful across a broad set of use cases. Those who want to deliver powerful digital experiences that can implement DXPs when they want to make their workflows more efficient, use best-of-breed tooling, or when they want to rid their stacks of data silos. Creating a continuous flow of information from one element of a system to another can be beneficial for a broad range of use cases.
Let’s take a closer look at some of these use cases to better understand how implementing a DXP is helpful.
Portals are sophisticated content repositories that can be used to neatly organize large amounts of content such as employee intranets or content hubs. Portals often require multiple sources of content and stakeholders to be able to reuse content in multiple contexts. These requirements make them strong candidates for a DXP use case. Learn how BioCentury built a content hub portal using Hygraph as a composable DXP.
eCommerce sites are the new standard for purchasing items beyond a brick-and-mortar store. Delivering high-powered, performant eCommerce experiences at scale is a clear case for DXPs where consistency and accuracy of data are paramount. Learn how Burrow built their eCommerce site with Hygraph as a DXP.
Marketing websites are still the central way that brands interact with their customers; however, the customer experience of these websites can be enriched using personalization features or A/B testing to ensure that only the most engaging content is used. DXPs are appropriate where teams want to build a data-oriented, future-proof stack. Learn how Travel Weekly used Hygraph as their DXP to build their performant marketing site.
Federated Content Applications
Federated Content applications bring data together from multiple external services to create an engaging end user experience. Because content is being fed from multiple sources, implementing a DXP is a must to ensure that data is consistent across the platform. Learn how Telenor built a federated content application using Hygraph as their DXP.
#How to get Started with Implementing the DXP
In order to begin to implement a DXP, there are several steps to consider.
Evaluate your Needs and Goals
The DXP landscape is vast and each system or approach has various pros and cons. The most important things to understand is how this new approach will affect your team, the digital experiences you can create, and how the architecture will grow with you in the long term. The first step is to have a good understanding of what kind of digital products you would like to produce with your DXP.
Considering questions like these will help you get a better sense of your needs:
- What are the competencies of my team?
- How will this architecture scale?
- How many channels should I consider with a DXP?
- Do I want the ability to experiment with new technologies as they arise?
- Do I want to be tied to a single vendor?
- How much of my tech stack should carry over into a new approach?
Answering these questions will help teams bring together better understanding for what kind of system or approach is best for your project. It will also make it clear how large of a migration is needed to this new approach and may help give a sense of the timeline required.
Choose between the Composable and Monolith DXP Approaches
Once you have a sense of what you want to achieve with migrating to a DXP approach, it can be easy to understand whether or not a monolith or composable approach is best. There are tradeoffs with each approach so it is important to evaluate which will make your projects more productive in the long run.
Monolith systems offer the ability to have DXP functionality out of the box; however, teams will be limited by the availability of specific features depending on the vendor. Composable DXPs require more time in the initial configuration of the architecture; however they enable more flexibility to build a wide range of digital experiences and are largely extensible. The inherent extensibility makes it easy to add and remove functionality as it is relevant to their use case.
Evaluate your Toolsets
Evaluating the landscape of tools can be overwhelming due to the crowded DXP markets. Taking time to consider your goals and capabilities will help you determine the correct tooling. To learn how Hygraph has enabled teams to build composable DXPs, reach out. We are happy to discuss your use case and offer suggestions in terms of approach.