Martech 终极指南 | Austin Hay（Reforge、Ramp、Runway）

Austin Hay 2023-08-13

Martech 终极指南 | Austin Hay（Reforge、Ramp、Runway）

文字记录

确定性匹配的黄金时代终结

Austin Hay： 从2010年到2020年，我们经历了确定性匹配的黄金时代——投放广告并精准了解是谁安装了应用，这一切都轻而易举。也许你不知道他们的名字，但你确实能知道他们的 IDFA，并且可以将其与个人身份信息（PII）关联起来。现在做不到了。这意味着，广告网络正变得更加复杂、精密和有趣，而与此同时，营销人员却越来越难以真正理解自己的钱花在了哪里。因此，我非常关注营销人员如何在概率性数据下做出决策，因为我目前大部分工作实际上就是在回答这样一个问题：既然我们不再拥有关于特定受众或用户来源的确定性数据，那我能否找到其他信息来为一个样本建模，覆盖30%的人群，然后据此外推到百分之百。

什么是 Martech

Lenny： 欢迎来到 Lenny 的播客，在这里我会采访世界级的产品负责人和增长专家，从他们打造和增长当今最成功产品的亲身经历中学习。今天的嘉宾是 Austin Hay。在 Martech，即营销技术领域，Austin 是世界上最聪明的人之一。他曾为 Notion、Airbnb、Walmart、Postmates、Robinhood，甚至 Pete’s Coffee 和 Mars 提供过 Martech 战略和战术方面的咨询。他目前担任 Ramp 的营销技术负责人。此前，他曾是 Runway 的业务运营副总裁，mParticle 的增长副总裁，也是独角兽公司 Branch Metrics 的第四号员工。他还在 Reforge 教授 Martech 这一专题。在这次对话中，Austin 解释了到底什么是 Martech，它如何融入你的增长组织，什么时候需要招聘 Martech 人员以及应该看重什么，还有他最喜欢的面试问题。此外，还有他最推荐的工具、框架、团队结构，以及他最看好的新兴平台。本期节目适合所有负责增长、并希望优化方法论以及了解营销技术如何融入其中的人。Austin，非常感谢你来到这里，欢迎来到播客。

Austin Hay： Lenny，非常感谢你的邀请。

Lenny： 今天我们要变得非常极客，深入探讨 Martech 这个非常酷的领域。你对聊 Martech 有多兴奋？

Austin Hay： 我非常兴奋。因为你可能是产品和增长领域里第一个讨论 Martech 的人。

Lenny： 哇，好吧。这让我更兴奋了。是的，Martech 是我一直没有完全理解的东西，所以我很期待深入挖掘。那我们先从基础开始。到底什么是 Martech，从事 Martech 的人具体做什么？

Austin Hay： 这个问题问得好。因为营销技术是一个非常模糊、跨职能的学科，处于产品、增长、工程和营销的交汇处。它将来自众多学科的流程和系统整合在一起。我认为，理解营销技术真正的方式是把它看作一个产品经理，其特定角色和关注点是系统——无论是第三方平台还是第一方平台。因为营销技术可以指一系列第三方工具的集合，很多人是这么认为的，但随着公司规模的扩大和增长，它实际上还可以包含一系列你在内部自建的第一方解决方案，可以与第三方工具并存使用。所以我倾向于把营销技术看作两部分：一部分是人与流程，另一部分是系统与平台。这大概和很多产品人对自身领域的理解非常相似，这就是我对 Martech 的定义。

你同时还问了从事 Martech 的人具体角色是什么，我们稍后可能会详细聊，但这很大程度上取决于你所在公司的规模和阶段。在 Airbnb，我可以说 Dmitri——你可能和他共事过——就是当时的 Martech 负责人。他管理着 Airbnb 大量的第一方和第三方工具。那时候 Airbnb 的规模大概是800人左右，所以拥有一个配备产品和工程资源的职能团队是合理的。而小创业公司就不一样了，比如我在 Runway 和 Siqi 一起工作的时候，我们刚聊过这个，那里根本不存在 Martech 这个概念。就是我和 Tanner 还有 Siqi 自己搭建工具、使用工具，因为你必须用这些工具才能完成工作。所以说，在 Martech 的光谱上，你真的需要看公司的规模和阶段，随着公司的成长，你会看到它变得越来越精细、越来越明确。

Lenny： 那么，如果有听众从事增长工作，或者是增长产品经理，可能会想，这不就是我做的事情吗？那么，一个做增长或带领增长团队的人，和一个专门的 Martech 人，区别在哪里？

Austin Hay： 在某些层面上，也许没有区别。我可以说很多30人以下的初创公司里，你有一个增长团队，你的增长获客人员在用 CDP 把数据发送到广告网络来投放广告，因为那就是他们工作的一部分，也许他们就是 Martech 人。实际上你会发现，很多现在自认为是 Martech 专业人士的人，最初都是从增长或用户获取角色起步的，因为他们必须使用工具才能完成工作。但我想说的是，随着公司的成长和扩张，Martech 会从一种社区式、村庄式驱动的模式，转变为一种集中管控的模式。如果你是一家30到40人的初创公司，每个人都可能参与管理你的 CDP，或者使用 Amplitude，或者在它们之上搭建第一方解决方案。

这是一套第一方和第三方工具的混合体，工程、产品和营销团队共同协作。但这种模式无法扩展。当公司规模跨过100到200人之后，必须有人负责了解数据如何在工具之间流转、如何运作、数据模式（schema）是什么。这还没考虑采购和法律方面的事。如果你不妥善管理合同，你将面临无限的责任风险。所以通常在公司达到100到150人左右的时候，就会到达一个临界点——你不能再对系统和工具采用村庄式的管理方式了，就像在 IT 组织中一样，如果对 SSO（单点登录）也采用村庄式的管理，企业将面临很大风险。这就是你通常会开始听到这样的问题：好了，我们需要一个系统和工具负责人，我们需要有人来管理这些系统和管理那个平台。

这有多种组织方式。我见过它完全归属产品方向，由产品运营组织来负责，一个产品运营人员实际上会管理大量第三方和第一方工具。我见过它归属 IT 组织，比如 Walmart 在很大规模时就采用了这种模式。他们有一个 MarProd（营销产品，Marketing Products）职能，是营销职能内部的产品，或者是为营销服务而设计的产品。当然也可以有更传统的路径，比如营销技术可以作为一个独立的单列单元，或者商业技术作为独立单元。这还部分取决于企业是 B2C 还是 B2B。通常在 B2B 企业中，你会看到 Martech 归属于收入运营（Rev Ops）或某种系统角色，因为你不仅要服务进入你获客漏斗的用户，还要服务之后的那些企业客户。

这也是你通常会看到 Salesforce 这类工具以及更高级 CRM 登场的场景。而在 B2C 企业中，你的用户漏斗实际上非常简单——获取用户，把他们引入产品，然后由产品接管。没有额外的 CRM，所以通常 CDP 就是你的数据真实来源（source of truth），这也正是为什么在 B2C 中你往往会看到营销技术与增长结合得更紧密。举几个例子，比如在 Postmates，我给他们做了很长时间的咨询顾问。营销技术就是增长的一部分。在那之前我们甚至有一位增长总监，就是 Runway 的 CEO Siqi Chen——我刚才了解到你应该是他的第一任经理——他是第一任增长 VP，而营销技术就是增长的一部分，产品团队作为系统来管理它。

另一个不同的例子是 Ramp，我们的规模足够大，而且是一家 B2B 公司，但我们有一个 B2C 的漏斗顶部，用来获取用户并让他们填写申请来获取信用卡。我们有一个独立的收入运营团队，分为商业技术和营销技术两部分。所以，Martech 的组织形式有很多种。我觉得这正是营销技术有趣和好玩的地方——它不是一个单一的万能模式可以套用到所有公司，我见过无数种变体，它们都在试图解决同一个问题。

Lenny： 那么，为了让听众更具体、更简单地理解 Martech 人的工作，本质上就是使用技术和工具来推动增长，对吗？这是不是理解这个特定角色的一种简单方式？

Austin Hay： 完全正确，就是这样的。我有一句常说的话：工具就是用来解决问题的。而营销技术人员和商业技术人员所专注的问题集合，就是工具本身。

Martech 人的具体职责切片

Lenny： 那么，如果现在有听众的公司还没有 Martech 人，他们在想，我们是不是存在这个缺口？假设他们目前已经有一个增长团队，或者一个带领增长的增长 PM 和围绕他的增长团队，那么 Martech 人会接手哪一块工作？

Austin Hay： 顺便说一下，这个问题太常见了。我每年都会和很多遇到这个问题的公司交流：我们有增长团队，增长得也挺快。我们招了一个人，通常是工程师出身，帮我们搭起了所有这些工具。也可能是女性，这里不限于性别，但这个人已经在这里两年了，对我们所有的系统非常熟悉，但现在他们开始不堪重负了。时间不够用，系统太复杂。这是我经常从初创公司那里听到的一种典型故事——他们招到了一位优秀的增长人才，管理和维护了工具和系统，但到了某个节点，一个人的力量甚至几个人的力量都无法再支撑。而那一块工作切片包括：配置新工具，在现有工具之上搭建新工具。因为很多时候你会拿一个第三方工具，比如 Segment 或 Amplitude，然后在你的自有技术栈中在其后端搭建工具，来实现更高级的功能。

所有人都以为营销技术就是那些第三方工具，但实际上它还包括在你的第三方工具之上进行设计、架构和搭建。这才是你真正获得高速推进能力的方式——不只是考虑”自建还是购买”，而是”自建加购买”。你购买工具完成90%的工作，然后用剩下10%在上面搭建酷炫的东西。而这个架构决策通常就落在 Martech 人身上。其中一个特别不性感的部分，我倒是很喜欢，因为它的杠杆效应非常高——那就是合同部分。当你作为一家企业刚起步时，你可以随意和第三方签任何合同，因为你只是想先跑起来。你有更大的问题要解决——产品市场契合度、活下去、资金跑道（runway）。但随着你扩张并开始赚钱，你开始关心的不仅仅是赚了多少钱，还有因为签约 SaaS 工具而损失了多少钱。

