Databricks推出CustomerLake：嵌入湖仓的Agentic CDP
Databricks发布CustomerLake，一款嵌入其湖仓、由Unity Catalog治理的Agentic CDP，围绕Profile Agents和Campaign Agents两类AI代理组织，并与Acxiom的身份解析引擎原生集成。
AI解读：客户数据平台过去通常独立于公司的核心数据平台之外，结果经常又多出一份敏感客户数据要同步、加密和对账。CustomerLake的卖点就是把这个环节省掉，代理能在一个地方拿到身份、预测模型、业务规则和投放端的访问权。
产品核心是两类代理：Profile Agents把散落的客户数据拼成Customer 360画像，宣传中使用了Acxiom的图身份解析能力；Campaign Agents则用治理好的上下文来建受众、推荐下一步动作、跨渠道投放，并围绕业务目标持续优化。营销人员可以用自然语言在Genie里探索客户上下文、搭建受众，不用排队等数据提取。
围绕这些能力，Databricks提出了“Infinity Campaigns”的概念，把过去那种建一次、发一次、再重建的活动，替换成始终在线的循环：代理先找受众，考虑资格和库存限制，推荐下一步报价或渠道，投放后按表现优化或抑制。
这套东西能不能落地，很大程度上取决于度量和身份。文章强调“增量”是营销和财务的共同语言，要能分清哪些结果是品牌动作带来的、哪些本来就会发生。身份则要持续维护，把已知客户记录和匿名意图信号连起来，同时不牺牲隐私、治理和消费者信任。
Acxiom与Lovelytics的案例给出了具体数字：把数据和身份服务重建成Databricks上的原生应用层后，可执行的客户洞察上市时间缩短约30%，运营成本降低约15%。Acxiom的Real ID身份解析引擎也已在Databricks上原生运行。
Databricks发布了一款名为CustomerLake的产品，官方定位是“Agentic CDP”——带AI代理能力的客户数据平台。它嵌入Databricks湖仓，由Unity Catalog治理，营销参与和个性化与公司其他业务共用同一套数据和AI基础。
传统CDP通常独立于公司的核心数据与AI平台之外，会多出一份需要集成、保护和核对的敏感客户数据。Databricks称，CustomerLake的代理可以在一个地方获得经过治理的身份、预测模型、业务逻辑、投放端和效果信号的访问权。
CustomerLake如何组织代理
CustomerLake围绕两类代理组织。Profile Agents把碎片化的客户数据转成可供业务使用的Customer 360画像，使用Agentic Identity Resolution，把确定性匹配、概率匹配和代理匹配，与Acxiom基于图的身份、数据卫生、匹配和丰富能力结合起来。
Campaign Agents使用经过治理的客户上下文来构建受众、推荐下一步最佳动作、跨渠道激活，并围绕业务目标持续优化。
营销人员可以用自然语言通过Genie探索客户上下文、搭建受众，减少等待定制数据拉取的时间，同时由人定义策略、目标和护栏。
Infinity Campaigns与增量度量
CustomerLake支撑Databricks所说的Infinity Campaigns，即始终在线的参与循环，用来替代反复搭建、发布、重建一次性活动的模式。营销人员从目标出发，比如重新激活流失客户；代理随后识别合适受众，考虑资格或库存约束，推荐下一步最佳报价或渠道，跨目的地激活，并根据表现优化或抑制。
在度量上，Databricks主张让度量进入决策循环，而不是事后出报告。增量性是核心概念：把营销活动关联到的结果，与因为品牌行动而改变的结果区分开。归因、增量测试和营销组合建模各自贡献一部分画面，对话式分析可以帮助团队不用排队等定制分析就能探索发生了什么以及为什么。
持续学习也有助于发现饱和和收益递减，识别投资应该转移或活动应该停止的时点。
Acxiom与Lovelytics的重建数字
Acxiom提供了一个身份基础现代化的例子。Acxiom与Lovelytics合作，将其数据和身份服务重建为Databricks上的原生应用层，可执行的客户洞察上市时间提升约30%，运营成本降低约15%。Acxiom的Real ID身份解析引擎现在也在Databricks内原生运行，品牌可以在数据已经所在的地方解析和丰富客户数据，而不必导出到单独环境。
Lovelytics通信与媒体实践负责人Jay Goebel说：“我们各自带来不同的部分。Databricks带来平台，Acxiom带来可信身份，Lovelytics带来交付经验，把它投入生产。作为CustomerLake的早期发布合作伙伴，我们正在一起努力，让营销人员可以基于客户上下文行动，并证明这个行动值多少钱。”
代理需要的四类上下文
传统客户记录捕捉的是谁以及做过什么，代理要做出营销人员认可的决定，还需要四类上下文。客户上下文覆盖身份、历史与当下行为、偏好、同意状态和生命周期阶段；业务上下文覆盖增长目标、利润率影响、品牌规则、库存和渠道约束；决策上下文捕捉客户已经收到过哪些报价和动作、如何回应、以及早期决定为何做出；控制层则是人定义的意图、护栏、权限和审批点，代理必须遵守。
上下文的体量增长很快：单笔交易可以携带30到50个元数据参数，因此一个客户画像很容易达到数千列上下文，远超任何营销人员手工处理的能力。
一个快餐品牌流失客户的例子
文章用一个快餐品牌常客来演示。这位常客已经停止下单，但最近又打开App浏览。条件反射的做法是再发一张折扣。更好的做法从品牌真正要做的决定开始，走五步。
决定：品牌现在是否应该触达这位客户？如果是，选项包括提醒、不同信息、激励、不同渠道或组合。上下文：把购买历史与购买前信号连起来，包括App和网站行为、浏览或加购商品、过往报价、媒体参与、生命周期状态、渠道偏好和沟通许可。经济判断：品牌需要知道激励是否会改变行为，还是只是补贴一笔本来就会下的订单；也需要知道继续对这位客户投入付费或自有媒体是否还在产生回报。行动与护栏：推荐的讯息、报价、时机和渠道都在营销人员定义的资格、折扣深度、联系频率、同意、品牌标准和需要人工审批的点之内运行。度量：品牌判断与不采取行动相比，这次动作是否带来了增量订单、收入、利润率或复购，结果回到客户上下文中，为跨自有和付费渠道的下一次决定提供依据。
同一情境下不同客户需要不同回应。如果一位通常每周五下单的客户错过了一周，然后在周四浏览常点订单，及时提醒可能就够了。如果同一客户六周没下单，正在浏览家庭套餐但没有完成，套餐优惠或免费小食可能有助于重建习惯。如果客户反复看到消息却没有回应，可能是在发出信号：品牌应该换信息、换渠道，或者暂时停止在他们身上花钱。