mcpField
F
funnel-flow-architecture

funnel-flow-architecture

github.com/rampstackco营销与增长1.0k264 次安装1 周前更新
代码仓库

关于 funnel-flow-architecture

面向增长与营销团队的转化漏斗架构方法,涵盖受众、阶段、入口和工具。重点是连接各工具与培育流程,为不同细分群体规划后续路径。

主要功能

  1. 01受众与阶段细分
  2. 02入口路由设计
  3. 03工具与漏斗映射
  4. 04培育序列架构
  5. 05跨工具数据流

适用场景

  1. 01从零设计转化漏斗
  2. 02审查转化停滞的增长计划
  3. 03规划细分群体的漏斗路径

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/rampstackco/claude-skills --skill funnel-flow-architecture

安装后在 Claude Code 中输入/funnel-flow-architecture确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
references/
architecture-anti-patterns.md
audience-and-stage-segmentation.md
common-funnel-architecture-failures.md
cross-tool-data-flow-patterns.md
entry-point-architecture-patterns.md
funnel-iteration-discipline.md
funnel-measurement-patterns.md
nurture-sequence-architecture.md
tool-to-funnel-mapping.md

详细介绍

漏斗流程架构

资深增长从业者的实战指南:如何设计跨工具转化流程,使其匹配受众和所处阶段。从落地页到引流资源,再到培育序列、优惠方案和进阶漏斗。重点在于构建漏斗架构,而不只是收集工具。

大多数增长项目会不断积累工具,却没有架构。聊天机器人、计算器、测验、引流资源、新闻简报订阅和演示 CTA。每种工具单独使用都有效,但彼此之间没有配合。访客使用一种工具后就离开,永远不会进入更广泛的培育序列。漏斗成了一堆互不关联的工具。

能够持续增长的项目会采取不同做法:有意识地设计漏斗。不同入口通向不同的培育序列。不同阶段使用不同的 CTA。不同工具服务于不同细分受众。每种工具都是整体架构的一部分,而不是独立的产物。

此技能是一项架构技能,用于统筹其他 5 项增长工具技能(lead-magnet-design、calculator-design、quiz-and-assessment-design、multi-step-form-design、chatbot-flow-design)。这些技能聚焦于特定工具的设计,而此技能着眼于跨工具架构,决定这些工具能否相互配合、形成累积效应。

此技能采用资深增长从业者的口吻:他们见过精心设计的漏斗架构如何形成累积效应,也见过孤立的漏斗工具集合如何带来互动指标,却对业务毫无助益。务实,明确指出收集工具与设计漏斗架构之间的区别,并愿意直言某个团队的增长项目需要的是架构,而不是再添一种工具。

适用场景:从头设计漏斗;审查工具各自有效但转化率停滞不前的增长项目;设计跨工具数据流,以便在各个触点捕捉受众信号;或确定哪些细分受众需要采用哪些漏斗路径。


此技能涵盖的内容

此技能涵盖跨工具漏斗架构。增长工具领域的技能分工如下:

  • lead-magnet-design、calculator-design、quiz-and-assessment-design、multi-step-form-design、chatbot-flow-design 是此技能设计的漏斗架构中使用的工具。这些技能聚焦于特定工具的设计。
  • content-distribution 涵盖内容如何触达受众。此技能关注受众触达内容后会做什么。
  • experiment-design 用于验证漏斗变更。此技能设计架构;experiment-design 对其进行测试。
  • landing-page-copy 涵盖页面层面的文案。此技能关注跨页面架构。
  • **funnel-flow-architecture(此技能)**涵盖受众与阶段细分、入口架构、工具与漏斗的映射、培育序列架构以及跨工具数据流。

目标受众:中小型及中型市场公司的增长营销负责人、产品营销负责人、营销总监;为客户运营漏斗架构的代理机构;以及从头设计增长项目的创始人。

不在涵盖范围内:特定工具的设计(由 5 项配套的增长工具技能涵盖);内容分发机制(由 content-distribution 涵盖);A/B 测试方法(由 experiment-design 涵盖);页面层面的文案(由 landing-page-copy 涵盖)。


孤立式漏斗 vs 一锅端式漏斗 vs 匹配式漏斗

核心框架。

孤立式漏斗。 每个工具(聊天机器人、计算器、潜在客户引流工具、测验)都独立存在。没有协同流程;用户使用一个工具后便离开,永远不会进入更广泛的培育序列。工具彼此孤立。代价:每个工具的投入都无法产生复利效应;与某个工具互动的受众不会被引导至任何后续步骤;团队有工具,却没有架构。

一锅端式漏斗。 所有人共用一个漏斗。无论受众或入口是什么,培育序列都相同。中小企业和企业客户收到相同的电子邮件。新访客和漏斗底部用户看到相同的行动号召。每个细分群体的转化率都会退化到平庸水平。代价:漏斗针对平均水平进行优化;没有任何细分群体得到妥善服务;下游转化率普遍偏低。

