The Best Martech Stack Is The One That Fits Your Needs

Few quests are as hopeless as trying to restore the meaning of a term whose use has changed over time. I’m not talking (for once) about Customer Data Platforms, but the idea of a “martech stack”. Originally, the term was used in the same way as tech stacks in general: “the collection of tools, frameworks, programming languages, and platforms used to build and run a web or mobile application.”  Stacks were distinguished by their components: developers might choose a LAMP stack (Linux, Apache, MySQL, PHP), a MEAN stack (MongoDB, Express, Angular, Node.js), a WIMA stack (Windows, ISS, MSSQL, ASP), etc. Each had its strengths and weaknesses, and no doubt its fanatical advocates. But, while there was a general framework that defined the types of components in any stack (broadly described as infrastructure layer, database layer, application layer, and presentation layer), there was no particular sense of one stack being "correct".

Martech stacks were originally described in the same way: as the set of tools used by a particular company for its marketing systems. Thus, for example, the Stackie Awards introduced by Scott Brinker in 2015  asked companies to illustrate the tools that they used, with an emphasis on creative presentation. But, more recently, the guru-sphere has been featured any number of proposals for how “the” martech stack should be defined, each slightly different but generally featuring broad data, decision, and activation layers.  The differences are mostly in how the layers are named and how they are subdivided into smaller components. Some also list products in each category, some don’t.*

It would be uselessly pedantic to try to restore “martech stack” to its original meaning. But I do think it’s worth arguing that there is no one correct martech stack design today, and never will be. As any guru will freely acknowledge, the right stack for any given company depends on its unique situation. The value of model stack designs is they offer is a list of capabilities that must be delivered to support an effective marketing operation. Everyone needs data, everyone needs decisions about how to treat customers, and everyone needs activation tools to execute those decisions. Having detailed lists of requirements within each layer is extremely useful in finding gaps in your current toolkit. 

Where the idea of one “correct” stack design causes problems is when it specifies, directly or implicitly, how delivery of those capabilities should be organized. Should all data be loaded into a single warehouse, or should it be read directly from source systems, or should there be a mix of direct access and warehouse access (including, quelle horreur, multiple warehouses)? Actual practice will nearly always end up with the mixed solution but the ideal martech stack diagram won’t hint that’s a valid alternative. The danger is that taking the diagram literally could push companies to adopt a solution that is in fact sub-optimal.

Anyone with the slightest practical experience recognizes that a simple stack diagram can’t capture the nuances of the real world. But, beyond a pro forma warning that is easily ignored, what can model stack designers do drive home the point that alternative implementations are viable?

I suggest that instead of presenting a single stack diagram, they offer several designs that illustrate different options. All would still draw on the same underlying set of required capabilities; these are the layers of the stack framework that don’t change regardless of how the stack components are organized. The diagrams would differ in how the components are connected:

• Database centric: a stack with a single data platform that feeds multiple decision and activation engines.
• Decision centric: a stack with multiple data platforms feeding a single decision engine, which feeds multiple activation engines.
• Activation centric: a stack with multiple data platforms feeding multiple decision engines, which feed a unified activation system.
• Integrated: a stack with a one system that combines data, decision and activation.
• Network: a stack with multiple data, decision, and activation engines all exchanging data and workflows. (I’m skeptical that this will work but do see some people proposing it. My take:“It’s the stack of the future, and always will be.”)

More variations are possible if the layers are divided into smaller components. The point isn’t to come up with the optimal arrangement but to find the arrangement that best fits with a particular company’s current and planned systems. Another approach, closer to the original meaning of “tech stack,” would illustrate alternatives using real products, recognizing that different products provide different sets of capabilities and often cross the boundaries between stack layers. This would make it much easier for users to identify gaps in their existing stack, which is one of the main uses for a stack diagram.

In fact, the reason I’ve been thinking about this is I’m pondering the next generation of the CDP Institute RFP Generator and Vendor Selection tool(s). As I wrote in my last post, the current tools focus almost exclusively on system features, making the implicit assumption that the architectures supporting those features are all roughly the same. Since that’s clearly no longer the case, we need to define alternative architectures and the system attributes that differentiate them, so we can collect those attributes from vendors and match them against user requirements. The scope of capabilities provided by a system is clearly one set of attributes to consider. Types of integration standards supported (specific APIs, MCP, etc.) is probably another although I’m not (yet) sure how to capture them. Compatibility with specific platforms (Salesforce, Adobe, Snowflake, etc.) may also be an option although I’ve always avoided that because the answers change so quickly. I suspect there are others, so am open to suggestion if anyone reading this has any ideas.