所以你开始更加审慎地审视：我们在签什么类型的合同，条款是什么？我们有没有责任风险暴露？如果我们继续扩张，成本会是多少？我们在500 MTU 时拿到一个很棒的费率当然好，但当我们有100万 MPU 时会怎样？我之前在 mParticle 工作过很长一段时间，它是一个 CDP 供应商，我是他们的增长 VP。他们的 SaaS 供应商策略的一部分就是：如何设计这些成本结构，使得随着客户公司扩张我们也能赚更多钱？这只是商业模式的一部分。所以如果你具备那种思维方式——不只是着眼于当下，而是展望未来两到三十年为业务把关——那么作为一个系统人员或营销技术人员，你就能创造巨大的价值。

什么时候该招营销技术人员

Lenny： 也许一个信号是——你该开始在增长团队中考虑引入营销技术人才了——我听到的是，你开始积累各种不同的工具，而且可能有一种感觉：在连接数据、搭建后端基础设施方面，你本可以高效得多，无论是对增长思路的构建、驱动增长还是衡量增长来说都是如此。

Austin Hay： 没错，效率和痛苦。我觉得痛苦驱动力更强。就是那种——嘿，我们做不了某件事，因为没人懂这个东西；我们做不了某件事，因为我们不知道搭建这些工具或更换这些工具的最佳方式；我们甚至无法推进一个业务方案，因为我们担心更换工具可能会带来影响。而且通常这跟邮件营销工具和数据工具有关，比如 CDP 以及 Braze 之类的厂商，因为很多时候你的邮件正是驱动回头客持续回访和使用产品的关键。所以，如果你不了解某样东西最初是怎么搭建的，有时候你根本无法做出你想要的改动。

营销技术人员在组织中该放在哪里

Lenny： 你谈到过这个人应该在组织中的什么位置。有各种不同的可能性。我提到过收入团队、运营团队、增长团队、营销团队。关于谁应该主导招聘这个角色，以及大概应该汇报给谁，你有什么总体建议吗？

Austin Hay： 这么说吧，我不想无耻地给我秋季的 Reforge 课程打广告，但我还是要无耻地给我的 Reforge 秋季课程打个广告。我们做了一个很棒的矩阵，展示了这个人应该放在哪里、做什么、向谁汇报，这些都在秋季课程里，如果你想深入了解的话。课程中会有一个专门的章节。不过要点是这样的——我首先喜欢把它拆分成两个维度。第一个维度是 B2C 公司还是 B2B 公司。第二个维度是，这个人是否需要汇报给某个特定职能部门，这一点对你有多重要？所以首先是 B2C 和 B2B，然后是集中式和分散式。

先说 B2C，其实更简单的说法是集中式还是分散式。所以我们有 B2C、B2B、集中式、分散式这几个组合。在 B2C 组织中，我觉得其实相当简单。大多数情况下，你的工具、你的营销工具都是为增长团队服务的。增长团队有一个明确的任务目标（job to be done），就是推动用户增长，工具只是为了解决这个问题。所以营销技术的职责就是服务增长团队。当然它也为产品、分析和数据服务，但它的核心利益相关者和客户是营销或增长职能。所以我觉得，如果你在 CMO 或营销负责人下面设计组织架构，把营销技术放在增长负责人旁边，或者根据这个人的资历让他向增长负责人汇报，是非常合理的。这个模式运作得很好。这里的关键是，你要确保这个营销技术人员是一个非常强的技术架构师，或者某种类型的技术运营者，因为他们将代表你与产品和工程组织打交道。

当然，有些人会在这个基础上做一点小小的变体。他们说，嘿，我有一个从产品经理方向出来的增长 PM。你可以设一个平台 PM 来在营销技术中扮演同样的角色，负责所有内部平台系统。然后就会引出一个问题：这属于产品运营还是不属于？这个问题我就不展开了。但对 B2C 来说，这就是集中式模式。至于 B2C 的分散式模式，你的做法就是说，嘿，我们在每个组织里都放一个这样的系统人员。产品团队有产品运营人员，增长团队有增长运营人员，工程团队有工程运营人员，然后根据他们管理的工具来划分界限。我通常觉得这种做法效果不太好，因为随着你增加更多运营人员，它只会制造更多系统。

所以除非你是一家需要那种规模的大型公司，否则我觉得大多数初创公司应该避免分散式模式。然后说到 B2B，我觉得 B2B 真的很混乱，因为你不仅有纯 B2B——只向企业销售的情况，还有 B2B2C 的概念，即你实际上有时候在漏斗顶部和底部分别向用户和企业销售，但有时候也同时向两者销售，比如 Notion。Notion 向用户销售，所以他们在顶部有一个小型增长获客漏斗，但他们同时也向企业销售。我发现这里确实也分为两种方式——分散式或集中式。实际上在 Ramp，我们在两种模式之间来回切换过。我们一开始是集中式，放在收入运营（Rev Ops）组里，后来分散化，把营销技术放到 CMO 组织里，现在又把它重新收回到收入运营组织里。很大程度上取决于：我们的客户是谁？

我们在解决谁的问题？资源分配在哪里？因为如果你采用分散式模式，就有可能面临资源被分散到各个团队的风险。问题在于，那个职能团队能不能真正推进工作，还是资源过于分散、优先级不够对齐，导致难以推进。我想说的是，尤其在 B2B 方面，对于正在收听的各位，没有一个标准答案。我甚至认为营销技术可以放在产品团队里，也可以放在工程团队里。这在很大程度上取决于这个职能的领导者是谁。如果偏向运营——即管理流程和系统——那也许你想要分散化，把它留在各自对应的职能部门。如果你有一个非常技术型的领导者，之前是架构师或 PM，那可能就暗示这个人应该在哪里带领团队。所以这非常因情况而异，我知道这是一个糟糕的答案，但事实就是如此。

营销技术人员是 IC 还是管理者

Lenny： 完全说得通。如果有人要招一个像你这样的人，Austin，你是自己做具体工作吗？你会作为 IC（独立贡献者）做很长时间吗，还是最终会组建一个团队，比如工程师来搭建其中一些基础设施？通常是怎么发展的？

Austin Hay： 我觉得所有营销技术人员在某种程度上都是 IC。我个人觉得这是一个很好的岗位，因为我可以同时做 IC 和管理者。你必须作为 IC 的原因是——你是所有第一方和第三方系统的最高级别技术专家。所以你必须非常了解第三方工具的运作方式，而你不亲自动手就不可能了解。所以我确实发现，一些最优秀的营销技术人员至少在过去五年中的某个阶段，做过工具和系统的运营操作专家。而且团队通常很小，超级跨职能。

所以我想说，比”这个人管过多少人”更重要的是——他们向上、横向和向下管理的能力如何，因为他们要去跟收入运营负责人沟通才能在 Salesforce 里改东西，他们要去跟产品 VP 沟通才能做一个影响其他系统的大平台变更。他们还要不断依赖数据负责人提供数据资源。所以我觉得这个人的秘密武器更多在于——他们作为跨职能团队成员有多出色。我几乎把他们看作真正的四分卫（quarterback），每个人都说自己的人才是四分卫。但营销技术真的是这样，因为它横跨这么多部门，天然就要扮演那个调度战术、拉动不同部门的角色。

Lenny： 因为听起来你并没有一个团队来帮你做这些事情，你需要说服别人来帮忙。

Austin Hay： 完全正确。这本质上是一场说服和推销的游戏。你必须让人们相信这些问题很重要。而且尤其是在公司规模变大之后，营销技术的很多决策和问题并不是关于如何快速实现一次巨大变革，而是缓慢的变革可能带来巨大的影响。我举一个例子。我接触的很多大公司都有两个 CDP 或者两个归因工具，这里面有成本问题——我们怎么去掉那个次要工具来降低成本？也许是一百万美元。但同时还有复杂性和决策的问题——我们怎么让人们更快地推进工作，而不是每次都要纠结”这种简单的事情我到底该用哪个工具？”

然后到了 Walmart 那种真正大规模的层面，你的问题甚至不在于”我们怎么整合技术栈、让工具对人有帮助”，而是”我们怎么防止重新回到那种混乱状态？我们怎么设置防护机制，确保人们确实能用到他们需要的工具、能解决自己的问题，同时又不给组织引入重复的技术？“因为一个非常知名的模式——抱歉让 SaaS 厂商们躺枪了——就是 SaaS 厂商常用的渗透扩张策略：先以小规模入驻，然后逐步扩展业务。但这对于想要控制成本、简化运营方式的企业来说，恰恰是一个棘手的问题。

营销技术人员的日常

Lenny： 我想聊聊你推荐和最常用的工具，不过我在想，也许我们可以先换个问题——作为一个营销技术人员，你的一天是什么样的？你每天都在做什么？如果从增长 PM 或管理者听这个播客的角度来看，这个人能为我做什么？如果我找到一个营销技术人员，能获得多大的杠杆效应？

Austin Hay： 营销技术的工作中有一半，我会称之为偏行政管理性质的、高杠杆的工作。包括管理 PI 请求和 PI 技术，管理合同、工具权限和准入这类行政事务。这都是在大型公司层面才会做的事，小公司大概率不会做这些。但这些事情很重要——举个例子，你给某个人开了 HubSpot 的编辑权限，然后他向一百万人发了一封测试邮件，结果你的公司就在 Twitter 上丢脸了。就是这样——

Lenny： 这种事在你身上发生过吗？

Austin Hay： 我自己没遇到过。但我收到过一些公司发来的这种邮件，内容是”这是一封测试邮件”，而且还是实习生发出来的。

Lenny： 对，我也收到过。

Austin Hay： 你就会觉得，这纯粹是权限管理出了问题。所以我觉得这个角色很重要的一部分就是设计自动化系统来处理这类事情。因为理想情况下，你不想整天坐在电脑前一个一个地点击审批权限请求。系统应该根据角色、工龄和部门自动做出判断，决定给你开放哪些权限。所以自动化这些流程是我工作的重要组成部分。而我工作中偏手动的那部分——其实我觉得非常有趣——就是为未来设计系统和合约。核心是：我们如何设计一套系统、构建一个愿景，并说服大家相信我们一到两年内——这通常是我关注的周期——的系统技术应该是什么样的？然后怎么从现在的状态过渡到那个状态？这其中会涉及财务和合同层面的问题，这就是合同管理发挥作用的地方。我们现在的合同条款是什么？我们在付什么价格？我们未来的增长会是多少？