匹配式漏斗。 漏斗架构与受众和阶段相匹配。不同入口会进入不同的培育序列;不同阶段会看到不同的行动号召;不同工具服务于不同细分群体。每个工具都是更大架构的一部分,而不是独立产物。代价:前期设计工作量很大;维护确实需要投入;各细分群体的下游转化率会显著提高。

试金石。选一位最近访问过网站的访客。团队能否说明这位访客属于哪个细分群体、使用了哪个入口、处于哪个培育序列,以及会看到什么下一步行动号召?如果能,说明这是匹配式漏斗。如果答案是“他们和其他所有人走的都是同一套流程”,说明这是一锅端式漏斗。如果答案是“他们用过计算器,但我不知道接下来会发生什么”,说明这是一条孤立式漏斗。


受众与阶段细分

基础。

原则。 漏斗架构从受众和阶段细分开始。没有细分,每位访客都会走同一条路径;漏斗就无法实现匹配。

受众维度。

  • 公司规模或买家类型。 个人、SMB、中型市场、企业。
  • 行业或垂直领域。 医疗保健、金融、零售、技术。
  • 用例。 受众想要完成什么。
  • 角色。 创始人、产品经理、营销人员、高管、个人贡献者。
  • 来源。 付费流量、自然流量、推荐、合作伙伴。

阶段维度。

  • 认知。 刚刚发现品牌或相关主题。
  • 考虑。 正在积极评估选项。
  • 决策。 在具体选项之间做出选择。
  • 客户。 已经是客户;处于持续关系中。

交集。 受众 x 阶段构成漏斗架构所服务的矩阵。处于考虑阶段的企业产品经理,与处于认知阶段的 SMB 创始人属于不同的细分群体;两者各自需要不同的路径。

细分纪律。 从 3-5 个受众群体和 3 个阶段开始。矩阵中共有 9-15 个单元格。有些单元格可以共用路径;有些可能需要独特路径。关键是有意识地为细分群体命名,而不是把“所有人”都视为目标受众。

详情见 references/audience-and-stage-segmentation.md。


入口点架构

访客如何到达,以及他们会被引导到哪里。

原则。 漏斗架构将入口点(访客到达的位置)映射到细分群体和路径(他们接下来会做什么)。

常见入口点。

  • 付费落地页。 访客通过广告到达;意向较强;内容针对广告所承诺的内容。
  • 自然流量内容页。 访客通过搜索或内容发现到达;处于认知或调研阶段。
  • 直接访问。 访客输入 URL 或通过书签访问;通常是回访访客。
  • 推荐。 访客通过合作伙伴或口碑到达;比付费流量更有意向。
  • 社交媒体。 访客通过社交媒体帖子到达;处于认知或兴趣阶段。
  • 工具入口。 访客直接通过计算器、测验或聊天机器人到达。

入口点路由。

  • 每个入口点都有预期的细分群体和阶段。
  • 入口点提供的第一个操作应符合访客可能所属的细分群体和所处的阶段。
  • 不同入口点可以通往不同的后续工具和序列。

示例。 通过一则关于“B2B SaaS 定价”的付费广告到达的访客,很可能处于考虑阶段,正在寻找定价信息。落地页应满足这一需求(清晰的定价、对比、计算器);下一步的推荐应符合考虑阶段(预约演示、联系销售)。同一位访客通过一篇关于“B2B SaaS 定价策略”的自然流量博客文章到达时,很可能处于认知阶段;落地页应提供教育内容(深入介绍定价策略);下一步的推荐应符合认知阶段(订阅内容、获取框架)。

详见 references/entry-point-architecture-patterns.md。


工具到漏斗的映射

哪些工具适用于哪些入口点。

原则。 增长工具包中的每种工具在漏斗架构中都有自己的位置。工具面向特定入口点,为特定阶段的特定细分群体提供服务。

映射示例。

  • 潜在客户引流内容。 通常用于认知到考虑阶段的过渡。收集到的电子邮件地址会进入培育序列。
  • 计算器。 通常用于考虑阶段。正在评估选项的受众会使用计算器,为某个具体决策提供依据。
  • 测验。 根据设计,可用于任何阶段。用于内容营销的测验面向认知阶段;用于产品匹配的测验面向考虑阶段;用于方案选择的测验面向决策阶段。
  • 多步骤表单。 通常用于决策或资格筛选阶段。该表单用于收集符合资格的意向信息。
  • 聊天机器人。 可贯穿各个阶段。借助意向识别进行路由,可服务任何阶段。

工具与细分群体的契合度。 工具应服务于与其价值主张相匹配的细分群体。面向独立创始人的计算器,其输入项和输出结果可能需要与面向企业买家的计算器有所不同;同一个计算器无法同时很好地服务两者。

