Skip to main content

From Dashboards to Decisioning: How We Rebuilt Marketing

Summary

  • Databricks' marketing analytics team started with 127 Tableau dashboards all running off a single table, where the same KPI could show three different numbers, making the analytics environment unusable.
  • Consolidating marketing signals into a medallion architecture with an identity resolution layer, metric views, and AI/BI on a certified gold layer resolved data fragmentation and eliminated contradictory KPIs.
  • The rebuilt platform enabled self-service analytics for business users, AI-assisted contact persona enrichment, look-alike modeling, and a roadmap toward closed-loop AI decisioning without human approval.

From Dashboards to Decisioning: How We Rebuilt Marketing

Watch: From Dashboards to Decisioning: How We Rebuilt Marketing
Every enterprise marketing organization is trying to escape the same trap: fragmented data, backward-looking reporting, and AI pilots that never make it into daily operations. At Databricks, we decided not to layer AI on top of a broken foundation — we rebuilt the foundation first. In this video, we’ll walk through our end-to-end transformation from descriptive analytics to AI-driven insight and activation, powered entirely by the Lakehouse. We’ll show how consolidating marketing signals into a governed, scalable data architecture unlocked a new operating model: real-time intelligence accessible to non-technical marketers, AI-assisted decisioning embedded in workflows, and closed-loop activation across our CDP. We'll talk about the vision, what worked, what broke, and what changed in how marketing teams plan, execute, and measure impact.
Talk By: Alex Schnabel, Business Intelligence Manager, Databricks ; Thomas Russell, Sr. Marketing Analytics Manager, Databricks ;

Chapters

FAQs

What was wrong with Databricks' original marketing analytics setup?

The team maintained 127 Tableau dashboards all built on a single marketing data table, leading to slow, contradictory reports where the same KPI could have three different values. Delivering a single business unit deep dive took about a week of manual work to produce.

How did Databricks fix its fragmented marketing data?

The team rebuilt on a medallion architecture with an identity resolution layer, creating a certified gold layer that AI/BI and Genie Spaces could query. Metric views in a business semantic layer ensured consistent KPI definitions across all reports.

What is metric drift and how was it addressed?

Metric drift occurred when the same KPI showed different numbers across dashboards because each was built on slightly different underlying data logic. The fix was introducing metric views in a business semantic layer so every dashboard and AI query uses a single governed definition.

What results did rebuilding on the lakehouse deliver for the marketing team?

The rebuilt platform enabled faster iteration and self-service analytics for non-technical marketers. The team also deployed an AI agent for contact persona enrichment and a look-alike model, with a roadmap toward closed-loop AI decisioning that requires no human approval step.

Full transcript