我们能不能建一个财务模型来展示，无论是从运营效率还是实际的固定和可变成本来看，达到那个目标状态要花多少钱？然后我怎么构建一个有说服力的论证，让人们同意我们应该投入工程时间和资源？通常结论会非常明确——如果成本低于某个阈值，你怎么证明值得为此投入工程资源？你得等问题积累到足够大才行。但回到你刚才说的——怎么给正在听的增长管理者一些实用的建议。我觉得在公司早期阶段，人们常常忘记的一件事是：公司会比你活得更久——希望如此。你不会是最后一个增长管理者，除非公司倒闭了。所以我倾向于采取一种与大多数人不同的方式——我认为你应该始终为未来考虑。

这不意味着你应该做出过度偏向未来导向的设计决策，以至于错过了产品市场匹配（product-market fit）或者做出了糟糕的产品决策。但当你选择工具、部署和实施工具时，你应该思考：如果什么都不改，一年后会怎样？这会不会变成灾难性的局面？然后采取措施去降低这个风险。比如一些具体的例子：如果花两千美元就能启用 SSO，两天就能设置好，而这能防止有人下载你所有用户数据的安全问题，那看起来就是一笔很划算的投资。

而且你猜怎么着？随着时间推移，如果你不做这件事，最终你还是得雇一个 IT 人员来给所有工具逐一配置 SSO。所以这类事情更多是关于做一个好的管理者——在管理第一方和第三方工具时，带着对未来的思考来行事。这始终是一个权衡，对吧？因为你在公司早期阶段搭建产品时花的时间，本可以花在其他事情上。所以如果你把时间浪费在管理第三方工具或配置工具上，也许就会错过一个关键的产品功能。所以我觉得这是一个很难把握的平衡。

营销技术与营销运营的区别

Lenny： 回到增长体系内不同角色的话题，假设有人负责付费增长，就是一个纯做付费增长的人，你会不会也安排一个营销技术人员跟他搭档工作？你和一个只负责付费增长的人之间会有多紧密的联系？

Austin Hay： 这里也许有一个关键的区分点。我们开头没有聊到这个，就是营销技术和营销运营之间的区别。在我心目中——这只是我自己的思维框架——营销技术里面有个”技术”，所以通常是由工程师或具有工程背景的人来承担这个职能。营销运营通常不一定是技术性的，可能是系统分析师或业务分析师，也可能是一个非常聪明的人，但他们未必有工程背景。所以我觉得这是一个很关键的区别。通常在 B2B 场景中你会看到这种情况——会有一个营销运营职能，负责搭建营销活动、发送邮件、调试问题、做分析工作、写 SQL 查询，这些都是半技术性的工作，但不是以工程为基础的。所以在我看来，当我们谈论营销技术时，我真的把它当作一个以工程为基础的角色。就我自己而言，我不是软件工程师出身，但我是土木工程师，后来学会了编程，通过一系列的编程训练走到了今天。

营销技术人员如何支持用户获取

所以，这就是我进入工程领域的方式。你会发现，尤其是很多营销技术人员，他们要么本身就是软件工程师，要么已经积累了足够的经验，可以”兼职”当软件工程师用。回到用户获取人员的问题——他们会如何依赖营销技术人员？我觉得那些最厉害的用户获取人员本身就是工程师，他们不需要营销技术人员，因为他们自己就能搭建工具。他们知道付费广告怎么跑，一个人全搞定了。你通常会在小初创公司见到这种超人——工程师被联合创始人一句”去搞清楚 Facebook 广告怎么玩”推过去，一个超人就此诞生。但更多时候情况并非如此。或者那些人做过一次之后就再也不想做了。所以通常你会发现这个角色会拆分开来，这是自然而然发生的事情。

随着规模扩大，你会进行分工。你会看到一个人负责竞价、获取用户、压低广告成本；另一个人负责搞定整个系统——怎么让这些东西真正跑起来。我们在 Ramp 也是类似的结构。我们有一个非常优秀的用户获取团队。我知道 Sri Batchu 之前来过这个节目，他在 Ramp 招了一个叫 Cody Morgan 的人，由他带领一支用户获取团队。可以这样理解：我的工作是支持他们满足所有广告投放需求。当 CEO 下达指令说我们需要优化 CAC 或调整任何指标时，我的职责就是与他们协作，帮助达成目标。实际上，我刚加入 Ramp 时，我们做的最酷、最有意思的项目之一就是做优化——

端到端的数据打通与广告优化

我们试图把漏斗顶部数据一路贯通到漏斗底部，与商机数据关联起来，然后把这些数据回传给广告网络。这样一来，你的广告优化不再基于用户点击了网站上的某个按钮，而是基于商机是否真的产生了、这个商机的理想价值是多少。你把这条数据作为一个合成事件（synthetic event）发送回 Facebook 和其他广告平台。根据你深入漏斗的程度和业务的复杂度，这可以是非常酷、非常前沿的东西。

Lenny： 所以你一般不会自己去 Facebook 或 AdWords 上跑广告，作为营销技术人员，你更多是在支持那些负责跑广告的人。

Austin Hay： 对。

Lenny： 明白了。

Austin Hay： 帮助他们使用工具和技术来达成目标。

营销技术的目标制定

Lenny： 好。那别人会给你设定目标吗？你自己是否承担增长目标？一般来说，营销技术人员应该有自己的增长目标，还是仅仅作为支持角色服务他人？

Austin Hay： 这个问题问得好。也许我们可以在节目末尾问问其他嘉宾，因为我很想知道更好的目标设定方式是什么。我对这个有两种思路。一种是，我的目标直接与我所服务的人挂钩。比如用户获取团队——我们确实有——Ramp 有增长目标和 CAC 目标。所以我的目标与他们绑定，我要确保这些目标得以实现。但除此之外，我内心还有一个关于成本和效率的目标，我认为它很有价值。至于业务方是否认为它有价值，那倒不一定重要。我有销售背景，我喜欢运营精简高效的团队，所以我总是在想：我接手时工具成本是多少？现在又是多少？我是否为公司未来的成功奠定了基础——随着我们的增长，每个用户、每个席位摊到的成本是否在下降？我们因此变得高效了多少？理想状态是：业务在增长、赚更多钱、招更多人、获取更多用户，而人均工具总成本反而在下降。这才是最理想的状态。有很多种方式可以构建这种财务模型，但我认为这是大多数营销技术领导者应该追求的——确保持续控制成本，因为大多数公司做不到这一点。

还有一些目标可能不是成本效率方面的，而更偏向能力建设，是离散型的。比如，嘿，我们要打造一套世界一流的第一方系统，实现这三个目标。或者你想在产品平台的某个环节引入人工智能，集成第三方工具。这些更像是具体的产品目标。就像企业可能会发布对外的产品目标——上线某个功能一样，有时也会有内部产品目标：清理收入运营系统、改进邮件营销系统。特别是邮件营销这个，我经常看到中小企业乃至中型企业遇到这个问题——他们在公司创立初期选了一个工具，随着公司成长，那个工具已经不够用了，需要迁移到 Braze 或 Marketo。于是就会有一个为期六个月的大项目：我们必须迁移。这就是目标。我们要安全地从一个小工具切换到一个更大、更复杂的工具，成本更高、复杂度也更高，但必须在不亏钱的前提下完成。这通常是营销技术人员的工作，属于某种变革转型类的项目。

工具栈推荐：B2C 的过去与现在

Lenny： 完美地衔接到我想聊的下一个话题——工具和你推荐的好工具。那我们是不是先聊聊，对于开始思考营销技术和增长的人来说，一个好的起步工具栈是什么样的，然后最终一般会演进成什么样？

Austin Hay： 关于工具栈，我们还是要区分 B2B 和 B2C。B2C 方面，我觉得工具栈在 2017 年到 2020 年间基本已经定型了。之后数据架构迎来了一次复兴，所以我的做法是先回顾 B2C 的过去和现在，然后再看 B2B 的过去和现在。

Lenny： 好。

Austin Hay： B2C，如果你回到 2016、2017 年，那时候有 Segment 和 CDP 的崛起。面向消费者的企业需要采集用户信息，关联一堆数据，然后追踪他们的行为，发送给效果广告网络、邮件营销工具和产品分析工具。所以你会看到一套非常标准化的工具栈——中间是一个 CDP，周围连接一堆工具。CDP 的承诺是：你只需集成一个 SDK，工程师不会讨厌你，数据自动分发到其他工具，你还能创建受众群体。挺好。持续了很长一段时间。但我觉得大约在 2020 年前后，真正发生变化的是数据仓库的持有成本大幅降低了。到了 2021 年，你开始进入这样一个阶段：把所有数据存储在数据仓库里、在仓库中建模，这件事变得非常合理且非常简单，而且不需要庞大的数据团队。我觉得 Airbnb 可能比其他任何公司都更早做好了这件事，但他们有一个巨大优势——钱多、资源多。现在到了 2020 年，拥有一支数据团队、搭建自己的数据仓库、在 Snowflake 这样的平台上集中管理数据，已经具有成本效益了。于是问题变成了：好，我们得把数据导入仓库，但数据如何在各系统之间流转？这个问题变得完全不同了。

反向 ETL 的崛起与 B2C 工具栈选择

Austin Hay： 这正是反向 ETL 兴起的真正原因。现在你实际上可以构建自己的 CDP 了，很多企业已经这么做了。几个月前我在为一家知名金融交易平台做咨询，他们有 CDP，仓库里也有所有这些内部数据，但他们一直无法激活这些数据，因为架构相当老旧，一切都是基于批处理的、按日结算。他们需要的是一个反向 ETL。他们不需要把数据拿出来直接推送到外部世界——他们需要的是反向 ETL 这个组件，或者说 CDP 中的数据转换组件。所以我觉得，今天当我们谈论 B2C 企业时，你可以走传统路线，购买 CDP，连接所有第三方工具。

