衡量开发者关系

2025-06-04

衡量开发者关系

“比赛的胜利属于专注于比赛场地的球员，而不是那些眼睛盯着记分牌的球员。”——沃伦·巴菲特

图片描述

几年前，一次 DevRelCon 会议的核心主题是“指标”。大家在推特上激动地讨论着，这在 DevRel 中是最重要的话题，大家也达成了共识。为期两天的会议日程安排得满满当当，48 位演讲者都名声显赫，按粉丝数量排名。数百名 DevRel 成员飞来聆听 DevRel 的思想引领。大家畅饮，握手，许下空洞的承诺。然后，他们各自回家。

一切都没有改变。 2021年的今天，人们仍在谈论衡量DevRel（开发者关系）有多么困难。这场备受期待的付费活动的完整演讲视频在YouTube上发布，每张门票价值数百美元，总观看次数为601次（没错，是拼写错误）。组织者出色地争取到了18家赞助商，但都被他们无视了。我的公司就是其中之一，花了数千美元买了一个黄金席位，只拿到了4张门票，大概是为了学习DevRel的最佳实践，并招聘优秀人才。我们一个也没派人来。

我确实挑了一个令人震惊的轶事，但它有助于说明当今 DevRel 问责制的典型状况。充斥着喧嚣，却又令人质疑。“DevRel” 表现得非常出色，却与“ Con ”难以区分。然而，尽管缺乏透明度，公司仍在继续投资！因为我们知道，在所有这些喧嚣和热情的交锋中，确实创造了一些价值，而这些价值是所有其他可用的用户获取渠道所独有的。

我当然没有完美的答案。但我已经经历了一段时间，想写下我不断演变的想法，为那些正在走这条路的人提供参考。我不会提供解决方案，而是提供框架。我不会回答你的问题，而是希望提供更好的解决方案。

注意：我为 DevRel 新手以及正在运行 DevRel 项目的人员撰写文章。这是一篇“201”博客文章，而不是“101”——我的目标是涵盖入门博客文章未提及的内容。由于我浓缩了大量想法，因此我的大写字母和语调可能会不一致，相信您足够聪明，能够理解。有时“DevRel”指的是一个人（实际上拥有“开发者倡导者”或“DX 工程师”的头衔），有时“Devrel”指的是一个行业。如果您对此感到不安，请阅读其他内容。

底线在前

替代文本

别再纠结了：你的北极星指标是“月活跃开发者”。如果增长加速，那就好。如果增长稳定，那就没问题。如果增长率为 0% 甚至更低，那么你所做的一切都没有效果。

  • 其他所有衡量 Devrel 的公司最终都会选择这个，所以直接开门见山吧。你可以尝试“月活跃集群”，但你肯定希望每个集群的使用量也能增长，所以最终还是会以“开发者”为索引。
  • 然而，MAD是多因果关系，并且是一个滞后指标，因此您需要能够更直接控制的领先指标。

您是哪种类型的 DevRel？

图片描述

当公司对 DevRel 的期望与每个 DevRel 的专长不匹配时，就会产生不满。人们之间有天然的亲和力——如果你已经组织过聚会，你更有可能在社区中表现出色；如果你经常参加演讲，你更有可能在内容方面表现出色；如果你已经建立了产品反馈，你更有可能了解如何利用产品反馈来弥补用户的不足，等等。不要以鱼与熊掌不可兼得。

