Ask HN: 针对高成本侧项目,什么样的定价模式有效?

1作者: onemiketwelve4 个月前
我一直在开发一个应用程序,它是一个仪表盘 + 任务栏小部件,用于显示通勤时间。我最初是为自己做的,这样我就不必每次都通过谷歌搜索来查找了。老实说,我挺惊讶它竟然没有类似的产品,但现在原因对我来说很明显了。因为实时交通数据非常昂贵。我的供应商每 1000 次调用大约收费 2.50 美元。<p>所以,每条往返路线每月大约需要花费 4 美元(每条路线 2 次调用 * 每小时 1 次调用 * 24 小时 * 30 天)。 在我看来,这在原始成本上已经很高了,这甚至还没有算上我的分成。我认为,在这个时代,有这么多免费的 API,普通人(包括我自己)不会认为一个简单的交通小部件会花费那么多。最重要的是,我当然希望更新频率可配置。也许有些人希望每 15 分钟更新一次。不幸的是,现在我们的成本增加了 4 倍。考虑到每个用户可以添加 N 条路线,有人可能有 5 条路线,现在他们突然要花费 80 美元!我相信很少有人愿意花这么多钱。<p>我最初的想法是按使用量收费,这样用户就有动力减少他们的使用量。也就是说,我可以加入一个活跃时间功能,这样他们就可以只设置他们的通勤时间。<p>但然后,每一条定价建议都说不要对用户进行“出租车计价”。而且说实话,尽管人工智能服务的成本也很高,但几乎没有面向消费者的服务是按使用量收费的。他们使用代币桶方法 + 超额费用。但老实说,我认为这只有对他们才可行,因为他们正在用风险投资的钱大规模补贴他们的用户。如果我没记错的话,他们许多人都有的 20 美元套餐,要收 150 美元左右才能收支平衡。<p>我认为是路线数量 + 频率这两个杠杆的特性,会产生如此巨大的成本,这让我很难想象一个有固定订阅计划的世界。<p>看看其他具有类似价格动态的业务,我发现了所谓的“家庭安全摄像头”模式,他们收取固定费用 + 每台摄像头 X 美元。最近一家大型摄像头公司改用了这种模式,因为他们的固定年度订阅根本行不通。例如,对一个用户使用 1 个摄像头和 10 个摄像头收取相同的费用,并且需要存储 1080p 与 4k 的视频<p>在这种情况下,你会怎么做? 诚挚的 困惑
查看原文
So I&#x27;ve been working on this app that&#x27;s a dashboard + taskbar widget for commute times. I made it for myself so I wouldnt have to search for it all the time by googling it. I was honestly surprised it didnt really exist but the reason is now obvious to me. It&#x27;s because live traffic data is super expensive. Around $2.50 &#x2F; 1k calls from my provider.<p>So each round trip route would cost around $4&#x2F;month (2 calls per route * one call per hour * 24 hours * 30 days) This is quite a lot imo in raw costs, which doesn&#x27;t even factor in my cut. I think in this day and age with so many free apis, your average person (myself included) would not think a simple traffic widget would cost ANYWHERE near that amount. On top of that, of course I wanted the udpate frequency configurable. Maybe some people want to have it update every 15 minutes. Unfortunately now we are generating x4 in costs. Factor in each user can add N routes, somebody could have 5 routes and now they&#x27;re suddenly incuring $80! in spend. Which I&#x27;m sure _very_ few people would be willing to spend.<p>I originally thought I would just charge for usage so that the user would have incentives to tune down their usage. AKA I could put in an active hours feature so that they could put in only hours of their commute.<p>But then every single piece of pricing advice says to NOT taxi meter the users. And to be fair, despite the similar high cost nature of AI services, almost none of them at the consumer facing front charge per usage. They use the bucket of tokens method + overages. But honestly I think this is only viable for them because they are massivley subsidizing their users with VC money. If I remember correctly, the $20 plan many of them have would have to cost around $150 to break even.<p>I think it&#x27;s the nature of these 2 levers of route count + frequency, which can generate such wildly amoutns of cost that makes it hard for me to imagine a world of a flat subscription plans.<p>Looking at other busiensses with comparable price dynamics, I found what I&#x27;m calling the &quot;home security camera&quot; model, where they charge a flat rate and +X per camera. Recently a large camera company moved to this because their flat annual subscription just wasnt working. IE charging the same for a user with 1 camera vs 10, and having to store 1080p vs 4k footage<p>What would you do in this situation? Sincerely confused