Previously, I published a post about Marketing Suite Fatigue. I described Marketing Suite Fatigue as a situation in which an organization has put “all of their eggs in one basket” with a large marketing suite vendor but is deriving less value than expected. I detailed seven key symptoms of Suite Fatigue:
- Frequent Price Increases
- Implementation & UI Complexity
- Vendor Lock-in
- Forced Version Migrations
- Lack of Innovation/Unfulfilled Roadmap Promises
- Lack of Intra-suite Integration
- Poor Customer Support
In this post, I’ll share some practical tips on how you can reduce your dependence on a single marketing suite and build a martech architecture that provides you more freedom, control, and flexibility. (Note: If you prefer an AI-generated podcast about this post and the last one, you can listen here.)
Vendor lock-in happens to the best of us
It’s surprisingly common for organizations to have gone “all-in” on a large marketing suite. In most cases, it doesn’t happen all at once but gradually over several years, with different people working at the organization. For example, let’s say you work for Fortune 500 Inc. and you've standardized on the Adobe Experience Cloud (I'll pick on Adobe since that is my background!). Your website and app are built using AEM, you use Adobe Analytics for digital analytics, Adobe Target for testing and experimentation, Adobe Campaign as your email provider, and Adobe Audience Manager for building marketing campaign audiences.
Historically, Fortune 500 Inc. may have begun using Omniture SiteCatalyst twenty years ago (before Adobe acquired it). Back then, it may have been upsold to use Offermatica (now Adobe Target). Several years later, a new hire may have decided to add Adobe Campaign to the contract. A few years after that, a different person may have needed more robust customer audiences, so they added Audience Manager to the contract.
That’s how it happens. Over time, more products are added, and now the organization has a large, multi-year contract and is dependent on Adobe (or Salesforce) for core components of its martech stack. If all of these marketing suite products are working in concert, reasonably priced, actively adopted by marketers, driving product innovation, and underpinned by excellent support, then Fortune 500 Inc. is in great shape! And I’m sure tons of organizations love being “all-in” on their chosen marketing suite. But what if Fortune 500 Inc. begins to experience some of the Suite Fatigue issues outlined in my previous post? Even one or two of these symptoms can be problematic.
Let’s give Fortune 500 Inc. the benefit of the doubt and assume it’s moderately happy with its marketing suite investment. But now, suppose their friendly Adobe sales representative tells them that they should move from Adobe Analytics to the newer Adobe Customer Journey Analytics (CJA). They should also move from Adobe Campaign (which is being sunset) to Adobe Journey Optimizer (AJO). But to use those two products, they also need to move to the Adobe Experience Platform (AEP). Additionally, since Adobe Audience Manager (AAM) is being replaced by Adobe Real-Time CDP (RT-CDP), they should also move to RT-CDP. Part of this migration will require migrating to the new Adobe Web SDK for data collection and translating all data to Adobe’s XDM schema. The overall migration could take up to a year, and the professional services contract for the migration is quite significant. Suddenly, Fortune 500 Inc. is facing a massive project to upgrade multiple products and retrain all its marketers. While the latest versions of the marketing suite tools look cool, the cost of the new Adobe contract could skyrocket. But Fortune 500 Inc. is fully committed to Adobe. Adobe is their martech stack. Do they have to just suck it up and migrate?
This scenario is pretty typical for organizations that have gone “all-in” on marketing suites. The underlying problem is that they are beholden to their lone martech vendor. Hopefully, that vendor doesn’t force them to migrate, but if they resist, how long will they be able to continue using the current versions of the products? Will the current versions continue to innovate and receive new features, or will innovations be available only to newer versions?
Whether you are currently unhappy with your marketing suite or content but leery of having to continuously rely on a single vendor for innovation and costly new-version migrations, it’s in your best interest to take back some control of your martech stack, even if you choose to continue using marketing suite products. Therefore, the following will share my advice for taking control of your martech stack and mitigating the risk of sole vendor dependence.
How to mitigate marketing suite risk
There are several ways and degrees to which organizations can mitigate their reliance on marketing suites. I’ll share a few different strategies that vary in the level of effort required and the independence they provide.
Option 1 - Replace one or more suite products
Suite Relief: Minimal | Effort: Moderate
If you want independence from your marketing suite, the most straightforward approach is to diversify your martech stack like you would an investment portfolio. Instead of using the same marketing suite vendor for most of your martech stack, replace one or more of the tools you are using within the marketing suite today with non-marketing suite alternatives.
For example, if Fortune 500 Inc. is currently using Adobe Campaign, it might choose to replace it with Iterable. Doing this would require work, such as migrating the customer audiences they have in Adobe Campaign to Iterable. Most companies would only do this if they were unhappy with the marketing suite product, thought the non-suite product was better, or wanted to reduce their overall dependence on the marketing suite. After all, the fewer products you are using in one marketing suite, the less vulnerable you are to price increases and other types of vendor lock-in.
If you do pursue option 1 for diversification, keep in mind that it may be easier to replace marketing suite products that are less reliant on collecting data via JavaScript tags or SDKs, since re-tagging typically is a larger development effort (more on this later).
Option 2 - Backup customer data in a cloud warehouse
Suite Relief: Moderate | Effort: Easy
For almost any marketing effort, it’s essential to have a holistic picture of your customer. Creating this holistic view requires leveraging data from all digital properties and other customer touchpoints (e.g., stores, call centers, etc.). Most organizations today use a cloud data warehouse (Snowflake, Databricks, GCP, Azure, Redshift, etc.) to store all customer data. If your organization has a cloud data warehouse, the first thing you want to do is ensure you are sending all customer data from your marketing suite to the cloud warehouse. Aggregating all customer data in the warehouse allows you to combine the marketing suite event data with any other customer data you have. If your organization doesn’t currently have a cloud data warehouse, you should consider doing that as soon as possible. While organizations can treat their marketing suite as their data warehouse, I don’t recommend it. Marketing suites are much more expensive than cloud data warehouses for storing customer data, and cloud data warehouses offer many advantages over marketing suite vendors.
There are several reasons why simply backing up your marketing suite data in a cloud data warehouse is advantageous and can start to limit your dependence on marketing suites:
- You can use a Composable CDP to improve identity across user IDs from multiple data stores.
- You can use a Composable CDP to build more comprehensive customer audiences across multiple data stores. These customer audiences can be centralized and used by downstream marketing suites and other Martech products.
- You can use a Composable CDP to activate audiences across martech tools or advertising destinations.
- You can keep historical customer data for as long as you want, unlike marketing suites that might force or financially incentivize you to remove it after a period of time.
Note that some of these choices aren’t mutually exclusive. For example, if Fortune 500 Inc. were to pursue option 2 and have customer audiences built in the cloud data warehouse (with the help of a Composable CDP), it would be infinitely easier for them to execute option 1 above, since their customer audiences are stored upstream in the warehouse and could be pushed down to a new email provider without having to recreate them manually.
Option 3 - Stop using marketing suite data collection
Suite Relief: High | Effort: Difficult
When marketing digitized in the early 2000s, organizations realized that most customer interactions would be digital. If you want to listen to or interact with your customers, it’s now often done by collecting digital signals (called events) about them. Many SaaS marketing products use JavaScript tags or SDKs to collect customer events. Collecting these digital events is a LOT of work. You have to embed code on your website and mobile app that sends data to the SaaS company's servers for processing and storage. Most organizations began collecting this data decades ago, often through digital analytics tools such as Omniture or Google Analytics. Due to the amount of work to put this data collection in place, many companies are hesitant to replace these tags. For example, Fortune 500 Inc. may still be using an updated version of tags set back in the Omniture days!
One reason marketing suite vendors are so “sticky” is that they own the organization's data-collection infrastructure. As long as Fortune 500 Inc. has Adobe tags on its website and mobile app, it will likely still be locked into Adobe’s marketing suite. Therefore, organizations that truly want to break free from the marketing suite must eventually stop using the vendor’s data collection. Unfortunately, that means ripping out existing tags and adding new ones that are independent of the marketing suite vendor.
While this is a lot of work, I’m a big advocate of owning your own data collection. Disintermediating yourself from the marketing suite at the data-collection level brings a level of freedom, since you control where you send customer data.
There are a few different ways that you can own your own data collection:
- Build your own data collector - Your organization can build its own data collector. There are many open-source code bases you can use to collect events from your digital properties.
- 3rd-Party data collection - Several vendors and tools are available for data collection. Hightouch offers Hightouch Events, and other tools like Snowplow, Rudderstack, and Segment allow you to collect customer data and route it to any martech destination.
Once you own your customer data collection, the next decision is where to send customer data. Here are a few different options based on how much independence you want from marketing suites:
- Continue sending data directly to martech products - If you’re not quite ready to break up with your marketing suite but want the ability to do so if needed, you can own your own data collection while continuing to send the data to the marketing suite products. For example, Fortune 500 Inc. may choose to replace Adobe tags with Hightouch Events tags and then continue to route data to Adobe Analytics, Adobe Target, Adobe Campaign, etc. This way, they can still use the marketing suite but swap out an Adobe product for another at any time by pointing its data collection to a different marketing product destination. Owning your own data collection also allows you to send customer data to other non-marketing-suite SaaS martech products, if desired.
- Send data to the warehouse and then to martech products - If you have your own data collection, another option is to send data directly to the cloud data warehouse instead of to the marketing suite or other SaaS martech products. As mentioned earlier, cloud data warehouses often have the most data, enabling better customer identity resolution and a more comprehensive customer audiences. Therefore, if you send customer data to the warehouse first, you can then use Reverse-ETL to send customer data to the marketing suite or other martech products. As I explained in this post, one of the key benefits of routing customer data through the warehouse is that you can enrich it and send better, more complete data to downstream marketing tools. The warehouse contains metrics such as customer lifetime value and product inventory levels that are simply not available to any JavaScript or SDK event collector. With this approach, marketing suite vendor products become simply tools for activation, such as digital analytics and email delivery. In the example of Fortune 500 Inc., if all of its data, identity resolution, and customer audiences reside in the warehouse, it is in a much better position when it comes time for the Adobe contract renewal. If it finds a marketing product from another vendor that competes with an Adobe product in the suite, it can easily switch to that product. If Adobe pushes them to migrate to AEP, AJO, CJA, and RT-CDP, Fortune 500 Inc. can easily turn to other martech vendors with minimal effort. And if Adobe decides to sunset any of its products, Fortune 500 Inc. can easily switch to other martech products. In addition, with this approach, Fortune 500 Inc. could also Reverse-ETL its customer data to virtually any martech product. Therefore, Fortune 500 Inc. can now look for the best-in-class vendors in each area where it currently uses an Adobe marketing suite product. For example, it may feel that Adobe Analytics is their favorite digital analytics product, so they keep that, but they decide to use Braze as their ESP, Hightouch as their CDP, and Optimizely as their experimentation tool. The best part is that anytime a newer, better martech product ever comes along, it’s easy to swap one for another.
- Go fully composable, don’t send any data - If Fortune 500 Inc. wants to be super independent, it can start replacing its marketing suite with warehouse-native (Composable) martech products that work directly from the cloud data warehouse. There’s a growing list of Composable martech products for CDP, email, and testing that don’t require you to send them any data, but instead leverage the existing customer data in the warehouse. Composable products are often less expensive, have fewer privacy and security risks, and don’t require data to be sent back and forth between systems. A fully Composable architecture is the pinnacle of martech flexibility!
Wrapping Up
Phew! That was a lot! I recognize that this can be confusing, but the ownership of your martech stack is an important topic. As mentioned above, there’s nothing wrong with going all in on a marketing suite. But doing so definitely has potential downsides, such as vendor lock-in, dependence on the vendor for innovation, and the risk of higher pricing and new product versions. The options above offer varying ways to create layers of abstraction between you and your marketing suite vendor. Even if you believe you’ll stay with your marketing suite vendor for the foreseeable future, many of the tips above can offer greater flexibility and leverage.
At the end of the day, if you worked for Fortune 500 Inc., would you rather be using marketing suite tags for data collection, sending all customer data only to marketing suite products, with no data backup in a cloud warehouse, or would you rather be using your own data collection, send data to a cloud warehouse you own, and then route that data to the marketing suite, knowing that you could re-route it at any time? Which of these options puts you in the driver’s seat? Which option would give you more leverage at the time of renewal? Which would help you sleep better at night if the marketing suite announced product sunsets or that new versions were more expensive?
I see many companies wait until the last minute to take control of their martech stack, but the time to do it is when you don’t have to, so you can do it on your timeline, not on your marketing suite vendor’s timeline…
If you'd like to hear a podcast episode about Marketing Suite Fatigue, you can find links to it here.