开发者关系领域出现了三个新兴的分支专业：以社区为中心、以内容为中心和以产品为中心。如何衡量你的能力取决于你的优势以及你的公司对开发者关系的理解。我们将逐一探讨每个专业，但首先介绍一下背景：

  • 许多公司会宣称，他们与开发者关系的方法与开发者宣传不同，因为它是一条“双向道”，这意味着你把产品放在人们面前，同时也把人们的意见带回到产品中。
    • 实际情况是，双向流量的比例通常是 99% 为出站流量，1% 为入站流量，因为产品/工程部门没有为 Devrel 的“影子 PM”预留任何带宽，而 Devrel 的所有指标都集中在出站流量上。这完全可以理解，但可以做得更好。
  • 如果你身处“devrel”（联盟营销），但你行事风格像营销，说话像营销，衡量标准也像营销，那么你就是营销。事实上，你从事的是非常昂贵的联盟营销。
    • 如果以观看量来衡量开发者关系，那么行业公认的衡量标准是“每千人成本”，即每千人触达的成本。参考数字：典型的开发者内容创作者的每千人成本 (CPM) 为 5 美元，而普通开发者关系的每千人成本 (CPM) 为 50-100 美元。换句话说，相比聘请“专业人士”制作关于你的内容（通常质量更高，受众更广），你“内部”制作内容的费用要高出 10-20 倍。
    • 像Draft和Ironhorse这样的开发内容机构确实存在，但它们只是一种尴尬的半解决方案，它们既不会带来观众，也不会与你的产品建立深厚的关系。
  • 因此，要使公司 Devrel 投资有意义，你必须提供一些除了原始匿名覆盖范围之外的其他形式的价值。这些价值可以是：深度、广度、一致性、访问量、洞察力、社区、电子邮件列表构建等等。
    • Devrel 特别作为一门独立于营销的学科而存在，因为开发人员讨厌营销废话，而自下而上 + 开源销售对于 devtool 的采用非常重要。
    • 职业营销人员很难与开发人员建立联系，因为很多传统观念都被颠倒了——你必须推销功能，而不是好处，并且要准备好深入探讨恰到好处的技术细节，而不是使用模糊的夸张​​辞藻。然而，营销人员在向组织的其他部门推销产品方面仍然非常有用。

糟糕的指标

我被要求在工作中衡量所有这些指标：GitHub 上我演示的 star 数量（真恶心），Google Analytics UTM 标签带来的流量（真恶心），我在会议上可以扫描的徽章数量（真恶心真恶心）。所有这些指标的出发点都是好的，但最终却毫无意义，因为它们重视数量而非质量，重视广度而非深度，重视免费和肤浅，而不是付费并表明认真关注。

  • 有时这些被认为是“有总比没有好”，但一旦到位，指标就会对想象力产生奇怪的影响：我曾经有一位 CTO 粗心地拒绝了我的真实想法，因为“它对 OKR 没有帮助”，我们之前同意的 OKR 不应该描述我们所做的一切。

我同意 Amir Shevat 的观点，我们应该“做正确的事情，而不是做容易衡量的事情”：

  • 人们对于使用 NPS 太过轻率。NPS 很容易被操纵，用 1-10 的等级来评价产品对了解其运作机制的开发者来说毫无意义。不妨试试Sean Ellis 提出的问题：“如果你不能再使用产品/成为社区的一员/阅读此内容，你会有什么感受？” 并以此作为一种细分/了解你的受众的方式，而不是仅仅满足于永远保持 NPS 的高水平。
  • 如果您不像 90% 的 DevTools 初创公司那样拥有足够的流量或基础设施来轻松实施 A/B 测试，则禁止您建议进行任何 A/B 测试。紧密的用户反馈循环胜过匿名数据。与保持用户距离相比，仅向用户一对一或小组展示预览效果会更有效果。

  • Will Klein 建议用“新版本的采用速度”来衡量 OSS 开发者关系。这听起来不错，但你得明白，升级采用率只是活跃使用率的一个指标，曲线几乎都像这样，无论你做什么，都只能改变几个百分比：

    替代文本

以社区为中心的开发者倡导

人们开始意识到社区的持久力量，现在技术社区建设者是科技界最热门的新职业。

我喜欢的社区指标（选择 1-3 个）：

  • Slack/Discord 活跃会员数量
  • Discourse/StackOverflow/GitHub 讨论中每周新主题的数量
  • 用户贡献的数量（无论是 PR、问题、答案、博客文章、聚会演讲等）
  • Orbit 1级用户数量
  • 活动数量及参加人数
  • 参与的“超级用户”数量

