Over-engineered or needlessly complex systems are one of the most common reasons technology projects in digital publishing fail.
As new technology and frameworks emerge and the needs of digital publishers — from editorial teams to the business side — evolve, your tech footprint can become incredibly complex, very quickly.
This can result in a spaghetti infrastructure with complicated integrations and interactions, which presents huge business risks because over-engineered tech stacks:
- Are costly and time-consuming to maintain
- Are more likely to break or fail at their core purposes
- Can be a deterrent to key talent you’re trying to attract
The Code Company talk a lot internally and with clients about our “anti-complexity” mindset and minimalist approach to building publishing stacks. It’s a pretty basic concept that comes down to focusing on what’s really important for a business and choosing technology that will have the largest return on investment.
Even sophisticated and diverse business needs do not necessarily require complex tech. Too often, we see digital publishers trying to build a Ferrari for a milk run.
With that in mind, we’ve put together five practical examples of how you can simplify your digital publishing technology using common tools.
Here’s what we’ll cover:
- Google Tag Manager with a data layer
- Automated data visualisation dashboards
- Centralised workflow inside CMS
- 15-minute newsletters
- Subscription platforms
Google Tag Manager with a data layer
Google Tag Manager (GTM) and data layers are pretty quick and easy to implement and have a long tail of benefits.
At its simplest, GTM is a copy & paste job and allows a wider range of users to manage scripts and tags on your website — Google Analytics (GA), Facebook retargeting pixels, etc. — without needing a developer.
GTM’s value can greatly enhanced by ensuring your content management system (CMS) builds a data layer. This means that when the page loads, important context and article attributes such as taxonomies, comments, authors etc. are load too. Additional user attributes, such as login or membership status can also be piped in.
The result of adding a data layer in GTM is that you can produce more advanced reporting. For example, telling GA the post author of every page view means you can easily build reports that group page views by authors. Another example could be finding out the average time on site for paying subscribers vs. free subscribers.
All of this impactful data can be gathered without the need, or expense, of developers.
Automated data visualisation dashboards
You no longer need engineers or specialist database experts to build custom dashboards or sophisticated reporting visualisations.
The reality is that data lives in many places in most tech stacks, but building a data lake or data warehouse can be a significant investment both in upfront costs and ongoing maintenance. As an alternative, we’ve seen tools such as Google Sheets set up to act as databases.
A recent example we came across pumped data from GA and Google Ad Manager. With some simple automation between these services, it allowed for near real-time updating and unique reporting without needing a data specialist to set it up.
Centralised workflow inside CMS
Editorial teams commonly struggle with clunky processes and often use a myriad of tools — Google Docs, Trello, calendars — to handle the editorial process.
What’s often overlooked is that most CMSs offer pretty easy ways to extend the default out-of-the-box workflows, meaning you can use the CMS for approval flows, calendering, and internal editorial comments across articles. This can cut down on the cost of running several different platforms and reduce the risk of human error or data loss.
One example of where the effort was made to bring as much of the editorial process into a CMS was Nine Australia’s INK CMS project, which was built on top of WordPress. INK moved everything from editing to legal approvals and Slack alerts into the CMS, streamlining day-to-day processes considerably.
It’s incredibly common to see someone with the unfortunate job of having to copy and paste content out of a CMS into an ESP such as Mailchimp or Campaign Monitor. Not only does it take forever, but there’s also a heightened risk of sending out the wrong link unless you intensely review every send.
Moving the composing of a newsletter into the CMS is actually pretty straightforward.
At the simple end of the spectrum, there are plugins like Newsletter Glue for WordPress that let you plug and play with a dozen mainstream ESPs.
If simple plugins like that don’t offer enough flexibility or custom workflows, most of these ESPs have APIs that can be plugged into your CMS and have newsletters pushed straight into people’s inboxes.
This is one of those features where we see drastic returns on investment, with the average time to compose and send a newsletter dropping to less than 15 minutes. Because the CMS is generating the images and links etc., there’s little chance someone will forget to update a hyperlink or send out the wrong story.
We often meet publishers who believe their subscription needs require a custom-made system that’s built from scratch. Tools like Stripe’s API make it seem like a custom subscription solution would be simple to set up –– and for less expense than SaaS subscription platforms.
But sorting out all of the peripheral requirements to run a subscription service is more complicated that it appears. You need to identify solutions for email automation, collection systems for failed payments, and reporting.
That’s why we generally recommend leaning on SaaS tools to handle all these business-critical functions and find they are usually well worth a revenue share with the developers. On the simpler end, tools like Memberful are often a quick way to build out a proof-of-concept subscription product that will scale and relieve headaches in the short term.
If you want to offer group subscriptions or the option to bundle, more sophisticated subscription products like Recurrly, Chargify, or Chargebee offer much more flexibility – but can be pricey. Enterprise subscription tools like Zuora or Piano are also available for higher-end solutions.
We recently moved California Sun off a custom subscription platform onto Memberful:
“Our old membership site was riddled with errors and confusing navigation prompts. I’d get emails almost every day from frustrated readers.
“Memberful is really robust with a seamless and user-friendly interface. I no longer get daily account queries, so that’s just wonderful!”
It can be an uncomfortable truth that many technology requirements for media and publishing platforms are actually pretty simple.
It’s disheartening when internal or agency teams sell over complex tech that eventually fails to do what it originally set out to achieve.
Some helpful questions to ask when greenlighting projects or proposals for new digital publishing technology:
- Are there any other ways we could build this feature?
- If we had 50% of the time or budget, would we approach it differently?
- Are we using industry-standard / highly-used modules/plugins/libraries, or is this feature being built with some experimental tech or run by a single developer who may abandon something critical?
- Does this approach require additional overheads? (e.g. Additional AWS resources, SaaS subscriptions, etc.)
- Do we need different talent and skill sets than we currently have to operate or develop in this?
Asking these questions at the start can avoid tech debt that will cost a lot of headaches, and money, down the line.
This article is based on a workshop presented by The Code Company’s Ben May at the 2022 Mumbrella Publish Awards in Sydney. The full presentation can be viewed on Mumbrella Pro, which offers a free 7-day trial.