返回文章列表
ABM 与细分

按职位个性化您的 B2B 网站(角色映射指南)

2026年10月15日
作者:Markettailor 团队
多元化的 B2B 采购委员会成员一起在屏幕上审阅网站

同一家3,000人公司的一位安全负责人、一位产品经理和一位采购分析师在同一周打开了您的网站。他们同属一个采购委员会,评估的是同一款产品,看到的却是同样的首页、同样的案例研究和同样的演示表单。安全负责人想要您的 SOC 2 报告,产品经理想知道团队是否真的会用,采购则想知道价格。按职位个性化网站,就是让他们每个人首先看到能回答自己问题的页面。

这件事也比听起来难,而大多数指南都跳过了难点。行业和公司规模几乎可以通过首次浏览时的 IP 查询免费获得。职位则不然:职位属于个人,而在大多数 B2B 网站上,个人是匿名的。本指南讲的是如何实事求是地做基于角色的个性化。内容包括使用哪些角色、如何把杂乱的职位名称归类到这些角色、角色数据实际从哪里来(以及从哪里来不了)、每个页面上要改什么,以及如何判断这些改动是否奏效。

为什么角色很重要,又为什么总被跳过

B2B 采购是集体决策。Forrester 2024 年买家旅程调研发现,平均每个采购决策有 13 人参与。每个人带着不同的问题浏览您的网站。客户级个性化可以识别出有人来自德国一家物流公司,但会把该公司的所有人都当作同一个读者。角色这一层,才能把 CFO 和工程师区分开来。

团队跳过这一步有个现实原因:数据太少。反向 IP 查询识别的是公司,而不是个人。只有当某人已经在您的 CRM 中、通过针对该职位的营销活动进入网站,或者其行为暴露了身份时,您才知道他的职位。因此,角色个性化永远只能覆盖少数会话,项目必须围绕这一事实来设计,而不是假装每个访客都能被打上标签。

我们的立场:在行业或规模个性化已经运行之后,再加入角色维度是值得的,而且它在三个页面上最有价值(首页、价格页、演示申请表)。不要一开始就做角色个性化,也不要构建二十个用户画像。

最值得优先按其细分的四种角色

四个分组足以覆盖采购委员会的分工方式。再多的话,每个细分获得的流量就太少,无法衡量。

角色典型职位想了解阅读正确的 CTA
经济决策者CEO、CFO、掌握预算的副总裁成本多少、回报多少、合同是什么样的价格、ROI 内容、附带成果的客户案例价格与 ROI 测算表、与资深销售代表通话
技术评估者CTO、安全负责人、架构师、工程经理架构、集成、安全、数据处理文档、API 参考、安全与信任页面架构概览、不含销售推介的技术简报
实践者分析师、运营经理、专员这能让我的工作轻松些吗?学会它要多久?功能页、教程、截图、帮助中心产品导览、沙盒环境或录制的演示
内部支持者总监、高级经理、团队主管、产品经理我能否在内部推动采购,我的团队能得到什么对比页、同行客户案例、ROI 资料内部推介材料包、客户参考电话

内部支持者是大多数网站服务最不到位的角色。这个人不签合同,但负责撰写促成签约的内部邮件。给他们一些可以转发的东西(一页摘要、一份对比、一份安全常见问题),往往是整个项目中成本最低的胜利。

职位到类别映射表

难点不在于写规则,而在于把您实际从 CRM、表单提交和数据供应商(ZoomInfo、Apollo、6sense 等)那里获得的自由文本职位,映射到上述四个类别中。请将下表作为初始分类体系,并根据您的市场进行调整。

类别C 级高管 & 副总裁总监 & 负责人经理和主管个人贡献者
经济决策者CEO、CFO、COO、CRO、首席营收官、总裁、财务副总裁、运营副总裁、采购副总裁财务总监、采购总监、运营总监、财务负责人、采购负责人财务经理、采购经理、采购员、品类经理采购专员、财务分析师(具有采购权限)
技术评估者CTO、CIO、CISO、首席架构师、首席数据官、工程副总裁、技术副总裁、安全副总裁、IT 副总裁、数据副总裁、平台副总裁工程总监、平台总监、基础设施总监、安全总监、工程负责人、平台负责人、安全负责人工程经理、技术负责人、架构师、解决方案架构师、安全工程经理高级工程师、主任工程师、首席工程师、安全工程师、DevOps 工程师、SRE
一线使用者 / 最终用户(在这一层级很少见)(在这一层级很少见)营销经理、运营经理、销售运营经理、RevOps 经理分析师(营销、销售、业务、数据)、专员、协调员、助理、研究员、初中级工程师
内部支持者 / 影响者营销副总裁、产品副总裁、客户成功副总裁(当其不是经济决策者时)市场总监、产品总监、需求生成总监、增长总监、营销负责人、产品负责人、增长负责人高级经理、产品经理、高级产品经理、项目经理、团队负责人(很少从这里开始)

关于这张表的一点说明:同一个职位在不同产品中的含义不同。如果您销售的是营销软件,营销副总裁就是您的经济决策者,而不是内部支持者。使用这张表之前,请根据您产品所服务的职能重新排列各行。

