We’re not going mad, we’re going headless
By: Chris Victory, SVP of Partnerships (New York)
Headless website architecture has become a much discussed topic with everyone from marketers to developers eagerly looking to reap some benefits. But it’s not the only one that’s turning heads. Header bidding has been another topic that has been at the top of many marketers’ minds over the last few years but has often been mistakenly confused with headless architecture. To ensure we all keep our heads on straight, we’ll explain the unique qualities of headless website architecture and header bidding.
To clear the air on header bidding, let’s do a quick review. Programmatic advertising is the marketing solution that promised automation and efficiency. But with the proliferation of AdTech and MarTech vendors, publishers have been experiencing declining revenues and lower yield on their inventory. This led publishers to take a “waterfall” approach to selling inventory, resulting in lost opportunities to sell impressions to the highest bidder. This is where header bidding comes into play: it gives publishers the ability to make impressions available to multiple ad exchanges simultaneously, which should result in higher yield and revenue.
“Headless website architecture can lead to more efficient and agile development environments.”
Headless website architecture, on the other hand, is a set of solutions solving for pain points businesses face as their architecture becomes more intricate, especially related to back-end development. As the name suggests, the idea of headless stems from decoupling the front-end user interface from the back-end systems, connecting them through web services such as APIs. This setup provides a number of benefits that ultimately support more agility in development and execution in regards to increasingly complex tech stacks. Common applications and use cases include browsers, content management systems and more recently, commerce sites. Taking these environments as examples, let’s walkthrough the impact a headless approach can have on varying systems.
A headless browser, the simplest of the bunch, is simply a web browser without the graphical user interface (GUI). The most common application for a headless browser is the automated testing of web applications or even just as simple as seeing how the browser renders a URL. Almost all web browsers offer a headless mode – it’s about as common as having a voice assistant on your phone.
Content Management Systems (CMS) used to be tightly coupled across their frontend (website) and back-end framework. With a headless CMS platform, one can independently operate their content management tool, connecting them to multiple front-end applications via APIs. A popular reason for a headless CMS is that a front-end developer can be enabled to choose and use a CMS platform with which they are familiar. One can also choose to optimize or launch separate parts of a website, without having it affect the entire site. Decoupling your CMS from your frontend allows for more flexibility in testing and design, especially in complex environments, likely making your developers the happiest of coders.
Headless commerce is the relatively new kid on the block and is very similar to a headless CMS architecture. But in this case, the e-commerce platform is what has been decoupled from the various front-end applications (website, mobile app, smartwatches, in-store interfaces, etc.). This allows developers to deliver updates and changes via APIs to the targeted application, rather than the entirety of all applications. With the proliferation of customer touchpoints and opportunities for customers to make a purchase, a headless commerce architecture is critical to delivering the best customer experience, tailored to the right end user. Both headless CMS and commerce also allow front-end developers more stability without the worry of the downstream interruptions from changes on the backend.
In one of the most buzzword-ridden industries, it’s easy to confuse and mismatch all of the tools and solutions of the past, current and future state of technology. But as demonstrated here, detailing the differences between header bidding and the variations of headless architecture, it’s critical to understand these differences. Headless website architecture can lead to more efficient and agile development environments, providing companies a way to attain another industry buzzword: customer experience. At Rokt, we have identified this as a company wide imperative of such importance that we have adopted it as a company value. We also strongly encourage our clients to investigate and learn more about headless architecture in their product offerings. Rather than a one size fits all approach, tailoring a customer’s experience on a 1:1 level provides benefits that are two-fold: meet short-term goals and provide long-term value of customers.
Perhaps a little conscious ‘decoupling’ could be beneficial for everyone.