需要注意的事项：

  • 要小心经常要求用户为你做免费工作，并且用与你的社区建设工作只有松散关联的指标来衡量自己。
    • 例如，大多数公司“社区”实际上只是支持论坛，增加支持负担并不总是好事，也与你的管理无关。还要注意不要用 Devrel 来代替正式的支持团队。
    • 除了寻求帮助之外，你还需要给人们一个团结起来的理由。拥有优质内容往往是“最小可行社区”。
    • “大帐篷”服务于你的社群，而不是公司本身——邀请你的竞争对手参加你的活动或会议，一起演讲，或者让他们友好地聊聊天，无论什么方式，只要能让你的社群成为一个真正让人们聚集在一起学习你主题的地方，对你都有好处。这在尝试创建类别时尤其有效。
  • “真正的”社区指标极难衡量。例如，一个好的社区的定义是，人们期望他们与你的项目/产品的联系能够延续到他们目前的工作岗位之后。衡量这一指标的自然频率会跨越数年，但没有哪个指标系统能像它一样有耐心。
  • 活动在培养公司社群方面的作用被低估了。套用马歇尔·麦克卢汉的话来说，论坛和聊天是“冷门”，而活动才是“热门”。从公司办公时间到社交活动，从大型会议和黑客马拉松，再到用户组织的聚会，活动都应有尽有。要衡量这些活动的参与度和频率。我对此非常认真——我们有一个首席开发者关系经理，他的主要工作是协助组织我们的三场会议（与市场营销部门合作）及其相关的社群。即使他只负责这件事，对我们来说也已经是无价之宝了。
    • 如果您拥有完善的文档、快速的价值实现时间、快速的迭代时间（修改和重新部署时间少于 1 分钟），并且参与者能够获得切实的惊喜，从而赢得比赛（尤其是在多供应商参与的黑客马拉松中），那么现场黑客马拉松就是合适的选择。因此，您应该了解哪些因素能够赢得黑客马拉松——任何实时性（因为现场演示可以吸引观众）、任何基于手机的体验（每个人都有手机）、任何基于人工智能的体验（人们喜欢看到机器像人一样运作）、任何视觉设计。如果您的产品价值实现时间较长，远程/异步黑客马拉松可能是更好的选择。您可以与Major League Hacking、DevTo或FreeCodeCamp合作，或者与您所在领域的 YouTube 博主合作/赞助。
  • 拥有一个活跃且不断发展的超级用户社区，例如 AWS 英雄、Java Champion、GitHub Stars 和 Stripe 社区专家，可以帮助您最热心的支持者获得访问权限和地位。一小群高度参与的粉丝比一大群被动用户更能使社区充满活力。
  • 如果你的核心产品是开源的，你真正想要多少社区参与？Runa Capital 对活跃贡献者有一个定义，其中的巨头每年最多有 200 名定期贡献者。要管理这么多外部社区，你的工程/产品团队有能力/有准备/愿意承担吗？
  • 社区奖励问题：
    • swag 项目是由 Devrel 还是市场营销部门负责的？你们会把它和 Gatsby 之类的开源项目联系起来吗？你们会用自己的产品作为演示来构建 swag/CRM 吗？还是说这是“非我发明”综合症？
    • 如何衡量社区生成的内容和社区组织的聚会？Devrel 的衡量标准是它如何让用户互相分享（甚至炫耀）他们的使用情况。你可以借鉴Notion等非 DevTool 的“用户社区”项目。
    • 您如何让社区与工程师更紧密地联系在一起？Kelsey Hightower 举办了一场同理心会议，Kubernetes 团队原本应该使用 Kubernetes，但却失败了。显然，这些互动很有价值，但您如何衡量呢？
    • 如何帮助你的用户互相雇佣？在Temporal，我们为用户设立了一个招聘页面。可惜的是，大多数这类尝试都过于零散，难以进行认真的衡量。

以内容为中心的开发者倡导

内容是 DevRel 的核心。如果你不知道从何入手，我建议你每周至少创作一篇关于公司的内容，不断尝试，直到找到自己的节奏。每年重写一次博客固然有趣，但并非每个人都投入时间学习如何定期创作有趣的内容。

我喜欢的内容指标（大致顺序）：

  • 时事通讯订阅者数量
  • YouTube 订阅者数量
  • Twitter 关注者数量
  • 完成研讨会的数量
  • 参加会议/聚会的次数
  • SEO域名权限