In any event, putting my personal needs aside, I think we'd all benefit from an industry discussion that focuses less on creating the perfect martech stack diagram and more on how users can build the stack that best fits their needs. 

___________________________________________________________________________

* Conveniently illustrating my point, the Stackie competition itself ended in 2025. It was replaced with a State of Your Stack Survey that seeks to “benchmark” common stack components rather than illustrate individual stacks. QED. 

System Selection Isn't About Features Anymore

I recently explored rebuilding the CDP Institute’s venerable RFP Generator with a vibe coding platform. The project was a success – Replit* took about one hour** to build and deploy an attractive, bug-free system that is significantly more capable than the original.***

But looking closely at the RFP Generator – which has been running with virtually no maintenance for six years – also raised the obvious question of how it should be updated. The current focus of the system is features: users specify their target use cases and the system returns a list of the features those cases require; it then suggests vendors based on how many of those features the vendors provide. That made sense when most systems were largely self-contained bundles of capabilities. Features were the main differentiators and collecting information on each system’s features was the main task of a vendor selection project. Even hands-on evaluation tools like pilot projects and bake-offs, which have to some extent replaced or at least supplemented the traditional Request for Proposal, are still largely aimed at understanding system features more clearly.

But systems today are anything but self-contained. They are components of a larger architecture, more-or-less-fluidly exchanging data and participating in workflows that span different systems, departments and even companies. Any new software has to fit into this larger ecosystem.  

This shifts the focus of the purchase process to integration and compatibility. Understanding those is important because different systems are built to play different roles: some are designed to be a company’s primary platform (such as a data warehouse or marketing suite), some are designed to supplement a specific other platform (such as applications on a vendor’s app exchange or an optional module in a platform system), and still others are designed to work with any system that supports the same integration methods.

This means that delivering the right features is no longer enough. Systems must deliver the right features in a way that fits with the company’s larger system architecture. Compatibility with that architecture is the first screen that must be applied to any potential vendor list. In fact, since new tools often make it practical for users to add their own features to a purchased system, finding exactly the right set of features is considerably less important than it used to be.

The CDP Institute’s existing tools already accommodate this change to some extent. We capture whether a particular CDP works with its own database or connects to an external warehouse, which is one of the key architectural differentiators. We also ask whether a system can be installed on-premises, which is an important consideration for some buyers. The vendor selection portion of the new RFP Generator allows users to filter systems on those options. But we could surely do more to understand the different architectural options and the markers that indicate which systems are compatible with which options, and to collect and expose that information.

It's also important to recognize that new architectural options will continue to emerge. The AI-powered transformation of marketing technology is still in that early stage where the industry is trying many alternatives before settling on a standard approach. (Or several standards.) Once the industry coalesces around a few standards, it will be much easier for buyers to identify systems that match their company standard.  But it will be at least several years before the winners are clear.  This means buyers will struggle for some time to figure out which systems are compatible with their company's chosen approach.

Of course, technology isn’t the only factor that matters when selecting a system. Pricing, industry experience, professional services, typical client size, and local presence are all important considerations. The CDP Institute already captures those in its vendor data and the old RFP Generator already asks the user about them. But it would be helpful to find a way to identify some of the less concrete variables, such as cultural fit, ease of use, and skill requirements.

Ideally, a vendor selection tool would also include a user readiness assessment, to help buyers understand what types of systems are best for them, what kinds of problems they are likely to face, and maybe even what they should do avoid those problems. This is important because -- as I’ve pointed out many times in the past -- by far the most common causes of failure with new systems lie within the purchasing organization, not in the systems themselves.****

In short, finding the right system today is less about finding features and more about architectural and organizational fit. The buying process needs to adjust.  Vendor selection tools should – and I’m confident will – adjust along with it.

_______________________________________________________________________ 

* Lovable also worked very well. Botpress, not so much.

** This was after I spent a day and half prepping the data and writing detailed design instructions. It would have taken much longer if I wasn’t working with materials already assembled for the old system. Still, it would have a taken a conventional developer weeks if not months to deliver a system after they were handed those inputs. Replit cost me $20 in processing credits; conventional developer costs would surely have been in the thousands.