[00:09] You can go ahead and get started. I'm going to flash up this uh forward-looking statement real quick. I'm sure you've been to a lot of sessions, so you've probably already seen it before. Um and as always, um after the session, if you would complete the survey right directly in the app.
[00:22] But today, I'm really excited to talk to you about from dashboard to decisions, how Databricks marketing rebuilt analytics on the lakehouse. I'm Alex Schneble. >> And I'm Thomas Russell. >> Um and we're on the marketing analytics team here at Databricks.
[00:40] So, I've been at Databricks since 2020, and imagine this, when I started, we were just a team of one, and we had 30 joins in a single query, one single marketing table, the entire data sources went through Fivetran.
[00:52] We had dashboard for days, 100 Tableau dashboards, yes, 100. I think it actually was 127, I counted, all running off of that one table. And if you wanted an analysis, you would
[01:04] have to build 15 to 20 slides from scratch, and it took about a week's worth of time just to build a single BU deep dive. Nothing could be wrong with this, right? Well, from the slacks I've gotten in the last 6 years,
[01:17] why is this dashboard so slow? Does this dashboard refresh daily? Which of these numbers is correct? Why don't the numbers align between dashboards?
[01:29] Why doesn't the number match with Salesforce? Can you do this really long nurture analysis, opened May 12, due May 14? And I think the most egregious one yet,
[01:42] can you do a full funnel analysis, open May 20, also due May 20? Clearly, this model was not sustainable. Um as you saw from the slacks, the data
[01:55] in the dashboards were fragmented. We couldn't answer basic questions. Um, dashboards contradicted each other. The same KPI could have three different numbers. Data didn't have any concept.
[02:07] Uh, AI saw columns, not concepts. And on the dashboarding side, you saw dashboards were slow. Um, they were unusable, um, due to being built on these broken data sources. There were just too many dashboards. Uh, everyone
[02:19] kept asking, "Which of these dashboards should I be using?" And people needed quick turnarounds on these analysis as you saw. Um, we had an insights bottleneck and demand outpaced the analytics team. And we were spending
[02:32] a lot of time on tasks that weren't really bringing value to the business. And I'm sure you feel it in your organization, too. How do you scale your data when company head count is out pacing the head count of your team, so
[02:45] you're required to do more with less? Um, here at Databricks, it really starts with one team. We are a unified analytics team with three roles. Um, data architects like Thomas and data
[02:57] engineers, whose job is to rebuild the data foundations. And insights and visualization analysts like myself, where we're focusing on self-service discovery and intelligence and action.
[03:09] And none of what we're going to show you tonight happened overnight. Today, Thomas is going to show you how we first rebuilt data foundation in the lakehouse, so we had clean data foundations for our visuals to sit on.
[03:21] Then how we cleaned up our dashboards in order to improve self-service. To finally where we are today in implementing intelligence in action to go from dashboards to decisions. >> All right, thank you, Alex. So, I'm
[03:34] going to walk you through our architecture, where we started, where we ended up finally, and then some of the changes we made along the way. Uh, so this is where we started. We had a fractured ecosystem. Um, the data
[03:47] ingestions that we had went into silos. The, uh, code that we used for those data ingestions was brittle. It was things that we hard-coded ourselves. And ultimately, we couldn't deliver what the
[03:59] business wanted, which right now seems very simple. They wanted to have multi-touch attribution, and they wanted to understand a customer's end-to-end journey. But we couldn't deliver those insights due to the
[04:12] siloed data that we have cuz we couldn't stitch across a given person's customer journey. So, rather than try and build on top of this poor poor design, we decided to completely rebuild. And so, this was the
[04:25] first iteration that we went through, and we went with a medallion architecture. So, you have the bronze, silver, gold. And then in the bronze layer, that's where we land all of the raw data.
[04:37] We are leveraging instead of our brittle old pipelines, we've replaced those with Lake Flow Connect, and and Delta Share where our partners support it. Then in the silver layer, we we
[04:50] transform that bronze data into larger data objects. So, think of something like all of the engagements. We have data from Marketo, we have data from the web, we have data from the ad platforms. All of those engagements get transformed
[05:02] and put into one large engagement table. And similarly, we have one large contact table that has all of our golden contact information, and we build out an identity crosswalk that lets us identify for a given individual what are all of
[05:14] the IDs they have in all of the various source systems. So, we can stitch that together. So, now we have a golden view of our contacts, and we have a golden view of all of their engagements, which allows us to stitch together their
[05:26] end-to-end customer journey, and also allows us to do that true multi-touch attribution because for any given person, we know all of the engagements that they've had and the sequence of those engagements. And then building on top of that, we
[05:38] have the gold layer. That's where we take pieces of those data objects, and we create tables that are designed for reports and genies. So, we have like one for campaign performance, one for pipeline performance, one for audience
[05:52] segmentation. Uh and then now, what that allows us to do is end-to-end what this medallion structure allows us to do is deliver insights faster. We no longer have the silos. Um and we're also able to make changes
[06:04] and iterate faster due to the new modular nature of this architecture. Um and then ultimately, what that delivers on the top is insights and activation. Um so, AI BI is now powered by this. Uh the Genie spaces are ad-hoc analytics.
[06:17] And the other benefit is with activation, uh now those activation layers are reading from the same reporting tables. So, if we go into our um segmentation dashboard, we create a new segment that has a thousand people in it. When we take that over to the
[06:31] execution platforms, they're reading from the same table. So, that same segment will have the same total um number of contacts in it. This alone didn't solve all of our problems, though. If it were, it would have been nice. Uh we still ran into some additional
[06:44] issues. Uh this is a callback to one of the um slacks Alex was showing earlier. Why do the dashboards show the same measure but with different values? Uh and the reason for that is we did have the gold layer. We did have clean
[06:56] data in the gold layer, but it was a little too broad. Um what the business cares about is their business concepts. So, they have a concept of active pipeline. They have a concept of greenfield MQLs. What's really driving
[07:09] those concepts is complex filters in SQL. So, you have a where clause with a whole bunch of different um statements. As we built out our initial architecture, we were relying on the analysts to build those concepts into the dashboards. So,
[07:22] the criteria we used for what is active pipeline, it has to be open pipeline, it has to be um stage two or greater. Uh that was being put into the dashboard itself. And different dashboards often
[07:34] times had different calculations because different analysts were building it. Um or even if it was the same calculation, the business would request a change. Change would get made in one dashboard but not the others, and we would have drift.
[07:46] Uh so to address this, um metric drift, what we did is we went to towards a um business semantic layer that's leveraging metric views. And what the metric views allow us to do
[07:58] is take that complex logic, all of those case statements, all of those where clauses, we put them into the view itself, and then the output of that is just a column. We have a column that's called active pipeline. We have a column that's called um the greenfield MQLs.
[08:13] So now when an analyst needs to create a genie, when they need to build a dashboard, they just drag that column into the dashboard. They don't have to worry about the underlying logic. Um if that logic changes, our engineering team will make that change in one location.
[08:26] They make it in the metric view, and that gets pushed automatically to all of the genies, to all of the dashboards, so everything stays in sync. Uh with the other benefit to, just to call this out, is the analysts don't
[08:38] necessarily even know need to know how it's calculated. So, is it a count or is it a count distinct? Like how is it actually measured? Or is it an average or is it a median? What should we use? That's also baked into the metric view. So the analysts just need to use the
[08:51] measure function, and they measure in whatever they're measuring, it'd be a count, a count distinct, that's all controlled at the data layer. Did that solve all of our problems? No. Um we still found one more problem, which is the true value that our
[09:04] analysts bring is not just building dashboards. We have dashboards on dashboards on dashboards. That's fine. Those dashboards show numbers. Um a number by itself is not all that meaningful. So, we have a thousand MQLs,
[09:17] we have a million dollars in pipeline. Is that good? Is that bad? Is it going up? Is it going down? Um where do we need to invest? Where do we need to divest? Like what do we need to change? Like that whole narrative around the data, building that narrative is the value our
[09:31] analysts truly bring to this data. Um it takes a long time. Building something like that it takes weeks, especially if we're doing something across the entire business. Um and our analysts can't spend that
[09:43] much time. It's It's too much. We clearly don't have the resources. Our um resources line was flat that you saw earlier. Um so we thought, let's throw AI at the problem cuz AI solves everybody's problems, right? We'll just throw AI. AI will um do all of the analysis and we
[09:56] can walk away. What we found is when we did that, uh because we lacked some fundamental context in our data, the AI would just report back what was in the dashboard. It would tell us we have 1,000 MQLs. It tells us we have a million in pipeline.
[10:08] Doesn't tell us why. Doesn't tell us what we do about it. Um so we identified that missing context was the problem, and we went into um trying to identify like where are some areas we can make it better. And one
[10:21] area we found was our contacts. We generally target our contacts based on their persona, and we look at their job title to figure out what their persona is. Are they a data architect? Are they a data engineer? Um half of our contacts
[10:34] don't have a title. So we have no idea who they are and what they're interested in because we're just missing that context completely. Um similarly with our campaign data, we have some campaign metadata. It's Initially it was very generic. It was the campaign name, the
[10:47] campaign channel, the region. Very basic information. Not a lot about how does that relate back to the business, our objectives, our OKRs. Um and so we needed to find a way to figure
[11:00] that out and also understand the content cuz we were missing the content too. So we know we sent campaign A to a person. That may be an email. What's the content of that email? We had no visibility to it. It leads uh to a call to action
[11:12] which lands them on a a web page. What's the content of that web page? We had no visibility into it. And then we couldn't stitch all of that together to identify what's working, what's not. Um so the way that we solved this is with we built
[11:24] two agents. Um one is Agent Atlas, one is Agent Tagatha. Agent Atlas will go through and um identify a customer's persona. We're now leveraging an LLM that understands
[11:36] natural language context. So, it we don't use a regex, which was just simple pattern matching. Now, we've instructed the LLMs on what makes a data scientist, what makes a data architect. And it's
[11:48] able to take whatever um job titles we have and identify contextually what persona that relates to. But, many of you astute listeners out there will know that we half of our data doesn't have a title. So, how does that
[12:00] even help? Um what the agent will do afterwards is call out to a look-alike model. And so, we've built a look-alike model behind the scenes that the agent leverages. And where we know who somebody is, we start to build patterns on
[12:12] a data architect generally behaves like this, a data analyst behaves like that. And we can use that look-alike model to identify for that 50% bucket, how are they behaving? What do they look like? Do they look like they're a CMO? Do they look like they're um a data architect?
[12:26] What are they actually interested in? And we start to build out that persona and that profile of these users. And then agent Tagatha will go out and identify contextual tags for all of our
[12:38] content. So, we have content everywhere. We have content in a DAM. We have content in YouTube. We have PDFs. We have white papers. Um we have emails. There's just content everywhere. So, what agent Tagatha will do is go out to where all of the content
[12:51] is. Uh Google Drive. We have campaign briefs. Um brings all of that content into Databricks. Uh it'll then summarize it. Add it to a vector search database so that we can do natural language queries on it. Um and then it also
[13:05] applies some contextual tags on top of it. So, we have the agent read through like for a given email, it'll read through the email and determine who is this email designed for, what persona is it designed for, what life cycle stage
[13:17] is it designed for, um what industry is it designed for. So, we have all of these tags now um on our campaigns, on our content. We also apply similar tags to things like our OKRs, our business
[13:29] objectives, our target setting. Um and what that'll eventually allow the agents to do and our LLM um processing is start to build that richer picture on what's actually happening, who's engaging, what
[13:43] are they engaging with, what does it mean to the business, and how does that relate to our key objectives. And where that leaves us is with this architecture and this is where we are now. This is um
[13:55] somewhat similar to the last one. The big differences are we've added metric views at the gold layer. Um we've also added that blue contextual layer. It's not a physical layer, it's more of a virtual layer, but that's where all of
[14:07] our context processing lives. That's where we have our vector search database. It's where we have our AI judges. Um and the AI judges are really important. They monitor the agents that we have and they'll monitor the input,
[14:20] monitor the output, and I assess the quality. And if we see quality drift, we get alerted to that and we can start making changes. Um and then all of this, you've heard about ontology earlier in the week and
[14:32] um onto rank it, things like that. The ontology still works um but it does also leverage a lot of this additional context that we've added and the content and everything else. Um so now what that allows us to do is
[14:44] still more of the insights and activation. That hasn't changed, but we're able to um apply AI on top of that. So now we have AI taking a first pass at those analytics that we couldn't
[14:56] get a good response from before. Now it's actually able to build out a narrative. What's working, what's not, where do we need to invest, how does one campaign relate to another campaign. Um all of that information, all of that context, it's able to leverage that. So
[15:09] we've gone from weeks to generate some of this insight down to days to generate some of this insight because the analyst now just need to review what the AI has put together, make a few changes, validate it's right. Um and then same with our activation
[15:21] layer, we're able to leverage AI for that. Um, we had some AI in the past, but it was very generic because our data was generic. So, it would say, "Campaign A is the best campaign in the world. Send it to everybody." But, it may not
[15:33] be appropriate for everybody. Now, those models can look and see, "Okay, this campaign is the best campaign, but it's really designed for data engineers in the manufacturing industry who are in the awareness life cycle stage." So,
[15:45] let's give that campaign to those people. It'll operate really well. For the rest of the audiences, let's figure out what works for them based on all of that additional context. So, that's where we are now. That was the detailed
[15:57] bits and bytes of our architecture. I'll turn it back over to Alex for going through the UI aspect of it. >> Thanks, Thomas. Um, now that we had a data foundation that wasn't just 30
[16:09] joins in one table, um, the next challenge was how do we give marketers the ease of self-service in a land of a hundred Tableau dashboards? Um, you know the drill. An event lead says they need to see summit reg
[16:22] numbers. So, you build a summit dashboard. Demand gen lead needs to see how they are attaining to targets. So, you build a target dashboard. The digital marketer says they want to see how efficient their campaigns are.
[16:35] So, you build a digital dashboard. And a program owner wants to see their top driving program. So, you build a digital Oh, sorry, a program dashboard. Um, four different users asked four different questions and
[16:48] we built four different dashboards. But, was it really four questions? Every dashboard we built just led to a million more questions. Dashboards alone only showed the what
[17:01] and not the why. No good decision making comes slowly from dashboards. So, how did we actually go from all of these dashboards to making decisions? Um, we took a three-pronged approach for
[17:13] this. First, I'm going to show you how we empowered our stakeholders uh to better self-service at their fingertips, and then how we freed our team from manual tasks, so they could focus on work that's driving impact, and finally
[17:26] we gave both stakeholders and our team the tools to make decisions faster through AI-powered insights. So, coming into that self-service aspect, um the way we improved self-service was we accomplished this through
[17:38] Databricks-powered visuals in AI BI and Databricks apps. So, we completely deprecated Tableau, and we moved all of our dashboards into a single interface built on apps, which we're calling
[17:50] Marketing Lens. Um the app has dedicated hubs for each topic like you saw, so we have a CMO view, demand gen, brand, we have a summit view, um things like that.
[18:03] And all the KPI cards are interactive, so users can still filter each KPI to things like um BU and subregion. This, however, did not eliminate the demand for deep dives, and so we did
[18:16] embed AI BI dashboard deep dives into the lens itself, where they could still get that deep uh knowledge that they need um on top of that high-level CMO view.
[18:31] But dashboards alone don't tell you the full story. So, every deep dive dashboard that I just talked about, we do have partnered with its own Genie curated Genie space. So, users can look in a chart in Lens, and let's say they see an increase in pipeline, they can then ask in natural
[18:44] language to the Genie, "Which campaigns drove the most pipeline last quarter?" Um Genie is UC governed, so it does respect permissions, and as Thomas had talked about, it is semantic layer
[18:56] aware. And so, when I'm asking for qualified pipeline, I don't need to describe what that is, the Genie will already know and will give me that same answer every single time. Because we have a Genie on every single deep dive, users might not know which
[19:10] Genie room they're supposed to ask their question. So, we do have that multi-agent Genie embedded in the lens. And so, when we ask a question, I think the battery just ran out on the computer.
[19:22] That's a good segue where um within the lens, when you click on a Genie, you can push a button on the right of the Genie. That'll take you to the full Genie landing page. And what's really cool
[19:35] with the full Genie landing page is probably my favorite functionality is you can use Genie agent. And Genie agent uses deep thinking node where you can actually ask it the why behind the what. So, in that first question where I said,
[19:47] "Which campaign drove the most qualified pipeline?" You could ask it, "Why did that campaign drive the most qualified pipeline?" It'll give you a data-driven answer to that question and get you that why behind the what.
[20:03] Um so, we went from all of these Tableau dashboards and all of these questions that spawned from that Tableau dashboard to marketing lens with those functional hubs and those deep dives within it to Genie 1 where users can ask their
[20:16] questions in mobile, Slack, that multi-agent. So, the dashboards alone didn't get the users the data they needed, but it's really that combination of the dashboards and the apps and Genie on top of it that starts driving users
[20:29] to making the right decisions. Um dashboards are great, but sometimes our users want a little bit more hands-on experience where they want us to do some of the insights for them. And the way that used to work was we
[20:43] would make them open a ticket, we would scope the request, and we'd go back and forth for about a week, and we'd be manually pulling data and narratives, and that would take about a 1 to 2 weeks, and it'd be 20 slides from scratch, and that's just for one
[20:56] business unit. And I don't know about you, but I want my slides to look good, and I'm spending all this time manually pulling data and moving them into slides manually, and I don't have time to actually do the analysis cuz I'm
[21:09] spending so much time just moving data from one source to the other. Um this is where agents come in. We actually built an agent called Agent Deckly, and it populates slide decks, and so we can spend more time getting to
[21:21] the insights. How it works is we upload a slide template, and Deckly will have a conversation with you and tell you how you can upload it and what's the best way to access. And he also has a catalog, so he can remember every
[21:34] template you've given him. And Deckly will identify all tape uh tables and placeholders, so you can do individual words as well that you can replace um in the deck. And he'll ask you which SQL queries you
[21:47] want to use to populate that deck. Once Deckly runs, he probably runs end to end maybe 10 minutes, and he'll run all of those queries against your gold table, and he'll swap in the values, and
[21:59] the output is that finished decks that attach the tables and all. And he is one and done, and so once you have a template built, he'll remember the queries, and um he'll you'll never have to prompt him again to fill out those
[22:12] queries. So this works really well for like QBRs, for example, when you need to pull a QBR per BU, per region, and you don't want to be manually pulling data for all of those decks, and so we can
[22:24] generate all those decks at once and spend the time doing the insights instead of um filling out decks. Um now what if I told you that you can have fully automated reports with
[22:36] insights and key takeaways land in your stakeholders' inbox every single week? You ask for data in plain English, the AI fills out charts, insights, and key takeaways, and a Databricks-branded
[22:48] report per region arrives in a stakeholder's inbox without me even having to push the send button. Well, we actually accomplished that using Genie code. Uh what used to take a week now lands in
[23:00] our stakeholders' inbox, all four regional leads every Monday. So, what we did is we first prompted Genie code in natural language the color palette that we wanted for Databricks and the
[23:12] template we wanted to look like. We then prompted Genie code with the KPIs that we thought were important. You can see in the the final product that we asked it for things like MQL to SQL rates, attainment, response volume,
[23:25] things like that. And because of that semantic layer that Thomas talked about, uh Genie code has all the context it needs to understand what I mean when I say MQL to SQL rate, for example. Um we then asked Genie code to analyze trends
[23:38] in KPIs. We told it what we wanted to look for, like how far off something is from attainment, uh quarter over quarter, compared to benchmarks. And we told it to use uh whichever model it thinks is best to
[23:51] generate these AI insights. And finally, using that Genie code uh email connector and that Google connector, Genie code actually pushes all of this data into
[24:03] Google Docs and sends the email to the user without me even having to send it myself. And so, this entire product right there, you can see the final product, was all prompted in Genie code in natural language, and they get those
[24:15] insights automatically every single week. So, putting that together, this is actually a real-life use case that happened to me last week where a stakeholder opened an email from those automated emails they got and the report
[24:28] flagged that MQL to SQL rate was down 50%. So, they went into Lens and saw that drop. And they wanted to dig more into it. So, they went into the AI BI um deep dive that's embedded and they did see it
[24:40] increase in unknown dispositions. They went into Genie cuz they wanted to know where that unknown was coming from. And they asked the Genie which team in AMER had the lowest MQL follow-up volume. And because of that multi-Genie,
[24:53] it did know where to route it to the correct um Genie and it got an answer to that question. Because I'm doing a lot of funnel reporting, I actually had a deck already available. And so, I went ahead and generated that deck with Agent Deckly
[25:06] with them to fill out the data, and we included those insights that we just, uh, gleaned from Genie and from the lens. And we forwarded the deck to the XDR lead with recommended actions. So, what would have taken a week and going back
[25:19] and forth, um, with the analyst team to to pull this data, we actually had it resolved in 30 minutes, and we had the call scheduled with the XDR team ahead of their monthly pipeline reviews.
[25:33] >> All right, so putting it all together, what did we learn? Um, fix the data foundation first. If you try and throw AI on top of a wobbly foundation, it'll give you some kind of answer. It won't be a good answer. It'll be
[25:45] confident, and it'll be also subpar. Um, so definitely fix that foundational layer first. Um, and then give it as much context as you can. AIs work a lot better when they have more context than less. So, the as much as you can,
[25:59] add context where you can, especially if it's at the data layer. So, as the, um, agent is reading data, it's also reading the context, and it can start building out those relationships. >>
[26:12] Um, a lot of our stakeholders love the, um, Genies. They love having that embedded in Slack. That's where they work. They just want to be able to ask a question in natural language and get that response. Um, so we're leaning heavily
[26:24] into that as well. Uh, and then where are we going? Um, we're trying to build out some more of these, um, templates. Uh, if you just ask, uh, an AI the same question twice, it may give you the same result twice,
[26:36] but it'll be formatted slightly differently. So, um, as Alex was talking about with Deckly, we have these templates. We're trying to build more of those templates so that we can deliver different types of insights that are always formatted the same. Cuz as you're giving these insights to executives, you
[26:48] don't want them to have to try and relearn the layout. You just want to have a simple layout for an executive to read over and over and every time they get the update they know exactly
[27:00] we're also moving more towards recommendations. So, we want to lean heavily into having the AI use all of this context and deliver more real-time recommendations, especially to our individual stakeholders. Um instead of just giving a generic um
[27:13] overall idea of you should spend more money on X, like for a given event campaign manager, what should they do specifically versus maybe an email campaign manager, what should they do that's different? So, personalizing it to the people um as well as
[27:27] personalizing our outbound communications to our customers. Uh and then eventually, this is more long-term, getting to that closed-loop activation. Um today we have a human in the loop. We want to get to a place where in some instances we can remove
[27:39] that human from the loop and where we have enough trust be able to say the AI recommends we do X and then the AI takes action on X and then just gives us a report that says, "This is what I found. This is what I did." And then we can
[27:51] monitor it that way without necessarily having a human approve absolutely everything. All right, and that's it. Thank you all. Um I think we can take We have some time for questions now if there are any additional.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.