如何处理含义模糊的职位头衔

很多职位无法清晰归类。以下默认规则覆盖了常见情况:

  • 职能不明确的“X 总监”:默认视为内部倡导者。头衔笼统的总监,更多是在内部推动,而不是签字拍板的人。
  • 50人以下公司的“X 负责人”或“副总裁”:视为经济决策者。在这种规模下,职能负责人通常掌握预算。
  • 高级和资深工程师或分析师:属于实际使用者,除非公司规模在30人左右以下,此时决策权足够扁平,可以把他们视为技术评估者。
  • 产品经理:内部支持者。他们很少掌握预算,但经常主导供应商评估。
  • 顾问和外包人员:按职位中的职能归类(“Marketing Consultant”归为实际使用者)。他们有影响力,但很少是购买者。
  • 小公司的老板或创始人:经济决策者。
  • 空白或笼统的职位(“员工”“技术人员”“工程师”):归入未映射类别,这类会话依靠行为数据判断。

把映射关系作为一张查找表保存在个性化工具或 CDP 中,而不是在每条页面规则里重复写逻辑。这样市场部只需在一处修改类别,更换数据供应商时也不必重写分类体系。

角色数据究竟从何而来

避免使用“选择您的角色”弹窗。大多数访客会直接关掉,有些人出于好奇会点一个不同的角色,而您给所有人都增加了摩擦。请改用以下来源,大致按可信度排序:

来源工作原理可靠性注意事项
已知联系人的 CRM 记录在填写表单或点击邮件后,通过 Cookie 匹配的回访访客高:职位已有记录职位信息会过时;至少每年从数据供应商处刷新一次
广告系列定向UTM 显示访客来自针对某一角色的广告或邮件(例如按职能定向的 LinkedIn 广告系列)中到高定向会外溢;同事之间会转发链接
站内行为会话中阅读的页面揭示了访客在问什么问题中等,页面越多效果越好需要两次或以上页面浏览才能给出判断
个人层面识别供应商第三方声称能将匿名访客匹配到个人差异很大,主要覆盖美国在 GDPR 下,这属于个人数据处理,需要合法依据;对欧盟流量开启之前请先核实

公司级访客识别可以与这些方法配合使用:它不会告诉您这个人的职位,但会告诉您是哪家公司,让您能把角色与行业和规模结合起来。我们关于将网站个性化数据连接到 CRM 的文章介绍了如何把已知联系人的职位回传给网站。

推断角色的行为规则

对于匿名访客,行为是主要信号。起步阶段,简单规则胜过复杂模型,因为规则可以解释、也可以检验:

  • 一次会话中两次及以上浏览价格或 ROI 内容:经济决策者。
  • 浏览文档、API 参考或安全页面两次以上:技术评估者。
  • 浏览功能页、教程或产品导览两次及以上:一线使用者。
  • 一个案例研究加一个对比页或替代方案页:内部支持者。
  • 其他情况:无角色,显示默认版本。

当数据来源冲突时,使用优先顺序而不是取平均值:CRM 中的职位优先于广告活动背景,后者又优先于行为。只有当行为信号强烈且新近时,才应覆盖 CRM 中的职位(一位已知的“营销经理”本周读了四个 API 页面,说明他在这次采购中扮演的是技术评估者)。我们关于B2B 网站行为细分的文章更深入地介绍了评分方面的内容。

上线前,用实际情况检验您的规则。取上季度填写过演示申请表的联系人,查看他们转化前浏览过的页面,对比您的规则会为他们分配的角色与其真实职位。如果规则对其中很多人的角色判断有误,请在任何人看到个性化页面之前先修正规则。

按角色调整每个页面的内容

角色个性化并不意味着每个页面都写四遍。在每个页面上改动二到四个元素,其余保持不变。

首页

修改首屏标题、重点信任证明和主要 CTA。示例文案(仅作说明,针对一款虚构的分析产品):

角色首屏标题展示的证明材料主要 CTA
默认了解哪些账户已准备好购买Logo 栏预约演示
经济决策者看看您的网站已经在创造哪些销售管道财务或营收负责人谈论成果的引言查看价格和 ROI 工作表
技术评估者只需一个脚本标签,无需改动现有技术栈安全认证、集成标志阅读架构概述
实践者一个下午就能建好您的第一个细分日常工作流程截图体验产品导览
内部支持者您的团队本季度能交付什么来自同类团队的客户案例获取内部推介资料包

我们的首页个性化实战手册介绍了首页的其余部分。在已经做了个性化的元素上叠加角色维度,而不是再开辟新的元素。

价格页

这是各角色差异最大的地方。经济决策者想知道合同期内的总成本以及如何证明其合理性,所以应以年度视图和 ROI 计算表开篇。技术评估者想知道每个档位包含什么:API 限制、SSO、数据驻留、支持级别。一线使用者想知道每个套餐实际能做什么。内部支持者则需要能拿给财务部门的东西:一页包含商业论证和两个参考客户的摘要。

对所有角色保持价格本身完全相同。改变表述方式没问题;但同一家公司的不同人看到不同的数字,一旦他们互相对照,您很快就会失去信任。更多内容请参阅我们关于B2B 价格页个性化的文章。

