最新

我是一名创始人，我刚刚构建了 Revliu。 在构建了几个产品之后，我一直想了解我的客户是如何找到我的。是哪个营销活动将他们吸引过来，他们来自哪个渠道，以及他们完整的客户旅程是怎样的。 市面上已经有一些工具可以做到这一点，但我遇到的一个持续存在的问题是，它们通常只停留在首次触达或末次触达。 这就是为什么我围绕多触点归因和完整的客户旅程构建了 Revliu。 一旦有人访问了你的网站，Revliu 就会为他们分配一个匿名 ID 并开始追踪他们的旅程。当他们注册后，这个旅程就可以与实际客户关联起来。 从那时起，你就可以看到他们是否处于试用期，他们多久回来一次，他们打开了多少次会话，以及最终他们何时付费。 对我来说，这也有助于我更容易地与用户沟通，并理解他们为什么会在那个特定时刻做出前进的决定。 今天，Revliu 追踪获客渠道、回访用户、会话、触点和收入。 我不想仅仅知道一个营销活动获得了多少次展示，而是想知道它实际带来了多少收入。展示次数并不是我真正关心的。 这个应用本身非常简单。 主页会给你一个按渠道划分的收入概览。 流量页面显示访客、他们的旅程和会话。 营销活动页面显示获客漏斗。对于 SaaS 产品来说，这可以是访客 → 潜在客户 → 试用 → 付费客户。对于在线商店来说，它可以简单地是获客 → 购买。 客户页面允许你单独查看每个客户，查看他们的触点、他们来自哪里、他们的旅程以及他们何时购买。 技术方面原理上很简单。 它始于一个获得 ID 的匿名访客。我们追踪他们的访问和触点。当他们注册时，这个匿名的旅程就与客户关联起来。 Stripe 也已连接，因此当客户付费时，收入就可以链接回同一个旅程。 目标基本上是将获客 → 访问 → 注册 → 客户 → 收入联系起来。 目前，该应用仍处于第一阶段。我还没有构建完我想要的所有集成。 接下来我想要构建的是能够做得更多，而不仅仅是展示数据的东西。 如果有人留下了他们的电子邮件但从未完成注册，多次回来但未购买，或者表现出真正的兴趣但未转化，我想利用这些信息来尝试挽回那个潜在客户。 想法是通过电子邮件再次联系他们，或者根据集成情况，通过 LinkedIn 等其他渠道联系他们。 这就是为什么我今天仍然认为该应用是有限的。我首先想测试这个归因部分，看看这个问题是否有真正的吸引力，然后再构建其他所有东西。 我真正感兴趣的未来部分是收入挽回。 通过与 AI 结合，目标是适应不同的客户，了解哪些客户在犹豫，并做得更多，而不仅仅是显示数据。 我希望数据能在产品内部真正发挥作用。 我真的很想知道你今天是如何处理这个问题的。 编码比以前容易多了，但一个畅销的好产品和一个没人用的好产品之间的区别，往往在于营销和分销。 我真的很想听听你对 Revliu 的反馈，以及你对我的方法和你会如何做不同的事情的看法。

你好 HN， 我创建了一个用于查询内存中 JS 数据的 TypeScript 库。最初的目的是提供一个比 AlaSQL 更模块化、更轻量级的替代方案，但后来有人要求我支持 SQL/XML，我个人觉得这两种语言都过于冗长。于是我开始思考，想起了 Virtuoso 结合了 SQL 和 SPARQL 的查询方式，并以此为基础进行了扩展。 最终的引擎包含一个共享的核心，提供优化器、查询基础设施等，以及可以作为插件添加的独立语言。实现方式是将这些语言翻译成一种通用的代数。因此，你可以在单个查询中混合使用多种语言——想象一下你需要处理一些表格数据，但对于每一行，你都想从一个深层的树状结构中提取信息。这时，你可以编写一个外部 SQL 查询，并在其中嵌入一个 XQuery 子查询，它就能正常工作。这个代数本身就被设计成可扩展的——我不敢说它涵盖了所有查询语言可能需要的功能（但已经实现了针对每种主要数据模型的语言——SQL、XQuery 和一种类似 Cypher 的语言（涉及许可问题））。例如，XQuery 包含了两个特殊的代数运算符，而无需修改核心。 GitHub README 中有一个演示链接，你可以在其中查看查询计划或在示例数据上执行查询。如果你对此感兴趣，还有一个关于这个项目的我的毕业论文链接。去年，整个项目曾在 VLDB 上作为演示进行过展示。 这是我两年多工作的成果，我认为其他人也可能觉得它有用——主要是因为我能够编写出令我满意的文档。文档是借助 LLM 创建的，但我为此花费了数周时间，所以希望它们读起来不错。除了最初的一批回归测试外，代码本身都是手工编写的。

显而易见，如今大家都在编写自己的编码辅助工具，所以我将直接切入我工具的独特之处： * 没有提供 shell 访问权限的工具。取而代之的是一系列面向开发的工具，其功能受到限制。 * 读写操作受到访问控制的限制。项目文件可以无需提示即可读取，而 git 忽略的文件和点文件则不行。 * 附带的 MCP 集成仅限于只读访问。没有用于 git add 和 commit 的工具。 * 也许最大的区别在于独立的驱动程序（driver）和导航员（navigator）模式。在驱动程序模式下，Opair 的工作方式与其他辅助工具类似，但代理的自主性较低。在导航员模式下，代理根本无法访问可写工具，而是监控项目在你常规编辑器中所做的更改。其理念是模仿与人类结对编程的关系。 为什么会有人构建这个？因为我想要的是更少的自主性，而不是更多。我不想在实现推送的最后阅读大量的 diff，而是希望全程参与。Opair 是我试图让“人/代理”关系更像结对编程，而不是代码审查的尝试。 我在哲学文档中对此进行了更详细的阐述： https://www.opairdev.org/philosophy