工具组合策略。 团队通常会使用多种工具来服务不同的细分群体。架构会将每种工具映射到其对应的细分群体和阶段。

详见 references/tool-to-funnel-mapping.md。


培育序列架构

按细分受众、按阶段划分。

原则。 不同细分受众处于不同阶段时,应收到不同的培育序列。序列应契合受众的处境和所处阶段。

按阶段区分序列。

  • 认知阶段序列。 以教育为主;提供广泛价值;建立品牌形象。有软性推广时,也应保持克制。
  • 考虑阶段序列。 强调对比;提供具体价值;展示产品契合度信号。加入演示或试用 CTA。
  • 决策阶段序列。 建立信心;降低风险;营造紧迫感。加入直接购买或承诺 CTA。

按受众区分序列。

  • 面向企业受众的内容(白皮书、案例研究、投资回报分析)应与面向中小企业受众的内容(模板、快速见效方案、同行评价)有所区别。
  • 不同角色需要不同的表达方式(面向创始人的内容强调业务成果;面向 IC 的内容强调从业者视角的深度)。
  • 不同行业需要不同的示例和语言。

大杂烩式序列的失败之处。 所有人都收到同一套序列。内容足够通用,可以发给所有人;却又不够具体,无法满足任何人的需求。转化率普遍平平。

匹配式序列的成功之处。 序列针对细分受众和阶段量身打造。受众会觉得品牌理解自己的处境;转化效果也会不断累积。

详见 references/nurture-sequence-architecture.md。


跨工具数据流

在不同工具之间传递上下文。

原则。 受众在漏斗中从一种工具转到另一种工具时,其信号也应随之传递。聊天机器人的对话上下文会影响计算器的默认值;计算器输入会影响潜在客户磁铁的序列;测验结果会用于预填演示申请表单。

跨工具数据流模式。

  • 身份贯穿。 受众在任何环节被识别后(登录、选择订阅或通过电子邮件识别),其身份都会在各工具之间延续。
  • 上下文捕获。 某个工具的输入(计算器数值、测验结果、表单提交内容)会传递到下一次交互中。
  • 细分受众标记。 每次交互都会为受众添加细分信息标签,用于后续路由。
  • 序列与工具集成。 电子邮件序列包含特定工具的链接,并与受众的细分类型相匹配。

工具各自为政的失败之处。 每个工具只捕获自己的数据,工具之间没有数据流转。用户打开计算器后,聊天机器人中的对话内容就被遗忘;用户打开潜在客户磁铁后,计算器中的输入也被遗忘。

漏斗集成的成功之处。 数据得以流转。受众体验连贯;品牌也能根据受众的具体旅程匹配内容和优惠。

详见 references/cross-tool-data-flow-patterns.md。


漏斗衡量

衡量什么,哪些只是噪声。

原则。 漏斗衡量应揭示架构质量,而不只是工具质量。

架构层面指标。

  • 跨工具转化。 触达工具 A 的受众中,有多少比例随后与工具 B 互动?
  • 序列到工具的转化。 培育序列订阅者中,有多少比例会与下游工具互动?
  • 细分受众的下游转化。 各细分受众转化为项目主要目标(试用、演示、购买)的比例。
  • 漏斗阶段推进。 随着时间推移,有多少比例的受众会从认知阶段进入考虑阶段,再进入决策阶段?

工具层面指标。

  • 各工具的转化率(由各工具对应的技能涵盖)。

架构层面与工具层面。 工具层面指标告诉你每个工具是否有效;架构层面指标则告诉你这些工具能否协同运作。两者都很重要;架构层面的衡量往往是缺失的一环。

详见 references/funnel-measurement-patterns.md。


漏斗迭代纪律

何时重新设计,何时优化。

原则。 漏斗架构经优化后会产生复利效应;不断重新设计则会使其崩塌。关键在于判断何时该采取哪种做法。

优化时机:

  • 特定工具的表现低于基准水平。
  • 特定细分群体的转化率低于同类群体。
  • 漏斗中的特定环节导致用户流失。
  • 特定群体的序列参与度正在下降。

重新设计时机:

  • 受众构成发生了根本性变化。
  • 产品或服务策略发生了变化。
  • 竞争格局发生了重大变化。
  • 多轮优化都没有取得预期效果,表明可能存在架构问题。

不断重新设计的陷阱。 不断重新设计的团队永远无法从架构的复利效应中获益。每次重新设计都会重置学习成果,无法积累任何经验。

架构僵化的陷阱。 从不迭代的团队只能眼看着架构随着受众和市场的演变而逐渐衰退。

折中之道:持续优化;谨慎而有目的地重新设计,且少为之。

详见 references/funnel-iteration-discipline.md。