我认为如果你没有太多工程资源，这是一个很好的选择，因为你不需要在数据仓库及相关的所有建模工作上花费大量时间和精力，只需要花时间实现一个 SDK。我觉得如果你的业务追求的是简单，CDP 加中心化工具栈是个很好的选择。但如果你是一个拥有先进工程文化的团队，走在技术前沿，打算在 DBT 中做大量建模，并且已经有了 Snowflake，那你应该转向使用反向 ETL 的模式。这意味着你有办法把数据导入仓库，而如何激活数据则完全独立于 CDP。这实际上意味着你可以有很多不同版本的工具栈。

你可以用 Amplitude 作为你的 CDP，采集所有数据，流式传输到 Snowflake。他们现在实际上有一个与 Snowflake 的集成，可以直接从 Snowflake 中提取数据，然后你可以用反向 ETL 把数据传输到任何你需要的地方。不过这里有一个非常好的章节——再次抱歉自我吹捧——今年秋季的 Reforge 模块中有一个很好的章节，讨论的是当你有多种数据迁移方式时会发生什么。你买了 Amplitude 做 CDP，把数据迁移到仓库。Amplitude 有一堆集成，但同时你也有反向 ETL，可以把数据从仓库中迁移出来。

你怎么选择？我觉得很多企业会陷入困境，因为它们没有一套方法论或体系来决定何时以及如何将数据从一个地方迁移到另一个地方，只是随意地去做，对吧？系统管理的关键在于，你要设计一套流程——某种瀑布模型或心智模型——来决定什么时候适合直接从 Amplitude（即数据流的采集点）迁移数据，什么时候适合从仓库中迁移（在那里你可以对数据进行建模和优化）。我认为关键是要有一套理念和方法。并没有唯一的标准答案，但以上都是 B2C 的情况。那么 B2B 的话……好，你说。

Lenny： 在我们继续之前，你提到了反向 ETL，有哪些产品是反向 ETL 的例子，方便大家去查阅？

Austin Hay： 好的。我个人认为反向 ETL 是一种能力，即把数据从仓库迁移到某个工具的能力。所以从技术上讲，你会在 CDP 中找到反向 ETL 功能，也会看到独立产品。Segment 刚刚推出了反向 ETL 功能，mParticle 也刚刚推出了反向 ETL 功能。RudderStack 作为一个 CDP，一直都有反向 ETL 功能，可以把仓库数据迁移到不同的云基础设施。然后还有一些独立的单独产品——Census，曾获得 a16z 投资，以及 Hightouch，这是两个独立的反向 ETL 产品。如我所说，我是 Hightouch 的投资人，很喜欢他们的工作，我们在 Ramp 也在使用他们。归根结底，你应该选择能帮你解决问题的工具，而不是因为其他原因。所以如果你想继续聊这个话题，我们可以回头再谈。

Lenny： 太好了，非常好，完美。继续。

B2B 与 B2B2C 的复杂性

Austin Hay： 好。我们聊了 B2C。B2B 的话，我可能不像那些经历过 2008 年互联网泡沫的人那样有那么多历史经验。我 2014 年才真正开始我的 B2B 职业生涯，所以我会分享一下我的经历，也希望听众可能会说，天哪这家伙根本不知道自己在说什么——这完全没问题。2014 年的时候，我记得在 Branch 工作，我为我们的 COO Mike Molinet 工作，他现在在一家很酷的公司叫 Thena。当时我为 Mike 工作，正如我们之前聊到的，增长工具栈往往就是这样出现的——因为你面临一个挑战。我记得和 Mike 坐在一个小房间里，我们在帕洛阿尔托，就在帕洛阿尔托的山丘旁边那个小房间里。

房间里热得要命，我们都在出汗，在白板上规划如何设计我们系统的第一版——如何捕获潜在客户、如何把他们导入 Salesforce、如何用当时还叫 Outreach 的小工具给他们发邮件——那时 Outreach 还是一家创业公司。我可以之后把这些发给你，如果你想给观众看的话。那真的是非常 MVP 的状态，但它仍然建模了很多人今天还在使用的架构：有某种数据采集入口，有 Salesforce，有某种外发工具，有数据补全工具，然后还有一堆拼凑起来的东西挂在 Salesforce 上。在很大程度上，今天 B2B 仍然是这样——你有 Salesforce，然后整个世界和宇宙都围绕着 Salesforce 转。你只是有了更先进的工具，有了 Gong 之类的。

不过我觉得真正的变化、也是我一直觉得非常有趣且值得关注的，是在过去两三年里，B2B2C 模式全面崛起。它把漏斗顶部用户获取系统的所有复杂性，直接塞进了你的 CRM 旁边。如何在那片空间中构建一个优雅的系统，我认为是今天作为一名营销技术人员最复杂、最精巧的挑战之一。其中一部分原因就在于数据语言——所有这些 B2C 工具都只围绕两个对象来设计：用户和事件。如果你不是技术人员，面向对象就是你理解世界的方式。在用户获取系统中，世界只有两个概念：一个用户——一个匿名或已知的人，进入你的网站；以及他们在你的网站或应用上做的事情。你利用所有这些数据来获取用户或对用户建模。

在 B2B 企业中，你拥有所有这些复杂性，但归根结底，如果那个人只是在签合同，你可能并不真正需要这些——公司签了合同之后你也不太关心之后发生什么。你可能会追踪应用内的用户和事件，但那不是为了获客，而是为了用户留存。B2B2C 就很令人着迷了，因为你在顶部拥有所有复杂性，但然后你要如何、何时将一个用户关联到一个公司或某种实体对象？你需要什么工具来做这件事？这些工具在系统中处于什么位置？这些工具之间是否存在相互冲突的优先级？我给你举一个最好的例子——这在 Notion 时发生过，我在为他们做咨询时遇到过，在 Chris 为他们做咨询时也遇到过，在 Ramp 也发生过——就是同时使用 HubSpot 和 Salesforce。

HubSpot 与 Salesforce 的数据映射难题

Austin Hay： 两者都是 CRM，都有追踪用户和公司的能力，但都不是 CDP。而你实际上如何把数据从 HubSpot 映射到 Salesforce，基本上决定了你要承受多大的痛苦，而且真的没有什么好的解决方案。你只能自己去想办法——你想如何在漏斗顶部获取用户？如何把他们合并到 Salesforce 的漏斗底部？同样，这里有很多选项或者说不同版本的架构。你可以只用 Amplitude 收集所有的用户和事件数据，然后直接合并到 Salesforce。你也可以把所有数据收集到 Amplitude 或 Segment 中，然后发送到 HubSpot，再由 HubSpot 发送到 Salesforce。但当然，随着你做出这些决策，你的系统会变得越来越复杂，复杂到一个人无法管理。所以，你始终需要在复杂度和资源之间做权衡。

Lenny： 在 B2B 和 B2C 领域有一个很大的问题，就是如何做归因。这可以说是一场永无止境的斗争。我很好奇你有没有什么专业建议、最佳实践或工具，可以帮助企业改善归因的方式。

Austin Hay： 其实我听过你关于多点归因的那期节目。我一时忘了当时的嘉宾是谁了，但我特别喜欢，因为专门讲了 MMM 和 MTA。

Lenny： 对，那其实是一篇 Newsletter 文章，不是播客。

Austin Hay： 好，回到我们之前关于分工的讨论。我并不总是那个你应该找来创建 MMM 模型的人。我不是数据科学家。我知道如何做 MMM 模型，也了解它们是什么。

Lenny： 你能简单解释一下 MMM 吗？

归因模型的基础

Austin Hay： 营销组合建模（Marketing Mix Modeling）。MTA 代表的是多点归因（Multi-touch Attribution），这是两种衡量世界和营销效果的方式，用来理解你应该如何将资源分配到广告投放上。但 MTA 和 MMM 的底层都依赖于你如何收集数据。它们都基于你在网站或应用上收集的用户对象和事件对象，这些数据最终被数据科学家用于 MTA 和 MMM。这就是数据与营销技术之间的联系——我们搭建、部署和管理的工具和系统，往往是最终用于这些非常复杂的增长、实验和归因分析的基础。

关于 MTA，我能给出的最具体的建议——因为这个问题我经常被问到：我们需要 MTA 吗？我应该用首次触达还是末次触达？还是两者都用？实际上，我可以发给你一份指南，但基本上有六七件事你可以做，基本上可以让你在未来不需要依赖其中任何一种也能做好准备。因为大多数企业要么从首次触达开始，要么从末次触达开始，然后最终都想转向多点归因模型。对于不了解的人来说，首次触达就是收集用户最初从哪里来的数据。末次触达就是收集用户最后一次从哪里来的数据。

举个例子，如果我通过 Google 广告来到了 Lenny 的 Newsletter，而且只有这一个渠道——那这就是我的首次触达，也是末次触达。如果我最初是通过 Google 广告来到 Lenny 的播客，但后来又通过 Facebook 广告或者直接访问进来，那后者就是我的末次触达。

所以问题就在于：是最初的 Google 渠道应该获得功劳，还是后来那个 Facebook 或直接访问应该获得功劳？在首次触达归因模型中，100% 的功劳归于第一个渠道；在末次触达归因模型中，100% 的功劳归于最后一个触点。而混合归因模型或多点归因模型，你要想办法如何分配这些功劳。通常企业的演进路径是：先从首次触达或末次触达开始，然后变成简单的 50/50 对半分。然后有人因为没拿到足够的功劳而不满，说我们必须上 MTA。对于 MTA，既有第一方解决方案，也有第三方解决方案。

从第一天起为 MTA 做好准备

回到重点，核心在于如果你想想自己到底在收集什么——这对网站类业务来说——你收集的是来源页（referrer），就是 URL 中那个人从哪里来的信息，以及与该用户关联的所有 UTM 参数。你还需要广告网络可能给你的那些参数，让它们能够统计一次转化。每个广告网络都会在 URL 中塞一些小东西，告诉你用户是从它们那里来的。Facebook 有 FVP、FPID，有时还会做编码。Google 有一个叫 Google Click ID 的东西，就是一长串字符，除非你知道怎么解码，否则毫无意义。但所有广告主——而且在很长一段时间里，广告的运作方式就是把参数放进 URL，把用户引导到你的网站，收集这些参数，然后传回给广告网络，这样它们就能获得功劳。

