Data Cloud Architecture for Advertising/Marketing
The Data Cloud Architecture (DCA) was introduced recently — before reading this post, I highly recommend reading about that here.
The most important concept that the DCA promotes is to align IT projects with business objectives. Data being siloed ultimately comes from teams being siloed and not collaborating. IT and Data teams are also sometimes too preoccupied with their tooling and delivering a “technically exceptional” data product that they end up not delivering the right solutions that the business needs.
What DCA is not about is technology. While you read about the DCA, you’ll definitely recognize some patterns that many data platforms have adopted today, but it doesn’t take an opinionated approach to what technology should be used. It’s also unbiased about specific collaboration patterns that should be implemented.
In this blog, we’ll take a look at what the DCA could mean for brands in marketing and advertising. This blog isn’t suggesting these theoretical patterns for organizations, it’s more to show practically how the DCA could be adopted by martech and adtech teams inside of brands.
Recapping the Data Cloud Architecture
As a reminder, DCA defines four key concepts that build on each other:
An asset is any digital representation, physical and/or logical, which has measurable value to the organization. An asset typically has one producer, and one or many consumers. A physical asset is something that is copied and moved to the consumer, whereas a logical asset is something that is simply referenced by the consumer. In both scenarios, the producer owns creation, distribution, and governance of the asset.
For marketing and advertising, examples of assets are raw clickstream data, a modeled Customer 360, or even machine learning models like a predictive churn score or look-a-like model.
Both consumers and producers of assets are called business entities. A business entity is a logical way to define asset ownership in an organization. There isn’t a specific way to define a business entity, as teams within brands are organized in different manners, but business entities are naturally expected to collaborate on assets within an organization.
One way to think about a business entity is to think about them as a single line of business — like marketing, or ad sales; however, these would be very high-level and abstract definitions. You can get as specific as you need — it’s all dependent on how teams work together within an organization.
Before defining business entities in the DCA, it’s easier to create a list of assets that need to be produced. One way to start that process is by collaborating with different business stakeholders to understand what they need (e.g. key metrics). Then, work backwards to define the underlying assets needed to create the business assets.
A constellation is two or more business entities that collaborate together on standards, governance, and operating procedures of particular assets. They form a formalized or informalized “asset contract” on how they collaborate on assets. In the DCA, this is called a “Trust Relationship”, but it can also be thought of as a “data contract” — remember that assets are more than just data! A business entity can be a part of many constellations, and one constellation can be formed from many business entities. An asset can also be collaborated upon as a part of multiple constellations.
A constellation example could be a set of event schemas between the marketing team, the marketing operations team, and the analytics team on marketing data and campaign metadata. As the “business” (aka the marketing team) is making the main decisions, it’s up to the marketing ops and analytics team to serve and guide the business in a manner consistent with good governance and security.
Finally, the DCA specifies that business entities and constellations be interoperable with each other — this is especially true when each chooses different technology. Businesses shouldn’t be constrained by “blessed architecture” specified by IT, but instead IT should be following the lead of the business to achieve their goals while also coaching the business on governance and data security. This doesn’t mean you should ditch your architecture review board, it just means that during those meetings, business goals have to trump architectural perfection.
DCA Theoretical Example — Buy-Side Marketing
The following is a theoretical way that a buy-side marketing team might use the Data Cloud Architecture.
As you can see above, the Core IT team and Product teams own data assets that the marketing team needs to execute on their business objectives. Here, the marketing technology/operations team is responsible for consuming assets from both teams, as well as the data science team, to create their own Customer 360 data product, and also help the marketing team define base audiences for both acquisition and retention marketing. These assets are also used directly by partners, and then the analytics team is in charge of consuming assets from partners to define their own campaign reporting asset for the marketing team.
In this diagram, I chose to not represent the marketing team at all; however, they’re driving the entire value chain here. The core of this flow centers around marketing tech/ops acting on behalf of the marketing team’s interests in both consuming and producing assets — without that, much of this falls apart.
I also chose not to represent the constellations that are created between business entities; however, you can see how many multi-party constellations would be needed in the above diagram (e.g. MOPS+Analytics+Partner).
DCA Theoretical Example — Sell-Side Advertising
The following is another theoretical way that a sell-side advertising team might use the Data Cloud Architecture:
In this example, Core IT again owns much of the raw assets that the AdOps team needs to build their assets. The AdOps team is in turn working with the Supply-Side Platform to provide assets, but they’re also collaborating with the analytics team and bi-directionally with the advertiser as well. In this case, the advertiser (or the customer) is considered a core business entity — not only are they being sold to, but they rely on these assets for their own business as well.
Here, I also chose not to directly represent the Ad Sales team, even though they are the main business driver. The AdOps team is the main gateway and representative of the Ad Sales team as they are coordinating both consumption and creation of assets.
In both of these theoretical cases, you can (and probably should) include the business driving teams and constellations — the main reason I chose not to was to simplify the diagrams!
Conclusion
I want to highlight an important conclusion from the original DCA blog:
A good architecture supports the business’s ability to execute on business initiatives and allows IT to partner with the business delivering new capability in days, not months or years. Well architected means an architecture you can build upon, change overtime, and incrementally add capability to.
Executing new marketing campaigns/initiatives in days seems like a pipedream for most marketing teams. If you’re a marketing or advertising team that struggles to work with internal IT or data, or if you’re a data team that is struggling to prove business value, then I implore you to consider the Data Cloud Architecture approach as a way to promote collaboration with each other.