*** You’ll have to trust me that the system is ready to go. There’s no point to releasing it until we make additional changes in the data collected. The same goes for our Vendor Comparison report, which uses the same vendor information as the RFP Generator. Replit built an interactive version of that in just a few minutes. Woot!

****The CDP Institute does have an existing Readiness Assessment tool, although it's limited and not connected with the RFP Generator. 

Can AI Break the Hype Cycle?

Generative AI and its agentic offspring may be foundational technologies, but they are still following the normal technology hype cycle: excitement at the potential, followed by news of failed deployments, followed by a more mature understanding of what’s required for success. The third stage generally comes down to a realization that the main obstacles are organizational, not technical: projects fail due to poor internal alignment, change management, reward systems, and so on. Similarly, when it comes to customer data (and all other business data), there’s a dawning recognition that whether the data resides in a CDP, cloud warehouse, or marketing platform, the real challenge is still transforming raw data into usable information through quality management, unification, and mapping. 

We’re just beginning to see the third-stage insights from the industry’s more advanced thinkers. It's true that they’re important: the only way people will be convinced to address these issues is by seeing real data and hearing about actual experience. But they are also utterly predictable. 

What’s less predictable is that AI has the potential to remove those barriers. If AI radically changes how work gets done, then the organizational structures designed for existing business processes (and blocking progress) will change as well. For data, AI could – at least in theory – handle preparation tasks that have always been the main roadblocks to deployment. 

These are not subtle ideas and I don’t consider them particularly brilliant insights. But I also don’t see them being discussed (at least explicitly). Instead, most of the AI conversation is still about using AI to replace individual tasks within existing workflows or about creating AI-based workflows within existing organizational structures. What I’m suggesting is a clearer focus on using AI to remove the traditional roadblocks to technology deployment: in addition to redesigning organizations around AI capabilities (with a particular focus on accommodating future change), this might also mean developing AI coaches to help existing organizations with change management. For data management, it means developing AI tools to automate end-to-end data preparation. 

I will somewhat airily leave the details to people who make their living helping organizations with technology management; they will no doubt have many more and better ideas than I can offer here. My goal is simply to convince them to adopt roadblock removal as a conscious objective in their work. This is what will empower AI to deliver the fundamental changes that we all see as its potential.

What Comes After the Composable CDP?

For a bunch of smart people, the technology community can be awfully slow learners. One mistake they keep repeating is believing that the latest technology is a “silver bullet” that solves all problems. This despite years of experience finding that (a) no technology solves all problems and (b) every new technology is eventually replaced by something else.

The Customer Data Platform industry is as prone to these errors as everyone else. The current silver bullet is composability, which is touted as the ultimate solution to problems of CDP cost and complexity. Just hearing the claim should lead anyone to realize it’s not true: composability solves some problems in some situations (i.e., unnecessary data movement at firms with sophisticated technical resources) but it won’t help companies that lack the necessary data infrastructure or staff resources. I suspect that even the most ardent composable enthusiasts would agree with this more nuanced view if you pinned them to a wall.

It's a step in the right direction to move past “composability is great” to discussing “when composability is the best solution.” But it’s also important to address the second flaw in the “silver bullet” fantasy, which is to assume that the best current technology is the best future technology. In other words, it’s worth asking, what comes next?

Remember, composability isn’t a solution: it’s an architecture. The fundamental argument for composable CDPs is that it’s better to have an architecture that uses the enterprise data warehouse as the primary store for customer data, rather than an architecture where customer data is assembled, stored and accessed in a separate CDP database. So the question about what’s next is really a question of what other architectures are possible.

I can think of two candidates.

• Read customer data directly from the source systems, without assembling it in any persistent database (i.e., neither a data warehouse nor a CDP). This vision of real-time, on-demand customer profile assembly is what many people thought a CDP should be back in the early days of the industry. At that time, ten to fifteen years ago, the existing technology simply couldn’t make it work. Many source systems didn’t allow real-time access, internal networks couldn’t handle the volume, and the processing costs to assemble profiles in real-time were too high. The problem pre-dates CDPs, of course: the need to make data accessible by pulling it from source systems into a separate database is why data warehouses were first created in the 1980s. There has certainly been progress in recent years, although I can’t say that the necessary technology is fully available. Still, the scope of what can be done in real time continues to expand, which diminishes the share of data that must be assembled in a warehouse. This, in turn, diminishes the relevance of the warehouse-centric composable architecture.