所以在我看来，每个人从第一天起就应该做的最佳实践，就是为 MTA 设计好系统，然后在成长过程中使用任何对你合理的归因方式。我通常给人们的建议是：想象一下当用户来到你的网站时，你收集 URL，收集来源 URL，收集所有你可能需要的额外营销参数——TikTok ID、Microsoft ID 等等，你应该列一个清单。如果你没有这个清单，我可以给你。然后你应该收集所有 UTM。在 URL 中，你会有 UTM campaign、UTM medium。大多数营销人员用它来标注广告活动的类型。但需要注意的是，UTM 只对用户来到你网站的那个特定时刻有效。回到之前 Lenny 播客的例子，如果我来到 Lenny 的播客，而且是从 Google 广告来的，那我的 UTM 就只针对那个 Google 广告。

本地存储归因参数

**Austin Hay：**所以，你会获得一个 Google Click ID 和一组 UTM。接下来你要做的，就是把这些参数本地存储在设备上——不管是浏览器还是其他什么。你要把它们存为 UTM 首次推广活动（first campaign）和 UTM 最近推广活动（last campaign）。具体做法是，每次用户来访时，你用当前的新值替换掉上一次的值。比如上一次来源是 Facebook，后来用户从一封直邮广告过来，你就把 UTM 最近渠道（last medium）替换成新的值。如果你在使用第三方工具，当用户在网站上时你就在收集这些用户信息——你既会将其作为用户属性收集，也会作为事件来收集。在你的数据仓库团队的后端，他们会看到一个用户画像，上面同时包含首次归因信息和最近归因信息。

至于中间的所有环节，你发出的每次页面浏览事件都会同时携带首次和最近归因信息，其中最近归因可能会因为中间经历了多个步骤而有所不同。数据仓库团队可以做的，就是把某个用户在所有事件中看到的最近 UTM 进行合并（coalesce），从而同时获取首次的、中间所有的、以及最近的那一个。所以这个系统其实并不复杂。大多数人只是早期没有做这项工作，等到后来想要做 MTA 分析时，才发现没有数据可用。所以我给那些犹豫不决的人的建议是：从一开始就把基础设施搭建好。

把系统设置成这样：你有用户，有用户属性，你在用户身上收集首次和最近 UTM，你的事件也携带所有这些信息。还有一些更复杂的做法——你可以把它们设置在第一方 cookies 里，也可以设置在工具供应商的第三方 cookies 里。但归根结底，最重要的是从第一天就开始收集这些信息。这样当你真正想要升级归因模型时，就不用再等很长时间来积累数据了。

数据仓库与数据分类体系

**Lenny：**太棒了，你分享的这些细节我非常喜欢。我不知道人们还能在哪里找到这类建议。听起来核心要点之一是，你需要一个数据仓库，把所有数据都扔进去；之二是，你需要一套可靠的数据分类体系（taxonomy），以便后续能用它做各种不同的事情。这个理解大致正确吗？

**Austin Hay：**对，我觉得没错。不过关于数据分类体系，有趣的是它在很大程度上受制于你的第三方工具。这也正是我认为很多公司在这方面做得不到位的原因——他们没有去思考：我的工具到底允许我往里面放入什么？

**Lenny：**确认一下我是否理解了你的意思——你是说第三方工具通常会限制你能做的事情，从而给你后续带来困难。而你的建议是这块追踪工作自己做，大致是这个意思吗？

**Austin Hay：**对，是这样。可以这样理解：如果你自建数据仓库，你的数据模式（schema）是无限的——你想怎么设计都行，可以设计产品数据模式、用户数据模式和事件数据模式。但大多数面向 B2C 的第三方工具不允许你控制数据模式。据我所知，只有一个 CDP 能做到这一点，那就是 Snowplow。其余的工具都只有一个用户对象和一个事件对象——你要么把数据作为用户属性塞进用户对象里，要么把数据塞进事件里作为事件发出去，能做的就这么多了。所以我想说的是，大多数人根本没有去思考他们使用的第三方工具的对象结构，也没有据此去设计自己的网站流量或应用流量的数据收集方案。我们还没谈到应用端——那是完全不同的另一套问题，因为 iOS 14 之后的归因要困难得多。

即便在网站的世界里，人们通常也只是收集了 UTM 就觉得万事大吉了，但实际上远比这复杂。你需要考虑首次和最近归因，考虑中间的各个步骤，把这些信息设计到用户画像和事件中。这就回到我们之前讨论的核心观点——营销技术专家的职责就是经常提前一到两年思考我们将来需要解决什么问题，并以优雅的方式设计系统，不一定要花费巨资，但至少要达到最小可行产品的标准，能够真正支撑未来的需求。我工作的一大部分，我认为也是营销技术专家这个角色的核心，就是以最小侵入性的工程和资源代价，去守护那个未来状态的可能性。

新兴工具与平台

**Lenny：**你谈了不少前瞻性思考以及各种工具和平台。我想知道，有没有什么新的、正在崛起的工具、平台，甚至增长渠道，是你在持续关注、感到兴奋，或者觉得越来越有用的？

**Austin Hay：**如果不谈谈 Threads 就太不应该了。Threads 非常值得关注。问题在于他们能多快搭建起广告 API，它会是什么样子，还是说他们直接把它并入现有的 Meta 和 Facebook 架构？我相信很多效果营销人员会认同这一点——Facebook 在数据报告上存在利益冲突。他们希望你多花钱，所以自然会倾向于报告最好的结果。正因如此，Branch 和 AppsFlyer 这样的第三方归因平台才应运而生，某种程度上就是为了制衡这种利益冲突。所以我会非常关注归因机制将如何运作，尤其是当用户从 Instagram 跳转到 Threads、从 Facebook 跳转到 Threads 时——会沿用同样的架构吗？会是同一个广告平台吗？还是他们会尝试一些新的做法？

这是我正在密切关注的。Reddit 现在也是一个非常有意思的转化渠道。他们正在开放转化 API，我看到越来越多企业在 Reddit 上投入，因为现在可以投放嵌入式的广告，看起来几乎就像普通帖子一样，用户可以在下面评论。我认为这反映了广告业务正在走向成熟。在这一切背后发生的是，应用的广告归因已经变得困难得多，而且很大程度上只能依赖聚合数据。从 2010 年到 2020 年，我们经历了确定性匹配的黄金十年——投放广告后精确了解谁安装了应用非常容易。你也许不知道对方的名字，但你能获取他们的广告主标识符（IDFA），并将其关联到他们的个人身份信息（PII）。现在做不到了，挑战非常大。

即便能做到，你获得的结果也很有限，因为几乎没有人会选择授权给你他们的 IDFA。这意味着广告网络正变得更加复杂、精密和有趣，而恰恰在同一时期，营销人员却更难真正理解自己的钱花在了哪里。所以我现在非常关注营销人员如何基于概率性数据做决策，因为我目前的大部分工作其实就是在回答这个问题：既然我们无法获得关于某个受众或某个用户来源的确定性数据，那我如何找到其他信息来为一个子集建立模型，然后用它来推算整体。概率性匹配和概率性归因，我认为是更多营销技术专家和营销人员都应该熟悉的一项技能——这也是我们当今做决策的方式。

归因困难的具体原因

Lenny： 哇，我之前没听过这个概念。人们开始这样思考增长结果和影响力了——或者说，至少你建议人们应该这样思考——不再关注”这条广告带来了多少转化”，而是关注”这条广告产生这种影响的可能性有多大”。

Austin Hay： 并不是所有渠道都是如此，但对于有移动端应用的产品来说确实会受影响，因为他们无法再一对一地精确识别某个用户来自哪次推广活动。他们能知道有一群人来自某次推广活动，但无法将这些用户与其他属性结合起来进行衡量。网站的情况不完全一样，但也有不少因素让它变得越来越困难。首先是浏览器现在会剥离我们之前提到的那些 URL 参数。于是，越来越多实际来自付费广告的用户被算作了自然流量，因为当他们被重定向到你的网站时，浏览器已经截断了所有 URL 参数。第二个因素是 Cookie 拦截器。我们之前聊过各种第三方工具。

第三方工具收集信息的常见方式是在你的浏览器中植入一个 Cookie 来追踪你。如果你听说过 Segment——过去几年最知名的 CDP 之一——它的做法是在网站上植入一个第三方 Cookie，里面包含一个匿名用户 ID，以及你在浏览网站过程中的所有属性。然后一旦你登录，它就会将这个 ID 转换为一个已知的、非匿名的用户 ID。

通常这个 ID 会绑定到某种实体 ID 或用户记录上。在那一刻之后，如果你再次访问并且它识别到你的 Cookie，它就基本知道你是谁了。现在，如果你屏蔽了 Cookie，那意味着你在整个用户旅程中基本都处于匿名状态，直到你登录。更不用说很多人还有线索转化漏斗，你需要那些信息来真正理解用户在转化之前的行为。所以，如果第三方 Cookie 在用户还没机会转化之前就被屏蔽了，你就完全不知道这个人是从哪里来的。你只是看到他们注册了，所以只能算作自然流量。

应对归因挑战的方法

Lenny： 你谈到很多人正在努力适应这个 ATT 之后的新世界，归因测量变得困难得多。你有没有学到什么有效的方法来在一定程度上恢复对当前情况的测量？有什么建议可以分享的，或者你见过什么有效的做法？

Austin Hay： 有的，我觉得很多人现在都在转向营销组合建模（MMM），但并没有真正理解 MMM 在什么情况下有用、什么情况下没用。不知道你知不知道一家叫 Recast 的公司，我好像记得你是投资人，我没记错吧？

Lenny： 没错。而且你之前提到的那篇文章正是他们写的。

Austin Hay： 对，是 Michael 写的，还有另一个人，我记不清名字了——

Lenny： 是另一位 Mike Taylor。

