解决 Base 链上归因问题

解决 Base 上的链上归因问题

19世纪的零售商 John Wanamaker 曾有句名言：“我在广告上花掉的钱有一半是浪费的；问题是我不知道是哪一半。” 解决这个由来已久的问题的现代方案是所谓的归因：这是一门（或者说是一门艺术）对所有用户行为进行分类，并确定哪些行为带来了预期的业务成果的学问。

归因从根本上说是一个哲学问题：我们如何知道我们所知道的，以及我们如何知道事件 A 是否导致了事件 B 的发生？

在互联网出现之前的广告世界——归因的黑暗时代——营销人员费尽心思统计数据，以弄清楚在1954年赞助克利夫兰的 Little Orphan Annie 广播节目是否成功销售了更多的 Ovaltine。数字营销承诺提供一个测量全景图，最终将每一个用户事件都编目直到完成销售。然而，在实践中，在大量数据和浏览器 cookie 和移动设备 ID 之间零碎的身份识别的冲击下，这种理想化的愿景变得模糊不清。

Spindl 团队在 2023 年 Onchain Summer 期间，早期尝试在 Base 上绘制价值流：我们所能做的就是跟踪用户从入职到最后一次交易之间在协议间的跳转（需要大量手动标记）。

区块链承诺通过一个不可辩驳的用户行为的公共账本，来缓解这个问题，实际上是将曾经秘密的“转化”数据公之于众，供所有人查看和验证。Spindl（去年被 Coinbase 收购）就是基于这个前提成立的，但与早期数字营销时代一样，将难以捉摸的链下身份与假名的链上身份（即钱包地址）结合的现实很快就出现了。如果不在每个 dapp 的着陆页上运行代码，就无法将（大部分）链下应用层与高度抽象的智能合约和交易连接起来。

当然，你可以发布 Dune 面板来展示你的链上用户群和交易，但即使有了 Spindl 归因，也很难将其与用户实际来源联系起来。

直到现在。

Base 最近推出了 ERC-8021 归因标准，该标准使构建者能够在其用户漏斗的任何阶段（无论是钱包、消费者应用还是协议）为其交易打上标签。通过将其构建者代码附加到已签名的交易中，他们证明了自己是链上价值链的一部分（无需透露任何用户数据，并避免了隐私问题）。一个关于 8021 生态系统的 Dune 面板在此 。

以下是构建者代码集成在实践中可能的样子：

    await wallet.sendCalls({
      calls: [
        // your transaction calls
      ],
      capabilities: {
        dataSuffix: {
          value: "0x07626173656170700080218021802180218021802180218021",
          optional: true
        }
      }
    });

在 Base，我们鼓励所有构建者在其协议和应用程序中实施 8021 构建者代码，附加正确的 v2 后缀以识别他们在用户旅程中的角色（无论是应用程序、协议还是其他）。Coinbase 的两个零售界面，主零售应用程序和 Base 应用程序，都已实施 8021，同时还有大量主要的 Base 构建者，如 Aerodrome、Moonwell 和 Privy。

8021 构建者代码将是 Base 衡量对 Base 生态系统贡献的唯一方式，因此也将是未来整个用户漏斗（从应用程序到协议）奖励计划的主要输入。就像商用飞机上的应答器一样，你的构建者代码是 Base 能够看到你在用户和收入方面对共享交易状态的贡献的方式。

Base 上 ERC-8021 构建者代码的早期采用者。

归因只有作为商业模式或奖励计划的输入时才真正重要，才能让某人获得应得的报酬。仅仅编写你的“构建者代码”并不意味着你应该为新获取的用户获得信用：它意味着你只是其中一个环节，由归因模型来选择赢家。

但至少有了 8021 构建者代码，你就拥有了解决归因问题的链范围方法的开端，这个问题仍然困扰着链上增长。有了区块链的共享共识状态和附加到已签名交易中的构建者代码，我们终于可以弄清楚增长预算（无论是广告还是 Base 对构建者的奖励）中到底哪一半没有被浪费。向资本展示自己：前往 base.dev 注册构建者代码即可开始。更多实施信息请参见 Base 构建者文档 。

• 原文链接： x.com/antoniogm/status/2...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～