• Create customer digital twins. I’m highly skeptical that AI can accurately mimic customer behavior: this seems most likely to reinforce mediocrity by failing to predict unexpected behaviors (the most interesting kind) or reactions to novel situations (which includes the most important  innovations). But I can still imagine creating a digital twin for each customer, updated in real time with data captured across all company systems. The twins would be self-contained objects (or maybe agents) that can be queried any time a company system wants to find the best action for a particular customer in a given situation. While their role might resemble the customer profiles assembled in today’s data warehouses, I’m sure the technology will be quite different. I can't predict the specifics of that technology but am sure that clever people somewhere are already working on it. My only point here is that, again, the architecture won’t look like the warehouse-based composable CDP.

There are surely other possibilities that haven’t occurred to me. In fact, I’d offer better than 50/50 odds that the next CDP silver bullet will be something I haven’t listed. Placing the right bet matters a lot to investors and developers but not so much to users, who can wait to see what becomes available. 

What does matter to users is identifying their requirements.  This is something that debates about architecture only distract them from doing. So my fundamental recommendation is that CDP users think less about chasing the silver bullet and more about building the golden record – that is, how to create the accurate, unified, accessible customer data that a CDP using any architecture is intended to provide.

Fitting Agents into the Sales and Marketing Mix

Much has been written recently about how marketing and sales processes change when human buyers and sellers are replaced by buyer and seller agents: abbreviated, inevitably, as “A2A” marketing. It’s a fascinating topic but just one model that will coexist in the near future with human (or, more precisely, non-agentic) buyers interacting with agentic sellers, agentic buyers interacting with human sellers, and, lest we forget, humans interacting with humans. Any consultant will immediately recognize that this cries out for a 2x2 matrix, or perhaps a pair of 2x2 matrices if you want to distinguish business marketing from consumer marketing. For the moment, let’s stick with the single matrix model:

It’s worth making these admittedly-obvious distinctions because each situation raises separate issues, which are otherwise easily jumbled into a confusing heap. Let’s look at each situation in turn.

Human to Human (H2H)

Beyond the literal situation of one seller talking to one buyer, I’d argue this also includes humans interacting with traditional broadcast media, web search, and even non-agent websites. The common thread is that the human buyer does most of the work of asking questions and processing answers. The seller is largely reactive, although there are some situations where she makes choices such as selecting a personalized “next best action”, embedding dynamic content in a website, and setting up conventional search engine optimization. Those choices may be informed by predictive models or some other type of AI, but every step in the workflow is ultimately managed by humans, not agents.

I can’t point to specific data but am pretty sure that H2H interactions still account for the vast majority of today’s sales and marketing activity. This means that marketing and sales teams should still give significant amounts of attention to improving them, even though agentic interactions are vastly more fun to think about. If you absolutely must bring AI and agents into the picture, you can use them behind the scenes to speed up workflows, optimize performance, and analyze results.

Agentic Buyers to Human Sellers (A2H)

This is probably the situation that gets the most attention today. It includes true “buyer agents” (controlled directly by buyers) and “buyer-supporting” agents such as AI search engines and browsers. I call these “buyer-supporting” because they’re not controlled by the buyer, but instead by a company like OpenAI or Google which provides them to buyers at little or no cost.

The distinction matters because companies that offer “buyer-supporting” agents have their own agendas, which don’t necessarily align with the interests of actual buyers. In particular, these companies are increasingly interested in monetizing their products by serving ads within AI search and browser results. Some of these ads will be clearly labeled while others may be subtly embedded in the results themselves. These ads are an opportunity for marketers but may be problematic for users, who could be led to question the objectivity of the AI results.

Concern about biased AI search results could in turn lead to significant interest in true “buyer agents” that consumers pay for themselves. History suggests this will be an uphill battle: as we’ve seen with streaming video, large majorities of consumers typically chose free, ad-supported services over paid, ad-free subscriptions. Still, as streaming video has also shown, a significant fraction of consumers will pay for subscriptions in return for a better experience. This could be a large enough market to support a profitable business. Business buyers are even more likely to purchase agent subscriptions, since they don’t pay with their own money and can easily justify the expense based on better quality results. The precedent here is ad-supported versions of office productivity apps, which have never been broadly successful. There’s a chance that agents could be funded by charging advertisers for access to their owners, although such models have also failed in the past.