Austin Hay： 我不是 MMM 的专家，所以没办法像他们那样深入地讨论。但我和 Michael 交流过，当我思考 MMM 时，我更多会问：这对我们现在的业务来说真的现实吗？我们有没有足够的数据来跑一个 MMM 模型？这个模型会如何改变或指引我们的效果广告营销策略？如果从这些角度来看，大多数企业其实还没有准备好用 MMM。他们真正需要的是多点归因（MTA）和更好的概率性建模。我知道这个观点不算什么惊人之语，但至少在 Ramp 以及我观察到的其他正在运营的企业中，实际情况更像是——我们回到了那种只能大致了解每条推广活动带来了多少广告收入的状态。

我们无法再将这些数据与具体的用户旅程精确关联起来。而且我们知道这批用户中有一定比例可能已经流失或者本来就是自然流量。在这种情况下，我们该如何做出投放决策？当然，你也可以采取一些聪明的方法。比如，对广告牌做基于地理位置的测试，在其他干扰因素不变的前提下，尝试将广告牌作为一个独立变量来评估。你可以做到很巧妙。不过，协调这类推广活动其实非常困难，尤其如果你的企业规模很大，在全美范围内投放线上广告，同时又想在几个特定城市做独立的广告牌测试——要协调关闭某些定向条件、确保没有干扰因素，这些都极具挑战。所以我觉得目前没有一个银弹式的解决方案。

招聘营销技术人才的标准

Lenny： 太好了。还有几个问题，然后我想问一个更宏观的问题。假设你想招下一个 Austin Hay，首先，你在候选人身上看重什么？哪些迹象说明这个人值得聊聊？然后你会问哪些面试题来评估他们的实力？

Austin Hay： 我最先关注的就是求知欲。我知道这可能听起来有点老生常谈，但我认为你可以很快判断出一个人是否对这个世界真正感兴趣、是否热爱学习。做第三方工具这一行，你必须不断学习。你永远不可能成为所有工具的专家，因为工具实在太多了——我忘了是哪家媒体，好像是营销技术领域某家出版物的主编之类的——我订阅了一份出版物，所有东西都被归类为营销技术（Martech），那个图谱巨大无比，能铺满一整面墙。当然我不认为那里面所有的东西都算 Martech，但即使只有一小部分是，技术工具的数量也远远超过了一个人能精通的范围。所以，如果你想在这个领域立足，你必须对学习充满热情，同时也要有快速学习的能力。

所以我通常把求知欲作为第一个信号。第二点，我觉得对有求知欲的人来说很有帮助的是——他们具备一定的工程能力，虽然可能不是最强的工程师，但他们知道如何解决问题。他们懂 JavaScript，懂 Python，能读懂 API 文档并发起一个 API 请求。他们有足够的基础知识来理解如何解决一个工程师才会面对的问题，即便他们自己不是工程师。当然，有时候你会运气好，碰到一个再也不想做工程师、决定转型到不那么技术化岗位的工程师，这种情况下他们非常强大，但我这辈子还没见过太多这样的人。而且也有一些商业上的现实考量——做后端工程师的收入可能比做营销技术的人要高。

所以，你大概率会选择那条收入更高的路径。这有点像一个效用函数。因此，我首先看重求知欲，其次看重基本的工程动手能力。顺便说一句，我想对很多人说的是——你不需要去拿一个软件工程学位。你可以自学，我就是自学的。你可以参加线上的编程训练营。我觉得通过学习 Web 编程或某种后端编程，你就能获得足够的知识。所以我认为，对任何人来说，真正掌握所需的技能集，投入不会超过六个月。当然，一旦掌握了基础技能，你可以在之后的多年实践中不断积累和提升。但如果你是这个领域的新人——比如你目前在营销运营岗位，想往技术方向靠拢；或者你是一个做付费推广的用户获取经理，但心想”我真的很想做端到端的事情”——你完全可以去学一些软件技能，学完之后你可能就会变得相当厉害。

这两点是我最先关注的。当然还有很多其他方面，但这两点是最优先的。关于面试问题，我喜欢问的一个问题是——我喜欢问候选人他们是怎么准备这次面试的。这不是我的原创，我没法居功。是我妻子告诉我、给我这个想法的，我一听就很喜欢。好像是 a16z 的一位合伙人用过的。但我非常热爱这个问题，因为当你问”嘿，你是怎么准备的？“时，你真正在问的是：这个人是如何思考的？他们是如何规划的？他们有多认真对待这件事？他们读了什么、做了什么？如果你还得不断追问才能让他们说出自己做了哪些准备，那说明他们不是一个系统性思考者。

但如果他们说，“嘿，其实我读了这些东西，我做了这些。我早上起来，先去跑了步。“回答越有趣、越复杂，候选人就越有趣、越复杂。所以我特别喜欢这个问题，因为它能让你在面试一开始就对一个人有一个非常全面的了解。另一个我喜欢问的问题是：假设你明天来我们这里，面对我们的营销技术系统，到周五你必须交出一份报告，列出所有我们应该改的地方。你会怎么做？我喜欢这个问题，因为它几乎可以立刻筛出那些有偏见的人和没有偏见的人。有工具偏见的人会立刻说”我们应该上这个工具，因为我之前用过”——而我喜欢招的是那些不绑定特定工具、对工具持中立态度的人。他们把工具看作解决问题的手段，而不是把自己之前用过的方案直接搬过来。

这并不是在抱怨，当然也不是要批评 PM——但我的观察是，很多 PM 就是直接选自己以前用过的工具，因为这样简单，是一条捷径。我理解这种做法，但问题并不总是一样的，所以工具也不应该总是一样的。所以我更倾向于选那些会花时间思考问题集和解空间的人，他们会反过来问你”你们要解决什么问题”。我认为这才是更真正的 PM 思维方式——从问题出发往回推导，而不是拿到问题后把自己已有的东西直接倒出来。

危险信号与误判标志

Lenny： 有没有什么信号会让你觉得这个人可能不太适合一起工作？

Austin Hay： 我从两个角度来看这个问题。一个是我作为招聘者招 IC 的时候，另一个是我作为候选人被招的时候。当我去一家公司面试时，我的一个危险信号是——我会要求看公司的财务数据。如果一家公司不愿意向总监级别或更高层级的人披露财务数据，那我不想跟他们合作，因为这意味着他们有所隐瞒。或者他们的文化是不信任组织中最资深的一批领导者。在我看来，这两者都不是好兆头。所以这是我去面试时一定会问的问题之一。至于招聘别人的时候——关于危险信号，我觉得更有意思的是”假红旗”而不是红旗。所谓的假红旗就是简历上的空白期，每个人都会盯着这个看，但实际上通常都很好解释。

一个很好的例子是，我曾经招聘过一个人，他的简历上有两年的空白期。我们最终没有录用这个人，但他走完了所有面试环节，没被录用不是因为他的原因，而是因为那个岗位被取消了。这个人花两年时间拿了一个哲学学位——也许是诗歌学位——同时还自学了编程。所以这两年过得非常充实，而且我能看到他有很多方式可以将过去的经历和这段间隔时间结合起来，成为一个非常全面的候选人。

所以我觉得，我与其说是在寻找红旗，不如说是在花时间排除简历上那些会导致错误判断的”假指标”。还有一个例子就是学校——人们就看你的本科或研究生院校，然后就做出这样或那样的判断。我觉得这也可能是一个非常糟糕的捷径，因为有很多非常优秀的创始人，他们的毕业院校你可能根本没听说过。我知道这可能不是回答这个问题的最好方式，但我在识别红旗方面确实没有特别好的方法，不过我确实会花很多精力去排除那些假红旗。

有用的思维框架

Lenny： 这个回答方式很好。我想换个一个完全不同的话题——这个问题我之前没有问过别人，但我很好奇这里是否有什么值得挖掘的东西，如果有的话，我以后会经常问这个问题。我好奇的是，你在工作甚至生活中有没有发现哪些思维框架特别有用？有什么想说的吗？

Austin Hay： 有一件事我想做——如果我真做出来的话，也许可以给你投一篇 Newsletter——就是做一份一页纸的文档，列出最有用的人生框架，只写框架名称。当然你得知道这些框架是什么意思，但我感觉自己总是遇到非常好的框架，然后转头就忘了。所以我想要一份一页纸的 Lenny 人生框架清单。

Lenny： 好，我们现在就开始。

Austin Hay： 太好了。

Lenny： 第一条。

Austin Hay： 好。

Lenny： 我喜欢这个。

Austin Hay： 好的，这个我已经说过了，你已经答应把它放在清单最前面，所以我非常期待。就是——工具是用来解决问题的。我跟我招的每一个人都会说这句话。在 Ramp 以及我所有的咨询项目中，我都会反复强调。而且不仅仅是这句话本身，更重要的是它背后的精神。工具真的只是用来解决问题的。你不必通过购买工具来解决问题，你也不必购买某个特定的工具来解决问题。我认为这句话浓缩了营销技术的核心理念——帮助人们理解自己的问题，然后利用第一方和第三方的工具与技术真正采取行动去解决它们。而大多数人只关注工具本身，只关注购买和集成。

PPS 框架：问题、人员、系统

Austin Hay： 所以我认为，如果你始终提醒自己工具只是用来解决问题的，那么你就会真正进入这样一个境界——作为系统层面的人，你可以成为你的营销人员或产品人员的拥护者。我觉得有时候人们会有一种倾向，认为那些管理和搭建工具的人只是对管理和搭建工具本身感兴趣，但实际上归根结底，我们是想帮助人们真正把事情做成。然后就是我经常谈到的 PPS 框架，即问题（Problem）、人员（People）和系统（System）。所以，每当在 Ramp 或咨询项目中遇到挑战时，我喜欢先问：问题是什么？涉及哪些人员？影响的是哪个系统？通常人们会直接跳到系统上，他们会说，嘿，有这个问题，我需要用工具来解决。嘿，我想做这做那，你能不能直接给我系统的管理员权限？

但如果你先退一步理解问题，比如，嘿，这个人想解决什么？他具体面临的问题是什么？一个很好的例子是：我是一位销售经理，我希望每次招人的时候，不用再经历那个非常痛苦的新员工入职流程。好，这就是问题。涉及的人员有哪些——销售经理是否需要获得 CRO 的批准？销售人员是否需要培训？是否存在某些我们没意识到的干扰因素，导致我们不应该直接把这个流程自动化？一旦你理解了人员和你要解决的问题，那么设计系统来解决它就变得非常非常容易。所以这是我给技术人员的头号框架——不要直接跳到系统，倒过来想，从人员和问题出发，然后再走向系统方案。

