独立开发如何看留存与利润，决定下一轮投入

按任务频率约定回访#

每天处理资讯和每月整理报告，对回访的要求不同。一个月才需要一次报告的人，下周没有打开产品，不一定说明不满意；每天用的工具一周都没人回来，则值得尽快了解原因。

我会先定一项核心动作，例如用户处理了允许提交的文章，并得到可以用于原工作、只需可接受修改的结果。打开页面和登录可以记录，但不足以替代这项动作。

首次成功的人，在下一次同类任务中是否还用这个工具，是一条有用的线索。统计时也要记下他是否真的遇到新任务，否则会把“近期没需要”与“有需要但换了别的工具”混在一起。

示例产品面向每周整理资讯的人，可以先按周观察。比较同一段时间开始使用的用户，给他们相同的观察窗口，再看是否完成下一轮任务。还没过一周的新用户，不放进一周后的回访分母。

对于单次交付产品，完成任务后不再使用可能正是正常结果。此时应看交付质量、退款、推荐或下一项需求，不能硬套订阅工具的留存要求。

使用、续费和取消各自记录#

付费用户可能没有使用，使用频繁的人也可能很快取消。分开记录，才能看见这两种情况。

假设一批月付用户有 20 人，到相同续费节点时有 15 人成功续费、3 人主动取消、2 人付款失败。可以记录成功续费比例为 15 / 20，同时保留取消与失败人数。

付款失败可能与支付方式有关，主动取消可能是任务结束、价格或结果问题。原因仍需核实，不能把两人失败都判为不满意。年度预付用户也不能因为这个月没取消，就被当成已经验证了下一年的续费。

我会同时看使用记录和允许收集的反馈。连续付费却不使用，可能只是忘了取消；这种收入不适合成为持续增长的依据。取消入口应当清楚，取消后什么时间停止服务也要告知。

用户没有回来，从上一次结果查起#

先核实上一次任务是否真的完成。页面显示成功，摘要却漏了条件，用户可能不会专门反馈，只是下次改用别的工具。

可以查看失败状态、结果复核、复制或导出，以及用户是否需要再花很多时间修正。先了解结果为什么没被用到原来的工作里，才能判断提醒邮件是否有用。

联系用户时围绕这一次任务询问，不给没有证据的问题预设答案。提醒与召回也应按用户选择和适用要求发送，控制频率、提供退出方式。如果用户连链接都打不开，就先修好访问问题，再联系对方重试。

让每个月的收入对得上成本#

我会至少保留收入、退款、模型及其他服务成本、获客支出、支持时间这几项。订单流水和实际可用资金分别看，支付手续费、结算时间和税费也需要计入相应账目。

假设一个月收到 1200 元，退款 100 元，支付费用 50 元，模型与可变服务成本 300 元，固定服务费用 200 元，推广支出 400 元：

1
这组项目对应的剩余金额：
2
1200 - 100 - 50 - 300 - 200 - 400 = 150 元。
3
另记开发与客服时间、尚未列入的其他成本和税费。

只看 1200 元收入，会错过这些消耗；150 元也不能直接称为净利润，因为示例没有包括全部项目。先保持记账范围一致，再比较每个月变化。

年度预收还对应未来服务。收了一年的钱，不能把全部余额都投入当月推广，然后等后面提供服务时发现没有预算。按剩余承诺估算后续调用、支持和退款需要，保留可用资金。

看用户成本时，平均数与较高用量都要保留。正常使用造成高成本，可能需要调整未来套餐或优化调用；技术故障导致重复请求，则先修故障。已经售出的权益按原承诺处理，不能用突然收紧额度补亏损。

获客是否划算，要看实际回收#

上一轮渠道测试计算了首次付费的获取成本。这里继续跟踪同批用户后续付了多少、服务花了多少，何时覆盖获取他们的支出。

若获取一位用户花 80 元，首月收入扣掉退款和可变交付成本后贡献 25 元，这时还没有收回推广成本。以后几个月能否补上，要看真实续费与用量。缺少数据时，可以做不同续费情境的预算，但把假设与已经收到的钱分开。

免费使用者也会消耗服务。渠道带来很多试用，却只有少量用户购买时，把这些试用成本一起留在这批用户的记录里，才能知道增加流量会发生什么。

我不急着用一个固定的终身价值倍数判断健康。刚上线、样本少、价格还在变时，先看实际回收和现金是否足够。经营稳定后，再用更长观察期估计未来价值。

下一轮从一个能验证的问题开始#

我会把任务排成几类：故障和交付问题优先修；首次使用障碍影响新用户，要复测；有重复证据的新需求，再估算收益和开发成本。

结果稳定、用户会回来、获客能重复且成本可承受，可以逐步增加投入。只有流量涨而有效使用没涨，先查介绍和体验。收入增长但每位用户成本更快上涨，先查交付方式与收费规则。

连续几轮都没有新任务或回访，也没有可行的购买理由，就暂停扩展，回到用户与需求记录。暂停并不要求再做一个更大的版本，可能只是把当前方向留下来，集中测试另一个场景。

下一次开发的任务应具体到能复测，例如“摘要条件遗漏导致返工，补充这类样例并比较修改前后的结果”。任务书里留下原因、修改和成本，开发完成后再补复测结果。

下一篇继续讨论如何安排产品迭代，把用户反馈变成下一版任务。