产品和功能页面

产品页面需要改写的最少。改变首屏的内容即可:为技术评估者展示架构图和集成列表,为一线使用者展示工作流程截图和教程,为经济决策者和内部支持者展示来自类似公司、以成果为导向的案例研究。第一轮先保持功能列表本身不变。

演示表单

表单是不匹配代价最大的地方。经济决策者想知道谁会参加通话、需要多长时间;技术评估者往往想要技术交流或文档,而不是销售电话;执行者想在不开会的情况下看到产品。在标准演示申请旁提供适合角色的替代选项(例如为评估者提供“技术简报”选项),能留住那些原本会离开的人。

实例:一个账户,三位访客

示例说明:一家600人的物流软件公司正在评估一款报表工具。两周内,该公司有三个人访问了网站:

  1. 访客 A 来自一个面向财务岗位的 LinkedIn 广告活动,看了两次价格页。角色:经济决策者(广告活动与行为一致)。价格页首先展示年度成本视图和 ROI 计算表。
  2. 访客 B 是匿名的,阅读了 API 参考文档、安全页面和集成列表。角色:技术评估者(依据行为)。下次访问时,首页主视觉切换为“无需改动您的技术栈”版本,演示表单则提供技术简报。
  3. 访客 C 是一位已知联系人(一年前填写过网络研讨会表单),职位为“高级产品经理”。角色:支持者(CRM 职位)。他们会看到同行客户案例和内部推介资料包 CTA。

与此同时,公司级识别显示两周内有同一客户的三个人来访,这是采购小组信号,无论角色如何,销售都应该知道。角色改变的是每个人看到的内容;客户视角决定的是销售何时介入。我们关于客户评分的文章介绍了后半部分。

60天上线计划

  1. 第 1 至 10 天:角色推断。导入职位映射表,接入 CRM 中的职位,编写行为规则,并用上季度的演示申请进行回测。
  2. 第11至25天:首页。每个角色一个首屏、证明材料和 CTA 版本,另设一个持续看到默认内容的保留组。在上线前用 A/B 测试计划确定成功指标。
  3. 第26到40天:价格页。只改变表述方式和主 CTA。价格文案会带来商业后果,所以第一轮迭代要小。
  4. 第 41 至 55 天:产品页面。首屏的重点内容,以及功能列表下方的客户案例。
  5. 第56至60天:复盘。将每个角色细分与其保留对照组比较。保留在可信样本下胜出的变体,淘汰其余的,并决定下一步为哪个角色制作新内容。

如果您的流量较小,就精简计划:一个角色、一个页面、一个月。在首页针对技术评估者做测试是很好的开端,因为行为信号清晰,相关内容通常也已经存在于您的文档中。

毁掉基于角色个性化的常见错误

角色太多。画像文档常常列出十个甚至更多角色。每多一个角色,流量就被进一步分散,直到什么都无法衡量。第一个季度四个角色就足够了。

没有默认体验。大多数会话永远不会获得角色标签。默认页面本身必须足够好;角色变体是对它的补充,而不是替代。

改了文案却没改 CTA。一个面向财务的标题后面跟着“立即开始构建”,前面的功夫就白费了。行动号召必须与该角色的下一步动作相匹配。

把每次访问都当作第一次。第四次来访的 CFO 早已看过您的推介。除了角色,还要根据访问次数进行调整,例如从 ROI 测算表转为直接提供会议邀约。

只看角色、不看公司背景。50人初创公司的 CFO 和5,000人大型企业的 CFO 关注点完全不同。请将角色与至少一个企业属性维度结合起来;我们的按公司规模个性化指南是一个天然的基础层。

忽视隐私。向访客展示“欢迎您,财务部的 Jane”会让人毛骨悚然,而在欧盟,视您获取数据的方式而定,还可能违法。按角色做个性化要不动声色:改变强调的内容,绝不宣告您知道什么。

如何衡量

在细分层面进行衡量。全站转化率会因许多与角色变体无关的原因而变化。每周跟踪以下指标:

  • 每个角色细分群体相对其自身保留组的转化率。没有提升的角色需要新的版本。
  • 角色覆盖率:获得角色标签的会话占比。覆盖率低会限制效果;突然跃升通常意味着某条规则变得过于宽松。
  • 标签准确性,每月通过比较推断的角色与后来转化者的职位进行核查。
  • 下游质量:来自个性化会话的线索转化为合格商机的比例,是否高于来自保留对照组的线索。

Markettailor 的细分功能让您可以基于 CRM 字段、广告系列参数和页面行为定义角色细分,并对照对照组报告各细分的转化率。无论使用什么工具,衡量设计都比工具本身更重要。

从一个角色和一个页面开始

选定技术评估者,为他们写一个首页主视觉,与默认版本对比运行一个月。如果胜出,再加入价格页或第二个角色。如果没有,您也就以一个标题的代价,弄清了这类受众不关心哪个问题。

想看看角色细分如何与公司级识别结合作用于您自己的流量,请在我们的价格页上预约演示讲解。