“构建并购买”而非”构建 vs 购买”

然后另一个我已经提到过的原则是 B and B，而不是 BVB。也就是构建并购买（build and buy），而非构建还是购买（build versus buy）。人们每次一谈到实施工具或采购解决方案，就立刻变成：嘿，我想自己构建这个东西，或者我想买那个很贵的东西。“构建还是购买”是一个非常狭窄的决策树。如果只有构建或购买二选一，那你就已经做出了只能二选一的决策，这意味着你已经在组织内部跟某人对立了。“构建并购买”意味着双方都能赢，你可以创造一个不仅独特、而且能为公司节省时间和资源、让所有人都满意的方案。这是一种更倾向于达成共识的方式。每当我在会议、电话或讨论中听到有人说”我们有一个工具，它很贵，我们想自己构建”时，我就会尝试用”构建并购买”框架来引导大家思考：问题中的哪些部分可以购买？哪些部分可以构建？我们应该在哪里投入资源和人力才能获得最优结果？

一个很好的例子是，我曾经为一家公司做咨询，他们在考虑构建自己的 AB 测试工具。实际上我们在 Ramp 最近也遇到了同样的问题。他们说：“我们觉得自己应该构建。这是我们的核心技术，我们有工程资源来做。“他们在评估是全部自己构建，还是购买第三方工具——我记得是 split.io 之类的。整个咨询项目基本上就是设计一个财务模型，向他们展示：如果他们以最低成本购买第三方工具，然后把原本打算用于构建的所有资源花在围绕它进行定制开发上，他们可以赚更多钱、省更多钱、推进得更快。而且有很多——我讨厌”协同效应”这个词，它就是让人不太舒服。

Lenny： 我倒不介意。我觉得它能准确传达你想表达的意思，而且我感觉人们现在已经不那么常说了，所以也许反而可以用了。

Austin Hay： 对，因为他们害怕。换一种更好的说法是”互利共赢”——如果你在购买了一个工具之后再围绕它做定制开发，因为此时供应商已经对你有了承诺，他们希望你成功，所以在第三方平台之上构建往往比完全自己构建能获得更快的成果。一个很好的例子是，你购买了某个 AB 测试工具并在其之上进行构建，你是他们的大客户，而你也投入了大量自己的工程资源让这个解决方案成为你自己的。如果他们知道这一点并且在乎你，那么在你需要他们做出改变的时候——比如某个 SDK 的变更或新功能之类——他们会愿意真正让你满意。

如何搭建技术栈

我在 Reforge 课程中经常讲的一个框架是关于搭建技术栈的。每个人都会问，嘿，我该怎么搭建我的技术栈？我该怎么做？我该用什么工具？就连你刚才也在问，黄金技术栈是什么？告诉我应该选哪五个工具？

Lenny： 直接告诉我就行了。

Austin Hay： 嗯嗯，最后再告诉你，我得留个悬念。不然你就把这个播客提前关了。

Lenny： 没错。对，留到最后。在进入我们非常精彩的快问快答环节之前，你还有什么想分享的吗？

Austin Hay： 我还想塞进去的最后一个内容，这可能算是一个框架，也可能只是一种非常好的决策哲学，就是”灰度思考”的概念。你听说过吗？

Lenny： 没有。说来听听。

灰度思考

Austin Hay： 好。Steven B. Sample 是南加州大学的教授，他写了一本书叫《The Contrarian’s Guide to Leadership》，非常好的书。灰度思考是书中的原则之一。书中其实有很多很好的原则，但这是我认为在我职业生涯中对我影响最大的一个。灰度思考的概念是——在生活和工作中，我们经常被迫非常快速地做出决策。我们不得不对一个问题或方案做非黑即白的判断，然后做出决定。他的一个策略就是灰度思考，即尽可能久地不做决定，直到你不得不决定为止。这真的很难，因为它涉及一个叫做”耐心”的小东西，而我大多数时候并不具备太多耐心，我知道大多数人也没有。但它在系统思维和产品领域特别相关，因为我们经常认为自己必须做出决策——因为老板在催，因为有一个 OPR（未结问题报告），因为我们感受到了痛苦，因为有人在向我抱怨。

但实际上，你根本不需要做决定。你可以先让它搁置一段时间。这也适用于我认为你如何在这个世界上行走、如何看待他人。很多时候我们在公司或商业场合遇到某个人，就会迅速对他们做出判断。你甚至问我如何快速评估求职者——我们都在寻找捷径来做关于人的判断决策。但关于灰度思考最好的一条建议是，它给了你一种余地，让你在不得不做出决定之前不对人下结论。当然，对于面试的决策，你最终还是得做决定。

Austin Hay： 你必须做出是或否的决定。但你经常会遇到一些人，见过一两次面。我觉得每个人大脑深处都有一种倾向——“我喜欢这个人吗？我想和他一起工作吗？“而真正的问题往往不是这个，而是——你现在真的需要做出判断吗？给自己留出决策的空间，你实际上为未来做出更好的决定打开了可能性。所以我认为这对系统思维来说是一个非常好的经验教训，而且显然这也是一个可以应用到生活其他方面的道理。

闪电问答环节

Lenny： Austin，太棒了。接下来，我们进入非常令人兴奋的闪电问答环节。我为你准备了六个问题。准备好了吗？

Austin Hay： 我准备好了，Lenny。

Lenny： 你最常向别人推荐的两三本书是什么？

Austin Hay： 第一本书我已经提过了，但再说一次——《The Contrarian’s Guide to Leadership》，非常棒的书。第二本非常好的是 Warren Bennis 写的《The Art and Adventure of Leadership》。这些更多是哲学层面的领导力书籍，不是关于如何运营企业的技术手册。所以你得对这类内容感兴趣才行。

Lenny： 最近最喜欢的电影或电视剧。

Austin Hay： 我最近第一次看《Suits》（《金装律师》），以前从来没看过，我觉得挺不错的，因为每一集的故事线都是：出了一个问题，然后他们解决了问题，最后问题在结尾得到了解决。所以对于任何焦虑水平较高、只想在每集结束时看到故事线得到解决的人来说，非常满足。但如果这不是你的菜、你更喜欢刺激的话，我还在看《Silo》（《末日地堡》）和《The Witcher》（《猎魔人》）。想要轻松搞笑的，有《Our Flag Means Death》（《我们的旗帜意味着死亡》），特别搞笑。你看过这部剧吗？

Lenny： 没看过，《Our Flag Means Death》没看过。

Austin Hay： 你得去看看。讲的是黑胡子和一位同性恋海盗船长的故事。强烈推荐。然后如果想要特别无厘头的喜剧，《What We Do in the Shadows》（《吸血鬼生活》）也特别搞笑。

Lenny： 什么？《What We Do in the Shadows》？

Austin Hay： 对。

Lenny： 好的。哇，好多推荐。谢谢。你最喜欢问候选人的面试问题是什么？

Austin Hay： 我之前谈过关于”你做了什么准备”的问题，但另一个我觉得很好的问题是——告诉我过去一年你生活中克服的最困难或最具挑战性的事情。不一定是工作相关的，可以是个人生活方面的。我觉得这是一个非常好的方式来重置气氛，让人们更深入地挖掘自己是谁，展现更多的脆弱面。而且我发现通常这也有助于让他们放松下来，因为如果他们已经分享了生活中最艰难、最困难的部分，那么其他所有问题就显得相当容易了。所以这是我最喜欢的问题之一。

Lenny： 你最近发现的、非常喜欢的一款产品是什么？

Austin Hay： 这听起来可能有点傻。叫 cal.com，我先说说缘由。我一直是 Calendly 的重度用户，但 Calendly 挺贵的。如果 Calendly 在听的话，想给我优惠的话，欢迎。但它确实很贵。而且我还发现它在同步多个日历方面并不总是很顺畅——包括公司用的、咨询项目用的、个人用的，我老是记不住我的 Calendly 链接。怎么说呢，界面感觉还停留在 2016 年。所以我一直在找一个更接近 Notion 风格的、有 Command K 界面、集成功能好用的工具。而 cal.com 没让我失望，非常棒。所以如果有人在找新的日程工具替代 Calendly，强烈推荐。

Lenny： 哇，我从来没听过这个。域名真好，cal.com。

Austin Hay： 是吧，绝了。

Lenny： 你经常对自己重复或在工作中与他人分享的人生格言是什么？

Austin Hay： 我经常思考感恩的力量，最近我一直在想人们在日常生活中可能面临的挑战。我最近听了 Adam Fishman 的另一档播客，他邀请了 Brian Balfour。Adam 基本上就是在采访一群爸爸，挺酷的。但在人生中年纪稍大一些、当了父亲之后的一个好处是，你可能已经经历过一些艰难困苦。这档播客非常棒，它探索了我真正钦佩的人的故事，了解他们经历的磨难。在这个过程中，我获得了非常深刻的体验——了解人们在生活中经历过的挑战，那些早年失去父母的人，那些失去孩子的人。我自己呢，我和妻子去年失去了她的父亲。我们因为新冠失去了两位祖辈，还失去了我们的狗。所以我认为，这和感恩之间的联系在于——如果你能理解人们正在经历什么，开始把他们更多地当作一个有血有肉的人来看待，去理解工作表象之下，他们是谁？他们在乎什么？是什么在推动他们的人生向前走？这会让你对所拥有的一切以及那些真正美好的时刻更加感恩。这不仅适用于生活，在商业中也是一样。当你知道人们经历过怎样的磨难之后，胜利会变得更加令人愉快。这也是我喜欢和人们谈论的话题，尤其是那些职业生涯早期、可能只经历过成功的人——我会向他们描述失败是什么样子的，这样他们就能在脑海中有所画面，等他们真正经历的时候也有了一些心理准备。这是我的一大特点。

Lenny： 多棒的回答。我以后一定会继续问这个问题。对于还在听的各位，接下来是承诺的黄金技术栈。

黄金技术栈