Advertising aside, most A2H discussions in martech and adtech circles focus on how sellers can adapt their systems to get the best results from buyer-side agents. This often involves advice on optimizing website design to accommodate search and browser agents, so a given brand receives the best possible treatment. Traditional SEO vendors are frantically expanding their products to meet this need and new AEO (AI Engine Optimization) specialists are also appearing. So far, the solutions are pretty basic: systems run sample queries to measure how often a given brand is mentioned in AI search results and vendors offer design tips to expose the kinds of data that AI agents are looking for. The next level is to look beyond measuring and influencing whether the brand is presented, to how it’s presented in terms of positioning and value. We’ll surely see more of that.

The thing to remember about “buyer-supporting” AI search and browser agents is they are generally driven by a big LLM model that draws from the same information for all users. True “buyer agents” would supplement the more-or-less static LLM models with custom research that visits seller websites to find answers to buyers’ specific questions. For example, one buyer might be interested in pricing details while another cares more about product quality. Beyond exposing all possible information, a seller might aim to present its product differently depending on what appear to be the buyer’s priorities. This is largely similar to today’s (non-agentic) website personalization. What’s more intriguing is the possibility that sellers can find a way to identify individual buyers’ agents over time, perhaps by requiring registration in exchange for detailed information. This would let the seller build a buyer profile and tailor responses to this profile. Piercing the buyer agents’ veil of anonymity would be hugely valuable.

There is a third situation: where the “H” in “A2H” is an actual human, not a non-agentic system. One current example is humans responding to agent-generated Requests for Proposals, which will likely be joined by other formats such as email inquiries or even telephone surveys. The growing volume of agent-generated requests is already a nightmare for business sellers faced with the cost of responding to them. The obvious solution is to let seller agents respond to the buyer agents, but it may be a while before most firms can deploy this capability. In the interim, sellers will be increasingly pressed to qualify buyers before deciding how to respond. Insofar as responding to qualification questions requires effort by the buyer, this imposes a cost on the buyer that should help to eliminate frivolous requests. At some point it might make sense for sellers to impose a literal cost – that is, to charge a fee – for responding to agent-generated sales queries. A less obvious concern is that buyers who rely on agent-generated research questions may fail to understand their true needs, removing a substantial portion of the value gained from a good purchasing project.

Human Buyers to Agentic Sellers (H2A)

Traditional websites may use AI-driven personalization but they are still non-agentic systems. In the future, we can expect true agentic interactions to become increasingly common. The best current example would be chat interfaces connected to an agentic back-end, enabling them to engage in true conversations with potential buyers. These have already evolved in some situations to full-scale agentic business development reps (who send those those super-annoying emails complementing your latest blog post and asking for an appointment) and sales reps (engaging in lengthy dialogs).  Agentic customer support reps are even more common and, often, better than humans at many tasks. While the distinction between AI-based and agent-based interactions can be vague, it’s fair to say that agentic interactions will be significantly more responsive to individual situations. This, in turn, makes them more reliant on capturing real-time data, both for customer behaviors and surrounding context.

Letting autonomous agents interact directly with customers raises major concerns about governance, output quality, and risk. These are widely recognized, as are the challenges of integrating agent-based systems with existing infrastructure. That being the case, I won’t rehash them here, apart from noting that they currently present substantial barriers to adoption of H2A models.

Agentic Buyers to Agentic Sellers (A2A)

Agents selling to other agents is the obvious endpoint of agentic adoption. It’s appealing if only for the amusing prospect of agents merrily jabbering with each other without any human involvement. But apart from a few highly structured interactions, such as programmatic advertising, it’s still largely in the future. A2A can’t become more common until the industry first solves the separate challenges of agentic buyers and agentic sellers. It must then overcome the additional challenges of connecting the two. Once the plumbing issues are addressed, there will be another level of adoption as buyers and sellers work to turn the interactions to their advantage. How will price negotiations work when buyers want the lowest price possible and sellers want the highest price? How will sellers discover the actual needs of buyers so they can make the best recommendations – and is what’s best for the seller necessarily what’s best for the buyer? How will seller agents decide which information to offer and which to exclude? How will agents build trust with each other? And how will companies manage the computing costs of agent-to-agent interactions, which could be substantial if the interactions are extensive?

Plenty of smart people are surely working through these issues. We already see some technical foundations being laid in protocols such as MCP and Google’s A2A. But it’s probably too soon for most marketers to put much energy into worrying about A2A deployment. Mastering the intermediate steps of A2H and H2A should come first and will put them in a better position to deal with A2A when the time is right.

