he rise of marketing automation platforms (MAPs) like HubSpot, Marketo, Oracle Eloqua and Salesforce (Pardot) seems unstoppable. Globally, this market has been growing by double digits, and Forrester estimated the penetration of MAPs in the business-to-business space to be 58% in 2018. HubSpot alone grew their customer base by 36% in 2018, adding some 15,000 new customers during the year.
This means a couple of things. One is that the growing adoption of MAPs democratizes access to modern marketing practices across the board. This team-wide, easy access to marketing tools allows companies to compete effectively regardless of their size or the depth of their pockets. They no longer need massive budgets to be able to scale up their inbound, outbound or account-based marketing efforts. Nor are extensive engineering and development support on the backend required just to get started.
It also means that the volumes of marketing content that are managed in MAPs are exploding. This would typically include landing pages, email communications, blog posts, social media content and even actual websites. Digital marketing assets such as images, audio, video and other multimedia content are another key component.
MAPs are behind CMSs in
MAPs were built to make marketers’ jobs easier, and have become an essential enabler of the inbound marketing momentum, but it’s also fair to say that they are not yet, by and large, fully globalized. “Global” is not part of their DNA as a rule. These systems allow companies to compete globally, but the devil is in the details. So as companies set up and grow their marketing technology stacks, they should consider early on how their particular setup will support the globalization of their marketing content in the future.
In practice, marketing automation platforms are key, but are only one component of the set of tools that form a typical modern marketing stack. Figure 1 shows what other technologies are often part of that stack, along with examples of frequently used products in each category.
It’s not unusual to see an overlap of features between categories. MAPs in particular tend to aggregate several functionalities, such as email, SEO, social media, online advertising and analytics, or provide out-of-the-box integrations with other specialized marketing tools.
It’s no surprise that much of the marketing content that lives in MAPs is used in global campaigns and needs to be localized. However, localizing such content is not yet as simple or as easy as global businesses might want. The industry is still a few years behind compared to the level of multilingual support that exists in the more established space of enterprise content management systems (CMSs) or web CMSs. These would include the “traditional” platforms like Sitecore, WordPress, Episerver and TYPO3. CMSs have accumulated a wide range of features and components over the years and would normally contain built-in support for translation and publication of multilingual online content.
Adobe Experience Manager (AEM), for instance, comes with integrated translation management and support for both human and machine translation. This allows businesses to automate translation workflows by creating a cloud configuration that connects AEM to a selected language services provider or machine translation service. Among other things, AEM supports automating machine translation of user-generated content, such as posts and other user communications on community sites.
For WordPress, which may power over 30% of websites globally, there is a variety of translation plugins, some good and some less so, to create multilingual websites. Kentico EMS, another well-established web CMS, offers an advanced centralized hub for translation management, with customizable workflows, one-click machine translation and full XLIFF support. And some of the inherent appeals of SDL Tridion Sites are its translation capabilities and its focus on companies that span multiple geographies and languages. The list goes on.
Headless CMSs and static sites are here to stay
But while marketing automation platforms may currently lack rich built-in multilingual and translation capabilities, they compare well with the new breed of headless CMSs, like IBM Watson Content Hub, as well as against the current wave of static site generators. Both are currently hot trends in website development and have a direct impact on how multilingual content gets managed and localized.
The idea behind headless CMSs is to separate content (and its creation, management and storage) from its presentation (think templates, design and layouts) so that given content can be easily pushed to any channel and delivered on any device, big or small. On the other hand, a traditional “coupled” web CMS would combine its code with your custom code and templates, making it rather inflexible to manage and publish to multiple channels.
In this sense, a headless CMS eliminates the front-end component of the website and provides the content via an application programming interface (API). Put differently, front-end developers don’t need to know how to work with a CMS, while the content people don’t need to worry about the technical aspects of their website and can stay focused on what they do best: creating and managing content. A win-win for everyone involved.
In a similar vein, the current static website momentum aims to build fast, lightweight websites and accelerate their development by breaking each site into a set of HTML-based files that are generated once and stored on the server. This concept goes back to the early days of website development and rejects the way established dynamic CMSs are set up to work: building each page on-demand, in real time, based on templates and content stored in a backend database, for each request to the server.
With static websites, the content is the same for every visitor, with only limited options for personalization and serving dynamic content. In this scenario, modern static site generators such as Hugo or Jekyll are used to create pages in online repositories like GitHub or GitLab, with content managed in static-website CMSs like Netlify or Forestry. All this is on trend with using the best tools for a given purpose and connecting them tightly, rather than relying on large, monolithic systems.
This setup provides easy publishing of multilingual content but does require organizations to have engineering support at hand. While few marketing teams are technically savvy enough to manage this architecture themselves, this is not an issue for product development teams when used for software product localization.
Getting the plumbing right
At present, current CMSs for static websites come with no built-in functionality for translation management and, as such, are toward the “build” end of the build-buy spectrum when it comes to creating multilingual sites. However, some translation management systems (TMSs) do provide out-of-the-box integrations with repositories and will automatically trigger translation workflows when a source file is changed, pushing back localized files once the workflow is complete. Memsource, for instance, has connectors for online repositories such as Bitbucket, Git, GitLab and GitHub that support continuous localization by allowing users to identify files that have been added or updated and sending them directly for translation.
In this sense, the static approach will be less agile (understandably) when it comes to specifying what content can be translated in a continuous fashion. Static will be a more traditional “project-based” system and could be addressed with the translation proxy approach.
Another option is to use a “mega-connector” like Xillio, which offers a wide range of connectors to CMSs and repositories, coupled with its own API, to automatically manage the flow of content with translation systems. This aims to make true the eternal dream of continuous localization via plug-and-play rather than built on either custom or customized integrations: an automatic workflow that would remove or minimize human intervention and manual document handling.
Xillio, specifically, aims to achieve this through their Localization Hub, which serves as a kind of lightweight middleware, with connectors to both content repositories and translation tools. Another middleware provider that caters specifically to the translation industry, iLangL, offers connectors for TMSs and web CMSs via their central iLangL Cloud repository. Wordbee provides a standalone middleware called Beebox that allows centralized translation memories and boasts more than 40 connectors for popular systems.
Breaking the content silos
The reality is that many organizations continue to manage their marketing content in multiple systems. Marketing teams specialized on individual channels or functions, such as online, social, paid promotion, buzz or awareness, may use their own tool rather than one centralized repository or features of a larger MAP. There may also be regional preferences, constraints or historical reasons that result in marketing content residing in different systems across countries. The same happens when multiple brands are managed.
All of this makes running integrated campaigns internationally more complex and has driven the recent emergence of tools that manage content operations, such as Kapost or Contentful. These aim to break down barriers between individual teams, or silos, that work with content by providing one centralized content operations hub (Figure 2). This allows teams to plan global campaigns, define automatic workflows and manage content and other marketing assets from inception until their ultimate publication via connected systems such as MAPs, web CMSs or social media. There is also growing support for localization in these systems.
Kapost, for instance, includes a localization feature that allows the creation of multilingual content that will then go through a different workflow.
features in MAPs
Content marketers using current MAPs to deliver international campaigns have a solid and increasing set of features at their disposal. Figure 3 shows some of the typical international capabilities of marketing automation systems today. Many of these are also localized into several languages.
But while MAPs enable managing localized content and delivering marketing communications to customers globally, they may not have features to run global campaigns for specific markets or languages or provide corresponding analytics. In other words, “global” is not a dimension that could be applied across all features uniformly.
For instance, there is normally no direct way to take an existing campaign, with its associated content, assets and workflows, and simply target a new market or country using assets localized into a corresponding language. Similarly, MAPs would not have comprehensive analytics that would report on how a specific marketing tactic performs in a given market, from SEO and content performance down to conversion or closed opportunities.
Some of the currently lacking built-in capabilities are tackled by integrations with specialized tools. For instance, an integration with Google Search Console will help a marketer understand search metrics and search queries across countries and locales directly in the MAP. A connection with a data warehousing platform, via an existing integration or API, will allow the use of an analytics platform like Tableau. This way, companies can combine marketing data with other sources of data such as a customer relationship management to get a detailed picture of their marketing and sales activities.
Connectors to the rescue
Much of the current support for translation in marketing automation platforms rests on their connectivity with external TMSs in which the actual translation takes place. Like with CMSs, this integration is achieved either by out-of-the-box connectors, provided by individual TMS developers, or via their APIs. These are typically RESTful (REST), meaning web services that use HTTP requests to GET, PUT, POST, PATCH and DELETE data.
Figure 4 shows how some commercial TMSs currently connect with MAPs via built-in connectors or APIs. In addition, a modern TMS would come with a more extensive set of connectors for various CMS platforms.
Organizations typically make use of existing connectors to MAPs. One reason for this is the obvious need for speed in marketing and the frequency of publishing or updating content online or on social media. Because of the velocity that modern marketing programs demand, there is no other way than to automate the process of localization. It is not unusual for companies to customize these connectors for their specific setups, or to opt to develop their own using the available APIs if their scenario or technical requirements are unique. This usually requires a sizeable investment of time and money, and an ongoing commitment to keep the integration up to date, along with the platform’s development.
I spy an API
Given the often-messy reality of how marketing assets are set up, some customizations or workarounds are frequently needed. For instance, certain content types may not be supported. If website templates or landing pages contain a lot of customized sections, they may not get extracted by a given connector. Complex access rights via API for specific blocks of content or files may lead to issues downstream. The involvement of multiple service providers, or the need to connect multiple instances, increases the complexity further.
However, when marketing platforms are set up and running smoothly, translation jobs for new or updated content can be triggered manually or automatically and returned back translated without the need to delve into the complexities of translation management. Workflows in the TMS will see to the rest.
One of the really useful features of such an arrangement is in-context translation or in-context preview of translated content, or the availability of a staging server where localized pages and assets can be tested along with their functionality. It’s often difficult for reviewers to spot problems when working inside a translation tool, so having the context at hand can improve accuracy.
Let’s embrace TAPICC
The state of connectivity between MAPs and TMSs, commercial or proprietary, lags behind what is available for CMS platforms in terms of scale and depth, but it’s following the same trajectory. There is a lack of standardization in how individual systems talk to each other, whether it’s via connectors or APIs, and the link between MAPs and TMSs is generally a bottleneck in the flow of content. This also results in variation in the way the connectivity is created, and an equally unnecessary duplication of efforts by both technology providers and LSPs.
This is why the TAPICC initiative, run under the umbrella of GALA, is so welcome. Standing for Translation API Cases and Classes, its very goal is to overcome the lack of standardization in connecting with content management systems. It should also prove useful when it comes to connectivity with marketing automation platforms.
Currently in the initiative phase, its aim is to produce a basic standard that would ensure an elementary interoperability between systems, one that would be extendable with advanced functionality. It’s set to use XLIFF 2.0 and exchange data on the segment/unit level, not based on files as is the case normally with MAPs. Technically, an output should be a RESTful API specification for such connections.
It’s still early, but if this standardization effort comes to fruition and is embraced by the industry, the “integration question” might eventually become a nonissue. It doesn’t mean the need for integrations would be eliminated, but at least they won’t have to be reinvented again and again.
The importance of content marketing has grown exponentially, and with it, the amount of content that gets managed in marketing automation platforms. The existing integrations and API connections with TMSs mean that translating this content is easier than ever before. The essential plumbing for content to flow in a modern marketing technology stack is in place. The expected future developments in this space should make running global campaigns even smoother.