What I've Learned from Seeing & Designing Dozens of Consumer Marketing Tech Stacks
In almost all my growth marketing and martech engagements, one of the first things I do is get a lay of the land. This usually means a few hours of accessing different tools, and asking common questions like, "how do you track your installs?", "who sends emails, and where?", and "why are these SDKs implemented?".
Inevitably, all roads lead to the creation of a marketing tech diagram. If you're from a technical background, you have probably heard of this for all common applications as an Architecture Diagram.
In short, a MarTech Architecture or Stack Diagram is simply a system map that shows you how data flows throughout your tools, and what various technical marketing capabilities are served by which vendors. It focuses on:
- Technical flow of data.
- Tools (both internal and external).
Surprisingly, none of the companies I've ever consulted for had an existing robust MarTech Architecture Diagram when I started working for them - although David Marble, formerly at Intuit, and then at Walmart, where I worked with him, did exactly this in his role there, and has produced far better and more in-depth marketing tech diagrams than me.
While I personally enjoy the process of taking apart complex systems, understanding how they work, unearthing every stone to get to the nitty gritty of why technical choices were made, not all people -- in fact, most people -- really don't enjoy this work.
The not-so-fun parts of a job in martech are often neglected, and developing a Marketing Architecture that outlives your time with a company is one of those. It slides in alongside other well known aspects of martech that are neglected, like codifying your stack into a playbook, designing processes for administrating users and updates to the stack, implementing a structure for how and when you pull and push data into and out of different point solutions, and, not choosing vendors based on subjective horse trading, but rather a capabilities-driven, systematic approach to evaluating tools.
Anyway, I created a standard martech template back in 2017 using Sketch, but over the summer this year I needed a refresh for a client. I went back to the drawing board and re-designed a new MarTech Architecture Diagram using LucidChart.
After designing it for them, I looked back and realized that almost all my clients over the years have followed some version of this marketing architecture. Below is a mishmash that I pulled from aggregating tech stacks from Jet, Walmart, Strava, Postmates, Airbnb, Sam's Club among others. I'm not endorsing any of these specific vendors or indicating that these clients specifically used these tools. Although, MightySignal could easily help you determine that for yourself. Rather, I'm showcasing the combinations I've seen so that marketers out there looking for what "great" looks like, have a place to start. I also added in some new and upcoming tools that I think are pretty exciting and will make their way into consumer tech stacks soon:
There are some specific things I'd like to call out with this template and some leanings I have had from designing different marketing stacks over the years:
Not Every Great Tool is Listed by Capability: There are lots of vendor options on here that work for people that aren't listed. I only had so much space in each vertical. In some cases, like location infrastructure, I've never worked with a client doing location based audience re-targetting that isn't using Radar, so that's why they stand out. In other cases, there's just not enough room in the box. Sorry CRM/Messaging, I know I left a few of you off.
Tools Can Be Swapped: Button, Appsflyer, Branch, Singular all provide attribution and deeplinking. For example, I've had a lot of success implementing and using Button on mobile web, but CDP integrations have been more challenging. I know they have customers using them as a standalone SDK. I tended to work with clients that approached their martech stack with a unified approach, which is probably why this overlap doesn't exist. Singular, while I've used it successfully to pull cost reporting data, is also an MMP and attribution/deeplinking vendor. I'm not endorsing specific vendors here. You should take a capabilities-driven approach when you select new tools. I'm just saying that there are lots of combinations, so don't take this diagram as the only version possible.
Naming Conventions: Marketing tools are becoming more and more competitive with one another. But they also need to play nice in certain cases where they really are complementary (Tai Rattigan was just writing a piece about how this is a sales tactic... it's also a useful component of a flexible stack). But what this means is that as tools become more competitive, their marketing becomes more creative. try to focus on the core capability of the tool, and not the marketing jargon they use to sell their tool to you.
The Future of Data Pipelines: A few years ago the central value prop of a Customer Data Platform was to centralize SDKs, provide audiences, and serve as a data pipeline. This worked well as a value prop especially because the data integrations to dozens of other marketing tools were not built. But today, that landscape has shifted, and that third value prop has been severely diminished by the fact that most major marketing tools, such as Braze, Iterable, Appsflyer, Branch, Radar among others, have built core integrations with the major tools needed. Likewise, these tools will continue to invest in the necessary integrations that their customers most often need. So what? I'm not saying CDPs are going anywhere. In fact, I recommend using one in almost every client I work with. But there are now questions evolving around the "pipeline" component of a CDP. I've seen tools like SnowPlow being used upstream to push data to various sources, and the CDP then becomes a marketing-focused consumer of the data. Likewise, when data becomes so large and hard to manage, tools like Iteratively and Avo must be put in place to wrangle schema, which then means a customer really should be tracking their analytics on their own and sending data server side to a CDP. This erodes some of the orignal value prop of CDPs, but then makes the much more focused tools
Upcoming Areas of Focus: As the market has matured, I find more and more that customers who use stacks like this are starting to deal with "enterprise" problems. As their companies have grown, their usage of unified tools has as well. This means more data flowing through the pipes, more employees using the tools, and thus in both cases, more opportunity for problems. I'm very excited about what Iteratively and AVO are doing to address this major problem in aging tech stacks.
If you're a marketer, user acquisition manager, PM or Engineer and want to create your own martech diagram for yourself, I'm selling this LucidChart template on my store here.
https://www.consulting.hbe.io/product/martech-achitecture-diagram-template-lucidchart
I hope it helps you codify your tech stack and work towards making and improving your tools!