需要考虑的细微差别：

  • 作为内容创建者，您可以选择TOFU、MOFU 和 BOFU 内容：
    • 漏斗顶部 - 从未听说过你（意识）
    • 漏斗中部 - 将您与其他人进行比较并学习基本特征/概念（评估）
    • 漏斗底部——决定购买并投入生产（转化）
    • 如果您仅衡量网站流量，那么您自然会激励 DevRel 创建根本不需要转换的点击诱饵 TOFU，并疏远您最大的粉丝。
  • 大多数公司都以博客文章作为主要衡量指标，而电子报只是事后诸葛亮。如果你正在创办一家公司，你应该明白这完全是本末倒置。订阅电子报（由优秀的公司博客文章和动态激励）可以让你保持诚实。大多数营销人员和专业创作者认为，一个电子邮件订阅者的价值相当于100到1000个社交媒体粉丝。尽管许多开发者不喜欢提供他们的电子邮件地址，你需要其他方式联系他们，但你也不能免受媒体的普遍规则的约束。
  • 事实上，你越认真地把自己视为“在公司内建立一家媒体公司”而不是“做一些内容营销”，你就会做得越好。
  • 记住内容的半衰期——一段内容多久才能达到其生命周期内预期浏览量的一半。Twitter 的半衰期是几小时，YouTube 的半衰期是几个月，博客的半衰期是几年。请根据实际情况进行创作。
    • 您可以在更短暂的媒体上测试事物，然后在更永久的媒体上进一步开发它们。
    • 大多数经理认为制定内容日历能起到帮助作用。我从未见过 DevRel 运营团队在第一个月之后还坚持这些日历。事实证明，说做事比做起来容易得多。最终，你创作内容是因为你受到了启发，而不是因为日历上的内容。列出你想涵盖的主题，并根据主观兴趣和用户需求定期挑选。YouTube 是个例外——推荐算法会奖励每周的产出。请参阅Dan Luu 关于工程博客最佳实践的文章。
  • 社区规模：YouTube 上有 500 万到 1000 万开发者（我估计）。Twitter 上有 100 万到 200 万开发者（我估计）。Hacker News 上有大约 600 万开发者。每个开发者都有自己喜欢的话题和子社区。请根据实际情况考虑/衡量/确定优先级。
  • 默认保持一致性：如果你是专业内容创作新手，最好的入门方法就是默认保持一致性。也就是说，只要你有正确的想法， 10倍的内容就能拥有令人难以置信的“半衰期”。
  • 工作坊是极度低估的深度内容形式。与其让5000人观看你5分钟的视频然后永远消失，不如让50人参加你3-5小时的研讨会，并在工作中运用它。
    • 将其录制下来并上传到网上 - 你不会在针对特定公司的 3-5 小时视频上获得大量观看次数，但对于喜欢快进视频或迫切需要解决某些问题的人来说，这是非常值得赞赏的。
    • 大多数研讨会也可以转换为基于自导文本的版本：参见 AWS 研讨会，如Amplify、ECS和EKS、Google Colabs、GitHub学习实验室。
  • 大多数公司可能都高估了出席会议的重要性，原因很简单，大多数开发者根本不去参加会议。如果只考虑参会人数，公司历来在开发者相关差旅预算上花费过高。然而，数百万开发者确实会在会议结束后观看精彩的会议视频。你可以抽象地将会议费用视为制作成本，用于社会认同和制作一个真正优秀的 YouTube 视频（在一个不属于你的频道上）。每年在高知名度的活动中制作 1-2 个精彩的会议演讲非常值得，有时为了达到这个目标，你需要在 5-10 个较小的场地练习和迭代，但除此之外的任何活动，与你所能做的其他事情相比，收益可能都会减少。
  • 聚会则完全不同：高接触，低强度。能够在不同的聚会上反复进行相同的电梯游说，可以很好地吸引一小部分开发者的注意力。利用他们的问题和反馈来改进你的电梯游说（2 个词、1 句话，2 分钟、7 分钟、25 分钟、55 分钟等版本），就像一场无限游戏。聚会的出席次数或许就是一个足够好的指标。
  • 我同意 Steph Smith 的观点，大多数公司过于注重社交渠道，但问题是，大多数开发者发现解决方案的方式更多是通过听朋友和思想领袖的建议，而不是自己主动搜索。Auth0 和 Digital Ocean 以优先采用基于 SEO 的方法而闻名，但你的开发者工具/品牌应该足够通用才能发挥作用。
  • 需要考虑的额外“内容”事项：
    • 谁拥有示例存储库和代码示例并保持其更新？
    • 你创建内容是因为文档不够清晰吗？你创建文档是因为产品不够直观吗？所有内容最终都有“半衰期”——有时你必须深入底层去解决根本问题，而不是衡量用户使用创可贴的熟练程度。
    • 如何鼓励真正的工程师内容和用户生成内容？Devrel 的规模在于它如何让其他人创造内容，而不仅仅是垄断内容。

