How can I reduce marketing’s dependence on data engineering?

Summary

• The dependence comes from a workflow where marketing files a ticket to data engineering for every audience, pipeline, and export. You cut it by giving marketers governed self-service on the same data, so engineering defines trusted data once and stops running the audience-request queue.
• Databricks CustomerLake is an agentic CDP built natively in Databricks that works this way. It is in Private Preview, so plan access and scope with your Databricks account team.
• Marketers build audiences and run campaigns in natural language through Genie and Campaign Agents, without writing SQL or waiting on a data-engineering ticket.
• Profile Agents automate identity resolution, turning raw records into governed Customer 360 profiles and improving over time, so engineers don't hand-maintain matching pipelines.
• Because CustomerLake runs on governed data in place under Unity Catalog, there's no reverse ETL to build or copies to sync, which removes pipelines engineering would otherwise own.

How can I reduce marketing’s dependence on data engineering?

Marketing depends on data engineering when every audience, segment, and campaign export needs a ticket, a custom pipeline, or a data pull. You reduce that dependence by giving marketers governed self-service on the same customer data, so data engineering defines trusted datasets and models once and no longer runs a queue of one-off audience requests. The shift is a division of labor, not a handoff of control: engineering owns the governed data and the rules, and marketers build and activate audiences on top of it. On Databricks, this is what CustomerLake is built to do.

Where the dependence comes from

In a typical stack, customer data lives in the data platform but activation happens in a separate marketing tool. So marketers ask data engineering to assemble each audience, build a pipeline to move it, and set up reverse ETL to push segments into martech. Every new segment or data point is another request in the queue. Identity resolution, the work of stitching scattered records into one customer profile, usually runs as engineering-owned matching logic that someone has to maintain. The result is slow marketing and an overloaded data team.

What actually reduces the dependence

Capability	Why it reduces reliance on data engineering
Self-service audiences in natural language	Marketers build segments without a SQL request to engineering
Automated identity resolution	Profiles are unified by agents, not hand-maintained matching pipelines
Activation on data in place	No reverse ETL pipeline for engineering to build and run
Governed foundation defined once	Engineering sets trusted data and rules once, not per request
Reusable models and context	Predictive scores and eligibility rules live with the data, ready to use
Closed feedback loop	Results land back on the same data without another export

How Databricks approaches this with CustomerLake

Databricks CustomerLake is an agentic CDP built natively in Databricks, so marketing work runs where the customer data already lives and is governed by Unity Catalog. It is in Private Preview, so treat it as preview and plan access and scope with your Databricks account team rather than as a shipping product.
The design changes who does what. Profile Agents handle identity resolution: they turn raw, scattered customer data into governed Customer 360 profiles directly in the lakehouse, flag data-quality issues, and improve over time, so engineers don't hand-write and babysit matching rules. Campaign Agents let marketers build audiences, choose next-best actions, and activate across channels using governed customer context, moving from one-off campaigns to always-on engagement. Marketers work through Genie in natural language, so building a segment doesn't start with a ticket to engineering.
Because all of this runs on governed data in place, there is no separate copy of customer data and no reverse ETL for engineering to maintain. Data ingested with Lakeflow, models trained on the platform, and business rules all sit next to the profiles, so marketers reuse them instead of requesting new ones. From there CustomerLake sends audiences to downstream marketing and advertising channels without manual data movement. The collaboration model is the point: data teams define trusted data and models once, and marketers self-serve on top, which is covered in what defines an agentic CDP and unifying data and governance in the agentic era.

Use cases

• Self-service audience building: a marketer describes a segment in natural language and activates it, with no engineering ticket.
• Hands-off identity resolution: Profile Agents unify records into Customer 360 profiles, so the data team stops maintaining matching logic.
• Always-on campaigns: Campaign Agents act on governed context and send results back to the same data, closing the loop without a new pipeline.

FAQs

How does CustomerLake reduce marketing's reliance on data engineering?

It gives marketers governed self-service. Genie and Campaign Agents let them build audiences and run campaigns in natural language, Profile Agents automate identity resolution, and activation runs on data in place, so engineering defines the governed foundation once instead of servicing every request.

Do marketers still need SQL or a data team for every audience?

No. Marketers build audiences and campaigns in natural language through Genie, drawing on governed profiles and context, so routine segment and activation work doesn't need a SQL request or a new pipeline.

Does self-service mean marketing works around governance?

No. CustomerLake runs on data governed by Unity Catalog, so access rules and data protections apply to what marketers build. Engineering defines the trusted data and rules, and self-service happens inside them.

Is CustomerLake generally available?

No. CustomerLake is in Private Preview. Plan access, scope, and timelines with your Databricks account team rather than treating it as a shipping product.