最新

我希望 MediaWiki 具备的两个功能： * 更深入、支持多种语言的功能性 API。有很多很棒的工具可以用来编写机器人，但如果你想编写一个解析器扩展，是不是只能用 PHP？或者说现在情况有变化吗？ * 多人协作编辑功能。编辑冲突确实令人头疼，也会劝退新手用户。我希望同时使用时的体验更像是一种协作的社交体验，而不是雷区。 ……但我确实认为 MediaWiki 非常棒，尽管存在这些缺点，我还是倾向于使用它。

我与一家产品导向型增长（PLG）组织交流过，他们在其营销自动化工具中拼凑了激活鼓励功能（这比我之前见过/经历过的要复杂）。 运作方式如下： - 增长工程团队将激活事件发送到营销平台 - 当用户未完成下一步操作时，会触发复杂的if/then自动化流程 - 根据实际的用户状态发送有针对性的“嘿，你没有完成X”消息 遇到的问题： - 竞争条件：用户完成操作，但事件延迟到达 = 邮件无关紧要 - 代理归因：无法判断邮件是否真正推动了激活或在漏斗中前进（使用点击作为代理） - 维护噩梦：复杂的自动化流程和工程依赖关系（或代码库访问权限） 再次强调，尽管存在这些问题，但这比我通常看到的要复杂。考虑到他们投入到一个不完美的内部解决方案上的时间和精力，我很好奇其他人是如何解决这个问题的。 据我所知，有三种方法： 选项 1：通用邮件推送活动 - 方式：发送预先安排的邮件，无论用户行为如何 - 例如：第 1 天“欢迎！” -> 第 3 天“查看功能！” -> 第 30 天“我们想念你” - 优点：易于设置，无需工程人员参与 - 缺点：未个性化，忽略用户状态，可能无效 （我个人几乎会直接删除这些邮件，因为它们出现在我的收件箱中） 选项 2：DIY 行为邮件（如这家公司） - 方式：跟踪用户状态并触发有针对性的挽回消息 - 例如：如果做了 X 但在 N 小时后没有做 Y -> 发送关于 Y 的帮助 - 优点：根据用户旅程个性化，完全控制 - 缺点：需要工程资源，无法衡量它是否推动了激活，可能由于时间问题导致邮件错误 选项 3：Appcues/Pendo/（其他？）行为邮件 - 方式：跟踪用户状态并触发有针对性的挽回消息（与选项 2 相同） - 例如：如果做了 X 但在 N 小时后没有做 Y -> 发送关于 Y 的帮助 -> 跟踪用户是否完成了 Y - 优点：根据用户旅程个性化，将邮件归因于激活，无需工程人员参与 - 缺点：至少每月 300 美元，用于购买一个应用内引导工具套件，以获取访问权限（Appcues）或选择购买行为邮件（Pendo） （我还认为应用内引导是需要用引导式教程来掩盖的更大设计问题的迹象（我相信存在一些特殊情况）） 我想更好地理解的是： 对于通用邮件推送用户： - 你知道它不起作用，还是只是没有优先考虑更好的方法？ - 你能判断出你是否对激活率有影响吗？ - 你的激活率是多少？ 对于 DIY 构建者： - 这花费了多少工程/营销时间？ - 你使用什么指标来衡量成功（代理）？ - 如果存在独立的行为邮件，你愿意付费吗？ 对于 Appcues/Pendo/（其他？）用户： - 你是否使用了整个平台，还是只想使用行为邮件？ - 归因数据是否值得捆绑成本？ - 你看到了多少激活提升？ 这家公司每月约有 3 万次注册（不包括季节性因素），激活率为 26%。这意味着有 2.2 万人收到了精心策划的、但难以评估的挽回尝试。他们构建了选项 2，因为选项 3 需要购买他们不想要的功能。 在电子商务中，没有购物车放弃邮件是不可思议的。为什么 B2B SaaS 没有针对流失挽回的相同功能，而没有捆绑包的负担呢？ 你的方法是什么？你能实际衡量它是否有效吗？

你有没有过这种感觉，就想压缩一下视频… 然后突然间就被各种参数、半吊子的 StackOverflow 回答，以及为了搞懂一个命令而打开的 10 个标签页淹没了？<p>我就是这样。每一次。都这样。<p>所以我创建了 FFmpeg Pages——一个简单到爆的命令集合，里面都是我反复搜索的命令。没有废话，不用深挖，只有真正能用的东西。