以产品为中心的开发者宣传

我喜欢的产品指标：

Devrels 可以通过 beta 测试（个人或与用户一起）或为发布日/年度会议创建引人注目/鼓舞人心的演示、博客文章和视频，在任何产品发布之前提供巨大的价值。

  • 有时最好的产品反馈可能是负面的：“嘿，你需要推迟这次发布，你还没有准备好。”来自内部的负面反馈比来自外部的要好，但公司文化需要接受批评。
  • 如果你习惯性地攻击信使，不管他们犯了多大的错误，你都不会对不再收到坏消息感到惊讶。
  • 是的，人们确实会雇佣 DevRel，让他们提供产品反馈，然后就直接忽略这些反馈。这很常见。

Devrel 还经常负责维护非核心集成和辅助工具。

  • 示例：Netlify 拥有一支完整的集成工程团队。目前，该团队主要负责 Next.js 集成，但也可能拥有 VS Code 扩展等功能。过去，我曾参与构建Netlify Dev和react-netlify-identity，作为该功能的一部分。Sourcegraph的集成并非核心产品，但有助于在其7 阶段 SDLC 框架下实现应用。Docker Compose和Helm Charts等流行的快速启动工具也属于该功能。
  • 更复杂的版本是“解决方案工程”，您可以协助完成客户定制的演示和集成工作。对于规模足够大的客户和规模足够小的初创公司来说，这没问题，但 DevRel 的大部分工作应该集中在可扩展的工作上。

大多数开发者关系（Devrel）把大部分时间花在向开发者宣传上，而不是为他们代言。用户到产品的反馈循环是目前开发者宣传中最不完善的部分，主要是因为开发者关系（Devrel）和产品经理（PM）之间谁负责这项功能并不明确。

结论

最终，我希望行业内能够更加诚实地承认复杂的权衡：

  • 沟通价值和量化进步的需要与指标对最终极其人性化的努力的非人性化影响之间的区别
  • 滞后指标更有意义，但你控制力较弱，而领先指标你控制力较强，但责任较小，领先和滞后之间的主要联系“仅仅”是轶事和定性的，但最终你的工作
  • 内容是一个个人的、创造性的过程，需要一种能够接受冒险和失败、高潮和低谷的文化，一致性、质量和范围会因受众的不同部分而有不同的评价，过多的后座驾驶员会导致个性和所有权的消亡。

我给大家讲个小故事：当我第一次听说一项技术时，我会先把它放在脑后，看看它是否会持续存在并取得进展。我通常会在第一次听说并看到持续进展至少一年后才会尝试一项技术。这不仅仅是我；许多首席技术官和工程副总裁都建议采用多年的采用路径，尤其是核心技术。传统的营销建议是，人们至少要听到你7次才会决定购买；对于开发者工具，Netlify 的 Matt Biilmann 说，更像是14次。

尝试将其纳入您的季度 OKR 审查周期。

如果您对更多 DevRel 想法、播客和书籍感兴趣，请查看DX Circle 指南了解更多信息！

资源和进一步阅读

文章来源：https://dev.to/dx/measuring-developer-relations-ie8
Devto 翻译
PREV
六边形架构和清洁架构（附示例）
NEXT
语言服务器是新的框架