Summary

The impact of AI in general, and agentic AI in particular, is overwhelming. While this piece offers some ideas and makes some prediction, my real goal is much simpler: to suggest that distinguishing the different types of human and agent interactions is a way to split the topic into smaller, more tractable pieces. I hope that helps.

Let's Debate CDP Functions, Not Definitions

What’s the definition of a CDP? It's a bad question because it diverts attention from what really matters: What capabilities do CDP users need? Still, buyers keep asking and sellers keep answering, typically in ways that promote their own interests. Looking for an unbiased perspective on the topic, I recently asked ChatGPT what answers it was finding. It came back with a reasonable cluster of responses and particularly interesting details on who was using each one (see below for the full response)*:

• Unified customer database: 70–90% of analyst pages, trade articles and vendor docs 
• Marketing activation / audience building platform: 60–85% of vendor docs, blogs and many press releases  
• Real-time/streaming profile & interaction engine: 30–60% depending on whether the source is vendor marketing (more likely) or neutral analyst articles (less likely to require “real-time”). 
• Privacy, governance & identity management layer: 15–35%, increasingly present in analyst pieces and vendor positioning  
• Part of a larger ‘data cloud’ or enterprise data stack: 10–30%, especially in vendor/marketing copy from big cloud vendors

These are categories that ChatGPT identified without me defining them in advance.  So it's particularly interesting that there’s no mention of composability, warehouse-centricity, no-copy, hybrid, embedded, integrated, stand-alone, or other architectural details that have dominated recent industry discussions. In a way, this represents a failure by the CDP Institute to propagate our view that a CDP must build a separate database of its own. But a less parochial response is to be pleased that the main distinctions reflect system functions, which is where the focus belongs.

Of course, the variety of definitions is still problematic. While it’s usually safe to assume that a system labeled as a CDP will provide a unified customer database, it’s less certain that it will also offer marketing activation and downright dicey as to whether it will offer real-time streaming profiles and interactions. This means the label provides little useful guidance: imagine a can of soup labelled “contains tomatoes and maybe chicken and could also have mushrooms, rice or shrimp”. The only way to know what's inside would be to open it -- which defeats the purpose of a label.  

(And, yes, the problem is worse for CDP than other categories. When I ran the same prompt for the term "customer relationship management software," a single answer dominated: 71% defined CRM as “a software/system/platform to manage customer interactions and data.”  The next highest share was just 29% for “integrated suite (sales, marketing, service automation)”. It’s true that the dominant answer is exceptionally broad, but at least most people understand this and won’t expect anything more specific.)

So, although industry understanding has not been entirely destroyed by architectural debates, there is still enough disagreement on the scope of a CDP to limit the term’s utility. (If the CRM example is typical, it may be a natural progression for popular categories to expand their meaning over time. That would be an interesting hypothesis to explore if anyone out there is looking for a thesis topic.)

The industry could fight to restore a more specific CDP definition, but that’s probably a losing battle. It’s more likely productive to shift the discussion away from defining the term "CDP" to defining the functions required to manage customer data. 

Yes, I’m proposing that the solution to our problem is a checklist. Don’t roll your eyes: whole books  have been written on the topic. (Ok, maybe just one book.)  But in an industry that has long been driven more by theory than practical requirements, anything that gets buyers to focus on what they actually need is a win.  

Getting the industry to agree on a shared requirements checklist wouldn’t be easy, since every participant would want to add or remove items depending on whether their products supports them. Indeed, the very notion of a comprehensive requirements list favors broad, integrated products over narrow point solutions. But I’d still invest a few embers of hope in a project to forge a complete customer data framework. The potential benefits, for users and vendors alike, are well worth the effort.

Why Agentic Campaigns Are Not The Future of Marketing

My last post, presenting ChatGPT’s description of AI-based marketing, generated thought-provoking comments on LinkedIn. Key insights included:   

• Organization issues as roadblocks to successful deployment (Chris Adelman and Lee Hammond)
• Buyer agents as increasing the importance of trusted information sources (Jon Miller, Dan Cote)
• Some vendors are already delivering end-to-end agentic campaigns (Matthew Niederberger, Duarte Garrido)
  

Thanks to everyone who contributed.

