Over the last decade, we’ve had the privilege of installing hundreds of analytic systems for marketing and advertising for companies, in nearly every industry, all over the world. We’ve done it all: Web, Mobile, BI, AI, and even invented quite a few products along the way.
These installations were most often built around some formal requirements from a marketing department or through the IT teams who needed a system of record for their sales, spend, downloads etc. Needless to say, there was quite a bit of diversity in purpose, and so it follows there was a similar diversity in arrangements. What we’re about to describe is one of the most frustrating and agonizing set of circumstances why it will still likely be years before there is broad, functional, and valuable adoption of integrated ‘Artificial Intelligence’ into how corporations leverage and activate ‘marketing data’: Governance.
The main issue is that the talk and sales cycle of marketing is far more aggressive than the budget which perceives that it is valuable. If you’re in this industry, you have probably seen the ‘Martech Landscape’ by Scott Brinker. The amount of technologies it illustrates that are available to plug into corporate marketing infrastructure of all sizes and shapes has accelerated a land-grab which has been invisible to most people. To me, the clutter there looks like a terrifying bubble. This is by the simple fact it doesn’t appear to have borders…I digress…
So how does this affect governance?
All of this really comes down to something really simple, governance is the ability to set down how data has relationships with the efforts of multiple teams around the business strategy for the purpose of alignment, accountability, and adaptability. It is the establishment of ‘Entities‘, or objects, and how they are described and how those objects interface with your business at any moment in time to produce current and/or future value. These can be concrete, like ‘users’ or ‘customers’, even ‘devices’, or they can be abstract, like a VisitorID hashed from a User-Agent string and IP Address. (In more secure cases, outside of marketing, these are multiple systems of abstraction and encryption used to represent grant rights to a resource of a request for a certain amount of time or instances in an application or software). Anyway, the point is that these are necessary concepts to be able to work across a business which is app software, web application, storefront and so on, as well as tie into a tangible product in ‘real life’; …and, importantly, it is also more akin to how EAV or RDB systems construct views for interfacing or interoperability. (aside: This, ‘interoperability’ is the key to literally ANY potentially valuable data science project, machine learning as a service paradigm, and certainly expedites digest for any map:reduce based network query node.)
Where the trouble hits, is that those systems being sold into marketing departments and applications of all kinds are sold without ever really conforming to any standard. Here is where folks usually talk about the ‘Data Layer’ and reference how ‘Tag Management’ solves this. While there’s some credence to that, the cases of successful, or even moderately well integrated are few and very far between. Worse, infighting and politics make these near impossible to agree upon for any marketing team. So, in more cases than we care to quantify, our goals and client duty must be focused on a more atomic integration of marketing technology. (Answering the request: make it do the thing the technology needs to make sure their system works and shows up in reports)
So, the problem is that an average multi-channel marketing ecosystem in an enterprise corporation might include 15, or even up to 35-40 different marketing/advertising technologies. We’ve had some pretty complex systems supported by global teams with disparity by country or line of business…so we’ve seen it get hairy. Each one of those will have an owner, a cost, a functionality, and a set of data items which are attributed to the ‘entity’ which they target.
To make things a little more accessible: An example might be a ‘customer’ targeting software which collects items you left in your shopping cart. This software requires a Customer ID, a shopping cart instance, and some data structure to capture the items and descriptors to get the whole picture of the value which was abandoned. Here is where things start to break apart (that didn’t take long, did it):
- The script provided by the vendor might easily mesh with whatever the platform describes as these values (ATG, Magento, and Shopify all have pretty solid structures for this in the DOM)…but the requirement might need to be encapsulated within a TMS system.
- The values which the vendor expects at their endpoint for the HTTP relay of that data might operate on some server API digest which needs uniqueness in the user key which matches their ‘entity’ for a user. Selections here might be a user email (dear god), a cookie id, a generated standard identifier on the backend, a client id….anything.
- …this is ok, but there has to be ‘Continua’ and alignment in all these systems which will leverage the feedback for some activity in the operationalization stages for the data.
- Products in the shopping cart, entities in their own right, will have a whole set of identifiers (SKU, StyleID, ProductID, ProductName). Some systems record these by uniqueness, as an index, others do different things to produce a point of access or query on the key, whatever is decided.
- if the POS system recognizes sales on one key, but the web order system uses another, and finally the vendor asks for something neither respect or map to, there is a good chance no functional implementation can really ever report value correctly.
- TMS systems create another layer of abstraction here because generally they have a meta layer, or a ‘Data Layer’ that’s meant to make interchange agnostic.
- again a point where the ‘simplistic’ sell has created a disconnect between what is functional, and what is valuable and what can be scaled in an inherently complex ecosystem.
Therefore, the problem here isn’t that the technology isn’t valuable, it’s that the proper implementation isn’t just immediately going to be clear and that very careful hands, with technical consideration behind them, need to operate on the data points. A marketing technology system that can operate on ‘omnichannel’ or ‘multi-channel’ strategies needs a particular amount of planning and a slow and gradual adoption of keys and objects to make sure there is parity in function and reporting in each of the main components. The will of companies to temper their adoption cycle and commitment to the stable growth of the ecosystem has not been responsible.
Now we come to the part where we have to try to ram AI and Machine Learning into this mess. With most enterprise mutli-channel implementations being around 2-4 years old on their current lifecycle, and with the diversification of devices, browsers and privacy settings; a functional installation of a series of processing nodes built upon the outputs of those systems to power AI decision support is likely to fail or cost far more than the value it would produce for a large number of companies who consider themselves ‘candidates’. Most of that failure can be ascribed to the possibility that the first ordinary layers of governance needed to ensure accuracy of the assignment of data to key based entities has not been constructed in a way that intricate neural networks and decision trees can reliably interpret and communicate outcomes or directives.
What is left is that, while possible, most marketing technology based strategic implementation of AI and machine learning will be based on an improper understanding the complexity and a need or will to keep up with competition who were able to pull off a fringe case on an insight which could be exploited more quickly. On the discussion circuit and the book tour for the next couple years, you’ll hear about these. Travel companies will be able to make gains there, online retail (offline retail too: see Gary Angel’s Digital Mortar)
The same is true, by the way for ACTUAL data science work. If the requirements weren’t built 2-4 years ago expecting to integrate complex query systems, large (like vastly large GB/TB/PB style) query sets, and access endpoints with a responsible turnaround time; you’re in a spot now where taking a few months to look at your architecture and its original requirements need to be projected onto the martech adoption path and see if some mitigation is needed.
On the upside, if you ARE planning or feel like there’s an opportunity to leverage a true AI program for your company, let us take a look and help you find the place to start. We can see how these systems integrate across the whole spectrum of stack configurations and have the experience to know when you’re going to hit a wall. We can help you tune up your marketing technology engine and help you get up the curve…then we can help you find the right decision technology to integrate into your stable, budget sensitive, investment into the next generation.