架构反模式

这些模式看起来像漏斗架构,却会降低转化率。

各自为政的漏斗模式。 工具彼此孤立;没有架构。

大杂烩式漏斗模式。 面向所有人只建一个漏斗。

过度细分的漏斗。 细分太多,导致维护工作无法完成;各细分群体实际上也无法区分。

缺乏维护的漏斗。 架构设计完成后便从未审查;问题不断累积。

以工具为中心的架构。 架构围绕工具组织,而不是围绕受众和阶段组织;无论是否有利于受众,每种工具都各自拥有一个漏斗。

不看指标的架构。 架构没有衡量机制;无法诊断哪些地方有效,哪些地方无效。

单工具漏斗。 架构依赖单一工具(只有计算器,或只有聊天机器人);如果该工具表现不佳,便毫无韧性。

交接失灵的漏斗。 工具各自运行正常,但彼此之间的衔接出现故障。

详见 references/architecture-anti-patterns.md。


框架:漏斗流程架构的 12 项考量

设计或审查漏斗架构时,请逐一检查以下 12 项考量。

  1. 采用匹配式漏斗,而非各自为政或大杂烩。 架构应匹配受众与阶段;每种工具都是架构的一部分,而不是独立产物。
  2. 明确划分受众和阶段。 3-5 个受众 x 3 个阶段;这是架构服务的矩阵。
  3. 绘制入口点架构。 将每个入口点引导至预期的细分受众和阶段。
  4. 记录工具与漏斗的映射关系。 每种工具都服务于特定阶段的特定细分受众。
  5. 为每个细分受众设计培育序列架构。 序列应随受众和阶段变化,而非所有人共用一个序列。
  6. 整合跨工具数据流。 上下文在工具间传递,让受众体验保持连贯。
  7. 跟踪架构层面的指标。 跨工具转化率、从序列到工具的转化率、细分受众层面的后续转化率。
  8. 遵循漏斗迭代规范。 持续优化;有计划地重新设计;避免走向两个极端。
  9. 平衡工具组合。 使用多种工具服务不同细分受众;不要过度依赖任何单一工具。
  10. 如实评估受众匹配度。 架构服务于品牌实际能够服务的细分受众;不匹配的受众应予以筛除或引导至其他渠道。
  11. 明确维护责任。 指定架构负责人;将季度审查列入日程。
  12. 制定扩展计划。 添加新工具时,架构应明确其适用位置;新工具必须证明其价值,而不是被装饰性地添加进来。

该框架的产出是一种随时间不断积累效益的漏斗架构,它匹配受众与阶段细分,整合工具数据流,并带来可衡量的后续转化。


如果无法获取所需数据

此技能的输出依赖于它无法独立生成的数据、测量结果或工具结果。如果所需输入、工具或数据源不可用或无法验证,经认可的输出方式是交付成果并说明缺口:需要什么、实际获取或验证了什么,以及输出中哪些部分受到影响。绝不允许为了完成交付成果而捏造、估算或插补所需数字。说明缺口本身就是完整的答复。


参考文件


总结:漏斗是架构,而不是工具集合

能够持续积累成效的增长计划,都是经过精心设计的漏斗架构。不是收集工具,也不是一次只优化一个工具,而是设计架构。

架构决定了工具是只能带来互动,还是能让漏斗产生业务成果。聊天机器人、计算器、测验、潜在客户磁铁、多步表单:每一个都是工具,但没有一个是漏斗。漏斗是让这些工具协同运作的架构。

这才是合格标准。低于标准的是各自孤立的漏斗(工具彼此孤立)和大杂烩式漏斗(所有人走同一条路径)。高于标准的是匹配式漏斗:通过受众和阶段细分,推动入口路由、工具与漏斗的映射、培育序列设计、跨工具数据流,以及架构层面的衡量。

总结:漏斗通过协同创造价值,才值得投资

增长工具包中的每个工具,都需要投入成本来构建和维护。工具协同运作时,投资会不断增值;工具各自为营时,投资则会被稀释。架构就是组织协同的实践。

复利机制如下:访客到来后,架构会根据入口和可观察信号为其分流。他们遇到的第一个工具服务于其细分受众和所处阶段。他们产生的数据会为其接触的下一个工具提供参考。他们进入的序列与其背景相匹配。每一次互动都会加深品牌对受众的了解;每个工具的贡献都会与其他工具相互叠加。

如有疑问,不妨问问:计划中的每个工具是否服务于明确的细分受众和阶段?工具之间是否共享数据和背景?团队能否用一张图解释架构?团队是否衡量架构层面的成果(而不只是工具层面的指标)?如果这些问题的答案都是肯定的,那么这个漏斗就是真正的架构。如果其中任何一个答案是否定的,那么这就是计划中的工具未能协同运作之处。

评论

支持 Markdown