What I didn’t see was push-back against the vision that ChatGPT presented. Maybe people were being polite or maybe they fear that ChatGPT could hold a grudge. But my own initial take was triggered by words including “narrative” and “journey”. These led me to think that ChatGPT was still describing today's standard of multi-step marketing campaigns applied to customer segments. On closer examination, the story is a bit more complicated: the various components included in ChatGPT’s list are not necessarily a consistent whole, but rather a collection of predictions that ChatGPT has gathered by scraping of industry discussions. Oddly enough, ChatGPT's summary provides a clearer statement of an alternative approach:

AI-native marketing is:

• Continuous (not campaign-based)
• Conversational (not broadcast)
• Collaborative (AI agents on both sides)
• Generative (creating narratives, products, and experiences dynamically)
• Ethically-audited and explainable (trust is as important as persuasion)

Of course, that ChatGPT says something is no guarantee that it’s correct. So, although I intuitively agree with the prediction, I still need to convince myself (and, hopefully, others) that it’s right. One test is to compare the prediction with cutting-edge industry developments. Here’s a list of trends I’ve been tracking:

• Agentic search: AI-generated summaries replace traditional, link-based search results
• Ads in chat replies: Chat responses include paid advertising, identified with varying degrees of transparency
• Social commerce (a.k.a."live shopping"): Make purchases of items featured in social media discussions without leaving the social media platform
• Commerce via agentic browsers: Advertising and shopping links presented by browsers based on what they see the user doing (a privacy nightmare but we'll ignore that for now)
• Interactive ads: Advertisements that link to a conversational interface rather than conventional landing pages or websites
• Buyer agents: AI agents that do product research and, perhaps, make purchases on behalf of users without users visiting seller websites
• Conversational websites: websites that present chat-style interactions or hyper-personalized contents in dialog with the user

All but the last of these occur at the discovery stage of the buyer cycle. That's encouraging because marketers have been very concerned about they reach new customers when traditional search no longer drives traffic to their websites and consumers increasingly ignore traditional email and display messages. But what's really important is that these items all change the role of marketing from creating campaigns that broadcast messages to consumers, to executing continuous conversations with consumers. This is indeed what ChatGPT described. It’s not something that is accomplished by using AI generate conventional broadcast campaigns.

In fact, I’d argue that the current broadcast campaign model developed precisely because the then-existing technology couldn’t handle a conversational approach. Branching campaigns with personalized content nodes were the best that could be done when marketers were limited to deterministic, manually-crafted workflows. If you recall the once-popular cliché of marketing automation as a way to replicate the personal relationship of customers to their “corner grocer,” you quickly realize the real-life grocer had conversations, not campaigns.

Think a bit deeper and you see that the reason the grocer was able to have conversations was data. He knew the history of each customer and was able to discern their current situation by seeing and talking to them. Multi-step marketing funnels exist because marketers don’t have that kind of information available in real time. Instead, they have to make a guess at where each customer might be in the buying cycle. The funnel is a framework for making those guesses. Provide real information and it’s no longer needed.

I think this is important. Marketers, vendors and analysts have focused largely on how AI can reduce the cost and time of generating marketing campaigns. This allows companies to create near-infinite amounts of personalized content. But unless that content is driven by near-complete, real-time data, there’s a severe limit to how relevant it can be. Data, not content creation, is what ultimately limits the effectiveness of AI marketing.

This may strike you as bad news. Data has always been a problem for marketers, and real-time data is a particular challenge. Agentic campaign creation won’t solve the data problem, although perhaps it will highlight data's role as a bottleneck. The good news is that other AI and agent applications can in fact improve data access, something that data management vendors are already pursuing. 

It’s true that better data management isn’t as exciting, or directly tied to revenue, as better customer engagement tools. This is probably why most vendors focus on adding engagement features. But as autonomous engagement become increasingly common, the need for better data will become more obvious. Vendors who use AI to deliver better data (and convince the market that they are leaders in doing it) will have an increasing advantage in growing their business.

I’ll give the final word to Abhi Yadav of iCustomer, one of those very smart people who see further, sooner than most of us. He recently shared a substack post that captures my opinion quite eloquently:

We used to drag customers to our properties (site, app, landing pages). Now we take capabilities to where customers already live: agent/app ecosystems, workflow-native GPTs, and search/ad surfaces that embed decisions at the edge. ... If your data stays scattered and your channels siloed while this shift accelerates, AI won’t transform your business it’ll just perform visual eye candy. AI should drive a paradigm shift in your business, not a party trick.