Structured content enables online publishers to assemble pieces of content in multiple ways.\u00a0 However, the process by which this assembly happens can be opaque to authors and designers. Read on to learn how orchestration is evolving and how it works.<\/p>\n
To many people, orchestration sounds like jargon or a marketing buzzword. Yet orchestration is no gimmick. It is increasingly vital to developing, managing, and delivering online content. It transforms how publishers make decisions about content, bringing flexibility and learning to a process hampered in the past by short-term planning and jumbled, ad-hoc decisions.\u00a0\u00a0<\/p>\n
Revealing the hidden hand of orchestration<\/h2>\n
Orchestration is both a technical term<\/a> in content management and a metaphor. Before discussing the technical aspects of orchestration, let\u2019s consider the metaphor.\u00a0 Orchestration in music is how you translate a tune into a score that involves multiple instruments that play together harmoniously. It\u2019s done by someone referred to as an arranger, someone like Quincy Jones. As the New Yorker<\/em> once wrote<\/a>: \u201cEveryone knows Quincy Jones\u2019s name, even if no one is quite sure what he does. Jones got his start in the late nineteen-forties as a trumpeter, but he soon mastered the art of arranging jazz\u2014turning tunes and melodies into written music for jazz ensembles.\u201d<\/p>\n Much like music arranging, content orchestration happens off stage, away from the spotlight. It doesn\u2019t get the attention given to UI design. Despite its stealthy profile, numerous employees in organizations become involved with orchestration, often through small-scale A\/B testing by changing an image or a headline.\u00a0<\/p>\n Orchestration typically focuses on minor tweaks to content, often cosmetic changes. But orchestration can also address how to assemble content on a bigger scale. The emergence of structured content makes intricate, highly customized orchestration possible.<\/p>\n Content assembly requires design and a strategy.<\/strong> Few people consider orchestration when planning how content is delivered to customers. They generally plan content assembly by focusing on building individual screens or a collection of web pages on a website. The UI design dictates the assembly logic and reflects choices made at a specific time.\u00a0 While the logic can change, it tends to happen only in conjunction with changes to the UI design.\u00a0<\/p>\n Orchestration allows publishers to specify content assembly independently of its layout presentation. It does so by approaching the assembly process abstractly: evaluating content pieces\u2019 roles and purposes that address specific user scenarios.<\/p>\n Assembly logic is becoming distributed<\/strong>. Content assembly logic doesn\u2019t happen in one place anymore. Originally, web teams created content for assembly into web pages using templates defined by a CMS on the backend. In the early 2000s, frontend developers devised ways to change the content of web pages presented in the browser using an approach known initially as Ajax<\/a>, a term coined by the information architect Jesse James Garrett. Today, content assembly can happen at any stage and in any place.\u00a0<\/p>\n Assembly is becoming more sophisticated<\/strong>. At first, publishers focused on selecting the right web page to deliver. The pages were preassembled \u2013 often hand-assembled. Next, the focus shifted to showing or hiding parts of that web page by manipulating the DOM (document object model).\u00a0\u00a0<\/p>\n Nowadays, content is much more dynamic. Many web pages, especially in e-commerce, are generated programmatically and have no permanent existence.\u00a0 \u201cSingle page applications\u201d (SPAs<\/a>) have become popular, and the content will morph continuously.\u00a0<\/p>\n The need for sophisticated approaches for assembling content has grown with the emergence of API-accessible structured content. When content is defined semantically, rather than as web pages, the content units are more granular. Instead of simply matching a couple of web page characteristics, such as a category tag and a date, publishers now have many more parameters to consider when deciding what to deliver to a user.<\/p>\n Orchestration logic is becoming decoupled from applications<\/strong>. While orchestration can occur within a CMS platform, it is increasingly happening outside the CMS to take advantage of a broader range of resources and capabilities. With APIs growing in coordinating web content, much content assembly now occurs in a middle layer between the back-end storing the content and the front-end presenting it. The logic driving assembly is becoming decoupled from both the back-end and front-end.\u00a0<\/p>\n Publishers have a growing range of options outside their CMS for deciding what content to deliver.\u00a0 Tools include:<\/p>\n These options vary in their aims and motivations, and they differ in their implementations and features. Their capabilities are sometimes complementary, which means they can be used in combination.\u00a0<\/p>\n Content structuring supports extensive variation in the types of content to present and what that content says.\u00a0<\/p>\n Orchestration involves more than retrieving a predefined web page.\u00a0 It requires considering many kinds of inputs to deliver the correct details.\u00a0<\/p>\n Content orchestration will reflect three kinds of considerations:<\/p>\n Content characteristics play a significant role in assembly<\/strong>. Content characteristics define variations among and within content items. An orchestration layer will account for characteristics of available content pieces, such as:<\/p>\n Each of these characteristics can be a variable and useful when deciding what content to assemble. They indicate the compatibility between pieces and their suitability for specific contexts.<\/p>\n Other information in the enterprise IT ecosystem can help decide what content to assemble that will be most relevant for a specific context of use. This information is external to the content but relevant to its assembly.<\/p>\n Business data is also an orchestration input.<\/strong> Content addresses something a business offers. The assembled content should link to business operations to reflect what\u2019s available accurately.<\/p>\n The assembled content will be contextually relevant only if the business can deliver to the customer the product or services that the content addresses. Customers want to know which pharmacy branches are open now or which items are available for delivery overnight.\u00a0 The assembled content must reflect what the business can deliver when the customer seeks it.<\/p>\n The orchestration needs to combine content characteristics from the CMS with business data managed by other IT systems. Many factors can influence what content should be presented, such as:<\/p>\n Business data have complex rules managed by the IT system of record, not the CMS or the orchestration layer.\u00a0 For content orchestration, sometimes it is only necessary to provide a \u201cflag,\u201d checking whether a condition is satisfied to determine which content option to show.<\/p>\n Customer context is the third kind of orchestration input. <\/strong>Ideally, the publisher will tailor the content to the customer\u2019s needs \u2013 the aim of personalization.\u00a0 The orchestration process must draw upon relevant known information about the customer: the customer\u2019s context.<\/p>\n The customer context encompasses their identity and their circumstances. A customer\u2019s circumstances can change, sometimes in a short time.\u00a0 And in some situations, the customer\u2019s circumstances dictate the customer\u2019s identity. People can have multiple identities, for example, as consumers, business customers at work, or parents overseeing decisions made by their children.<\/p>\n Numerous dimensions will influence a customer\u2019s opinions and needs, which in turn will influence the most appropriate content to assemble. Some common customer dimensions include:<\/p>\n The chief challenge in establishing the customer context is having solid insights.\u00a0 Customers\u2019 interactions on social media and with customer care provide some insights, but publishers can tap a more extensive information store.\u00a0 Various sources of customer data could be available:<\/p>\n Much of this information will be stored in a customer data platform (CDP), but other data will be sourced from various systems.\u00a0 The data is valid only to the extent it is up-to-date and accurate, which is only sometimes a safe assumption.<\/p>\n Content behavior can shape the timing and details assembled in orchestration<\/strong>. Users can signal their intent through their interaction with content. The user\u2019s decisions while interacting with content can signal their intentions.\u00a0 Some behavior variables include:<\/p>\n The most valuable and reliable signals will be specific to the context.<\/strong> Many factors can shape intent, so many potential factors will not be relevant to individual customers. Just because some factors could be relevant in certain cases does not imply they will be applicable in most cases.\u00a0<\/p>\n Though challenging, leveraging customer intent offers many opportunities to improve the relevance of content. A rich range of possible dimensions is available. Selecting the right ones can make a difference.\u00a0<\/p>\n Don\u2019t rely on weak signals to overdetermine intent<\/strong>. When the details about individual content behavior or motivations are scant, publishers sometimes rely on collective behavioral data to predict individual customer intentions.\u00a0 While occasionally useful, predictive inputs about customers can be based on faulty assumptions that yield uneven results.\u00a0<\/p>\n Note the difference between tailoring content to match an individual\u2019s needs and the practice of targeting. Targeting differs from personalization because it aims to increase average uptake rather than satisfy individual goals. It can risk alienating customers who don\u2019t want the proffered content.<\/p>\n Draw upon diverse sources of input<\/strong>. By utilizing a separate layer to manage orchestration, publishers, in effect, create a virtual data tier that can federate and assess many distinct and independent sources of information to support decisions relating to content delivery.\u00a0<\/p>\n An orchestration layer gives publishers greater control over choosing the right pieces of content to offer in different situations. Publishers gain direct control over parameters to select,\u00a0 unlike many AI-powered \u201cdecision engines\u201d that operate like a black box and assume control over the content chosen.<\/p>\n If the inputs are the notes in orchestration, the score is how they are put together \u2013 the arrangement. A rich arrangement will sometimes be simple but often will be sophisticated.\u00a0<\/p>\n Orchestration goes beyond web search and retrieval<\/strong>. In contrast to a ordinary web search, which retrieves a list of relevant web pages, orchestration queries must address many more dimensions.\u00a0<\/p>\n In a web search, there\u2019s a close relationship between what is requested and what is retrieved. Typically, only a few terms need matching. Web search queries are often loose, and the results can be hit or miss. The user is both specifying and deciding what they want from the results retrieved.<\/p>\n In orchestration, what is requested needs to anticipate what will be relevant and exclude what won\u2019t be. The request may refer to metadata values or data parameters that aren\u2019t presented in the content that\u2019s retrieved. The results must be more precise. The user will have limited direct input into the request for assembled content and limited ability to change what is provided to them.<\/p>\n Unlike a one-shot web search process, in orchestration, content assembly involves a multistage process.\u00a0\u00a0<\/p>\n The orchestration of structured content is not just choosing a specific web page based on a particular content type.\u00a0 It differs in two ways:<\/p>\n Unpacking the orchestration process. <\/strong>Content orchestration consists of three stages:<\/p>\n Find relevant content items<\/strong>. Generally, this involves searching metadata tags such as taxonomy terms or specific values such as dates. Sometimes, specific words in text values are sought. If we have content about events, and all the event descriptions have a field with the date, it is a simple query to retrieve descriptions for events during a specified time period.<\/p>\n Typically, a primary content type will provide most of the essential information or messages. However, we\u2019ll often also want to draw on information and messages from other content types to compose a content experience. We must associate different types of items to be able to combine their details.<\/p>\n Match companion content types. <\/strong>What other topics or themes will provide more context to a message? The role of matching is to associate related topics or tasks so that complementary information and messages can be included together.<\/p>\n Graph queries are a powerful approach to matching because they allow one to query \u201cedges\u201d (relationships) between \u201cnodes\u201d (content types.)\u00a0 For example, if we know a customer is located in a specific city, we might want to generate a list of sponsors of events happening in that city.\u00a0 The event description will have a field indicating the city. It will also reference another content type that provides a profile of event sponsors.\u00a0 It might look like this in a graph query language like GQL, with the content types in round brackets and the relationships in square brackets.<\/p>\n We have filtered events in the customer\u2019s city (fictiously named My City) and associated content items about sponsors who have sponsored those events. Note that this query hasn\u2019t indicated what details to present to users. It only identifies which content types would be relevant so that various types of details can be combined.\u00a0<\/p>\n Unlike in a common database query, what we are looking for and want to show are not the same.\u00a0<\/p>\n Select which details to assemble<\/strong>. We need to decide what information within a relevant content type which details will be of greatest interest to a user. Customers want enough details for the pieces to provide meaningful context. Yet they probably won\u2019t want to see everything available, especially all at once \u2013 that\u2019s the old approach of delivering preassembled web pages and expecting users to hunt for relevant information themselves.<\/p>\n Different users will want different details, necessitating decisions about which details to show. This stage is sometimes referred to as experience composition<\/a> because the focus is on which content elements to deliver. We don\u2019t have to worry about how these elements will appear on a screen, but we will be thinking about what specific details should be offered.<\/p>\n GraphQL, a query language used in APIs, is very direct in allowing you to specify what details to show. The GraphQL query mirrors the structure of the content so that one can decide which fields to show after seeing which fields are available. We don\u2019t want to show everything about a sponsor, just their name, logo, and how long they\u2019ve been sponsoring the event.\u00a0 A hypothetical query named \u201clocal sponsor highlights\u201d would extract only those details about the sponsor we want to provide in a specific content experience.<\/p>\n The process of pulling out specific details will be repeated iteratively as customers interact with the content.<\/p>\n Now that we have covered the structure and process of orchestration let\u2019s look at its planning and design. Publishers enjoy a broad scope for orchestrating content. They need a vision for what they aim to accomplish. They\u2019ll want to move beyond the ad hoc orchestration of page-level optimization and develop a scenario-driven approach to orchestration that\u2019s repeatable and scaleable.<\/p>\n Consider what the content needs to accomplish<\/strong>. Content can have a range of goals. They can explicitly encourage a reader to do something immediately or in the future. Or they encourage a reader\u2019s behavior by showing goodwill and being helpful enough that the customer wants to do something without being told what to do.<\/p>\n\n
Orchestration inputs that frame the content\u2019s context<\/h2>\n
\n
![\"\"](\"https:\/\/i0.wp.com\/storyneedle.com\/wp-content\/uploads\/2024\/01\/context.png?resize=580%2C285&ssl=1\")
<\/a><\/figure>\n\n
\n
\n
\n
\n
The orchestration score<\/h2>\n
\n
\n
![\"\"](\"https:\/\/i0.wp.com\/storyneedle.com\/wp-content\/uploads\/2024\/01\/stages.png?resize=580%2C367&ssl=1\")
<\/a><\/figure>\nMATCH (:Event WHERE location=\u201dMy City\u201d) - [:SponsoredBy] -> (:SponsorProfile)<\/code><\/p>\nQuery LocalSponsorHighlights {
\u2026 on SponsorProfile {
name
logo
sponsorSince
} }<\/code><\/p>\nTurning visions into versions<\/h2>\n
![\"\"](\"https:\/\/i0.wp.com\/storyneedle.com\/wp-content\/uploads\/2024\/01\/leonard-bernstein-conducts-the-new-york-philharmonic-in-a-young-peoples-concert-680e02.jpg?resize=580%2C441&ssl=1\")
<\/a>