Austin Hay： 好，黄金技术栈。如果我是一家 B2C 企业，我会购买 Amplitude 作为 CDP，购买 Customer.io，未来可能升级到 Braze。我会把所有数据放进 Snowflake，购买 Hightouch 做反向 ETL，把所有数据推送到广告网络。归因方面，移动应用的话可能用 AppsFlyer，不然就用 Branch，但大概率首选 AppsFlyer。这样一来，你有了 AppsFlyer，Amplitude 作为 CDP 和产品分析，Customer.io 做邮件，Snowflake 做数据仓库，Hightouch 把数据流式推送到各种工具。如果我今天为一家 B2C 企业实施的话，这就是当前的黄金技术栈。

如果是 B2B，大致相同，也是 Amplitude。如果你需要归因工具，B2B 的话——实际上如果是纯 Web 业务，大概会用 Branch，因为 Branch 在 Web 方面更好。所以你有了 Branch、Amplitude，把所有数据连接到 Salesforce。希望某个时候有人能造出一个更好的 Salesforce。这个就留到我们下次播客再聊吧，Lenny，今天来不及了。然后反向 ETL 用 Hightouch。所以非常类似，唯一的区别是邮件工具怎么选。很多人用 HubSpot。我会尽量一直用 Customer.io，能撑多久撑多久，然后再迁移到 Braze。所以最大的区别就是 B2B 场景下 Braze 和 Customer.io 之间的选择。

Lenny： 最后一个问题。我听说你是无人机飞手，我很好奇，你在最酷的地方飞过无人机，或者和无人机之间发生过最酷的事情是什么？

无人机的趣事

Austin Hay： 这其实又回到了我们之前聊到的好奇心那个话题。也许我招聘时就是喜欢找些有趣的人，因为我特别喜欢看到人们在和工作无关的领域做有趣的事情。故事是这样的——疫情期间，我不想只靠一堆在线教育平台来提升自己。坐在电脑屏幕前学统计学什么的，感觉会有点消磨灵魂。所以我就想找一些有趣的、小众的、完全在我知识领域之外的事情来学。最后我选了三件事：学飞无人机、考了 CFP（认证理财规划师，Certified Financial Planner）资格，还成了一个公证员。就是因为它们看起来都很实用，跟我工作完全无关，还能学到一些全新又有趣的东西。

这三件事里，无人机那段其实挺搞笑的。我开始在 DC 这边飞。我住在弗吉尼亚，但离华盛顿特区大概就一英里，而 DC 周围有一个限制空域。所以我拿到 FA 无人机飞行执照、成为认证无人机飞手之后，就一头扎进了研究如何在 DC 飞无人机的兔子洞。我见过周围有人飞，但显然这涉及国家安全问题——我可能会把具体经历说得面目全非。但当我真的去操作的时候，流程非常复杂、陈旧，同时也挺搞笑的，因为一切都在线上进行。你得去填一张表，拿到一位地方代表的信，证明你品行良好。我们就找了一位我认识的市议员。然后你要把所有材料都填好。

那些文书工作的网站看起来像 1994 年做的。DC 有一个办公室，里面有个人负责审批你。然后你还得去找一个警察，基本上就是让他来看着你飞无人机。我就把所有流程都走完了，到了需要人看着我飞的那一步，我给当地警察局打电话，说，你好，我已经跟那个办公室沟通好了，我只需要一名警官在这个时间出来一下。他们直接在电话里笑我。

他们说，我们不会派一个警察去看你飞无人机。我觉得这事儿真的特别搞笑，因为确实，说得通——凭什么用纳税人的钱来看我飞无人机？但那就是规定。所以最后我也没能在 DC 飞成。不过如果有人听到这里，知道怎么飞无人机，想一起飞的话，我完全愿意。我有两架无人机，一架 Mavic Air 2，一架 Skydio Enterprise。顺便说一句，如果有人在找无人机的话，Skydio 也是一家非常酷的公司。

Lenny： 好吧，所以你的意思是，如果有人有很棒的无人机，又住在弗吉尼亚，他们应该联系你一起飞？

Austin Hay： 对，没错。但别在 DC 飞。

Lenny： 好的。Austin，我觉得我们兑现了承诺，把这次对话搞得极其硬核、极其深入细节，而且我觉得我们解决了很多人的问题。我非常感激你，也觉得我们教会了很多人营销技术方面的知识，这正是我的目标。所以再次感谢你来。最后两个问题。如果大家想问你更多问题，在网上哪里可以找到你？除了来找你一起飞无人机之外，听众们还能怎么帮到你？

Austin Hay： 首先，在网上可以找到我的地方——LinkedIn。还有 Threads，我其实有 Threads 账号。我没有 Twitter，大胆说一句，我觉得 Twitter 会毁掉人的职业生涯。我已经看到好几个人的职业生涯被 Twitter 毁掉了。有些人就是管不住嘴。所以我不在 Twitter 上，但我在 Threads 上，正在摸索怎么用。如果你想关注我在 Threads 上的动态，可以来。我在 LinkedIn 上，邮箱也挂在 LinkedIn 上，我一直愿意和大家交流。

Lenny： 太棒了。听众有什么方式能帮到你吗？

Austin Hay： 有的。我在 Reforge 上有一门营销技术课程将在秋季上线。如果你是营销技术的从业者，或者对营销技术感兴趣，非常欢迎你来上课，也特别希望能得到你的反馈。我很乐意在这个播客上装作我对营销技术很懂的样子，但我其实还在学习。所以我觉得能从社区得到反馈会很棒——哪些内容有趣、有用，哪些还缺了什么，我们可以改进。另外一件事是，如果你在找营销技术方面的帮助，欢迎随时联系我。

Lenny： 太棒了。Austin，再次非常感谢你能来。

Austin Hay： 谢谢你邀请我，Lenny。这是我的荣幸。

Lenny： 荣幸是我的。大家再见。非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或写评论，这真的能帮助更多听众找到这个播客。你可以在 lennyspodcast.com 找到往期所有节目或了解更多关于这个节目的信息。下期再见。

术语表

原文中文
a16za16z（Andreessen Horowitz 风险投资公司的简称）
AB testingAB 测试
ad network广告网络（Ad Network）
Adam FishmanAdam Fishman（播客主持人）
AmplitudeAmplitude（一家数据分析平台）
AppsFlyerAppsFlyer（一家移动归因与营销数据分析平台）
ATT应用追踪透明度（App Tracking Transparency）
attribution tools归因工具（Attribution Tools）
B2B2CB2B2C（企业-企业-消费者模式）
BranchBranch（一家移动归因与深度链接平台）
BrazeBraze（一家营销自动化平台）
Brian BalfourBrian Balfour（企业家、Reforge 联合创始人）
build and buy构建并购买
build versus buy构建还是购买
CAC客户获取成本（Customer Acquisition Cost）
cal.comcal.com（一家开源日程安排平台）
CalendlyCalendly（一家日程安排工具平台）
CDPCDP（客户数据平台，Customer Data Platform）
CFP认证理财规划师（Certified Financial Planner）
CMO首席营销官（Chief Marketing Officer）
conversions API转化 API（Conversions API）
CRMCRM（客户关系管理系统，Customer Relationship Management）
Customer.ioCustomer.io（一家营销自动化和邮件平台）
deterministic matching确定性匹配
enrichment tool数据补全工具（Enrichment Tool）
first party system第一方系统（First Party System）
first touch attribution首次触达归因
Google Click IDGoogle Click ID（Google 点击标识符）
growth ops增长运营（Growth Operations）
HightouchHightouch（一家反向 ETL 平台）
HubSpotHubSpot（一家 CRM 和营销平台）
IC独立贡献者（Individual Contributor）
IDFA广告主标识符（Identifier for Advertisers）
ITIT（信息技术部门）
land and expand渗透扩张策略（Land and Expand）
last touch attribution末次触达归因
mar ops营销运营（Marketing Operations 的缩写）
marketing operations营销运营（Marketing Operations）
MarProd营销产品（Marketing Products）
Martech营销技术（Marketing Technology 的简称）
MichaelMichael（指 Recast 联合创始人 Michael Kaminsky）
Mike TaylorMike Taylor（另一位作者）
mixed attribution model混合归因模型
MMM营销组合建模（Marketing Mix Modeling）
mParticlemParticle（一家 CDP 供应商）
MTA多点归因（Multi-touch Attribution）
MTU月度追踪用户（Monthly Tracked Users）
multi-touch attribution多点归因
MVP最小可行产品（Minimum Viable Product）
notary公证员
outbounding tool外发工具（Outbounding Tool）
performance marketer效果营销人员（Performance Marketer）
PII个人身份信息（Personally Identifiable Information）
platform PM平台 PM（Platform Product Manager）
probabilistic attribution概率性归因（Probabilistic Attribution）
probabilistic data概率性数据
probabilistic matching概率性匹配（Probabilistic Matching）
product market fit产品市场匹配（Product-Market Fit）
product ops产品运营（Product Operations）
quarterback四分卫（Quarterback）
RampRamp（一家企业支出管理公司）
RecastRecast（一家营销组合建模公司）
referrer来源页（Referrer）
ReforgeReforge（一家职业教育平台）
Rev Ops收入运营（Revenue Operations）
reverse ETL反向 ETL（Reverse Extract, Transform, Load）
SalesforceSalesforce（一家 CRM 平台）
schema数据模式（Schema）
SDKSDK（软件开发工具包，Software Development Kit）
SegmentSegment（一家 CDP/数据平台）
SnowflakeSnowflake（一家云数据仓库平台）
SnowplowSnowplow（一家开源数据收集平台）
source of truth数据真实来源（Source of Truth）
split.iosplit.io（一家功能旗标和 AB 测试平台）
SSO单点登录（Single Sign-On）
stack技术栈
Steven B. SampleSteven B. Sample（南加州大学教授、《The Contrarian’s Guide to Leadership》作者）
synthetic event合成事件（Synthetic Event）
taxonomy数据分类体系（Taxonomy）
thinking gray灰度思考
ThreadsThreads（Meta 旗下的社交平台）
UTMUTM（追踪参数，Urchin Tracking Module）
warehousing数据仓库化（Data Warehousing）
Warren BennisWarren Bennis（领导力学者）

此文档由 AI 分片翻译（translate_long_document）