5 ms·
I appreciate the response and I'd like to reiterate that I might just not be the right user with the right expectations. Still, I hope it's useful to hear why s
by Jochim 3y ago
I appreciate the response and I'd like to reiterate that I might just not be the right user with the right expectations. Still, I hope it's useful to hear why someone might be on the fence about the product.
> (9 is probably a bug)
To clarify 9, the request is sent when clicking the cross on the Lens > Edit page rather on than visiting it. This also occurs when returning from maps. In both cases a new search is only billed when the cache has expired. Interestingly, from a totally naive user's perspective, maps don't appear to use up a search.
> If you know of other ways to do this, we are all ears.
I don't have an issue with charging for individual searches. On the whole I think it's a reasonable idea. I do think that some aspects of the UX encourage billing superfluous searches and that, on a purely financial level, Kagi is dis-incentivised from improving this.
Taking steps 5 and 6 as an example: there's no reason for these to be separate billable events. When viewing search results the user interface simply doesn't allow the user to select the sort order in the same operation they select the field. I sincerely doubt that this is intentional but it's easy to see the cynical take.
I think there's also a decent case for longer caching of results, giving users the option to refresh results if it's important they aren't stale. This avoids the current situation where a user might spend some time visiting the firsts webpage in the result set, return wishing to continue perusing subsequent results but end up triggering a billable event. The same applies should someone want to swap between web and images.
A quirk I noticed when trying to trigger shopping results was that searching for "best hair dryer" will display the shopping widget whereas searching "best hairdryer" does not, despite "showing results for best hair dryer" appearing as part of the search.
Maybe I'm misunderstanding the feature but searching for variations on "cordless drill", "best cordless drill", "best cordless combi drill", "best cordless percussion drill" never returned any shopping results, should I have expected it to?
To expand on my prior point as to why moving to a total number of trial searches might be harmful to conversions. In evaluating the billing rules and shopping results, I'm now on search 46/100. I haven't yet got into a flow with the product. That might change over the next 50 searches but I still haven't explored: redirects, lenses, personalised results, fine tuning search settings, or just the broader search quality.
- freediver 3y ago> I do think that some aspects of the UX encourage billing superfluous searches and that, on a purely financial level, Kagi is dis-incentivised from improving this. Kagi is selling searches at cost, and we make money on subscriptions. Making a suboptimal UX id definitely not what we are doing, as people pay us for UX to be optimal. You point out some valid use-cases there and the reason we haven't addressed them so far is probably because they are rare and users didn't care enough to post and upvote them on kagifeedback.org for it to make a difference. The one you noted has been suggested actually https://kagifeedback.org/d/844-dont-use-extra-searches-for-changing-order https://kagifeedback.org/d/844-dont-use-extra-searches-for-c... and is planned on our roadmap, just not prioritized (just one upvote) and we had bigger fish to fry. Hanlon's razor in general applies well when thinking about Kagi, expect it is not (always) stupidity but lack of resources.
- Jochim 3y ago> Hanlon's razor in general applies well when thinking about Kagi, expect it is not (always) stupidity but lack of resources. Please don't feel that I was making any hard judgements about Kagi or yourself based on the points I mentioned. My only intention has been to learn a bit more about the product and provide some insight into what someone evaluating the product for the first time might feel. I appreciate that the points may come across as hostile/challenging but I'd be happiest if they were rebutted easily. Your present response does raise some concerns however. > Kagi is selling searches at cost This is a different claim from your blog post on 08/03/23 where the cost of each search was 1.25 cents. If this isn't the case, you're losing money on any annual unlimited subscribers that make more than 1,416 searches each month. > and we make money on subscriptions If this is the case, why not differentiate the subscriptions based on their value-add features and operate an upper bound of $25/mo on the amount charged for searches for all tiers? If you're making money off of the subscription, why don't the search quotas roll over? Together, these three points give the impression that the aim is for subscription search quotas to be under-utilised rather than to provide the searches at cost. > You point out some valid use-cases there and the reason we haven't addressed them so far is probably because they are rare and users didn't care enough to post and upvote them on kagifeedback.org for it to make a difference. That's a fair point regarding general feedback. I can't speak as your average user but as someone that wasn't already invested in the product they were areas that introduced friction in the decision of whether I'd like to pay for the product or not. A user evaluating the product is unlikely to post why they haven't converted to kagifeedback.org, even if they're aware of the site. It's worth bearing in mind that issues for potential users may not be a problem for existing users, apportioning time to the desires of both groups is a difficult balance. > and is planned on our roadmap, just not prioritized (just one upvote) and we had bigger fish to fry. My personal perspective is that it's absolutely unacceptable for a company to double-charge due to their own UI decisions. Spurious billing in general is something I would expect to be treated as top priority on an ongoing basis. Treating it's occurrence as a feature request raises serious concerns, especially regarding how similar/more impactful situations might be handled. I'm disappointed, there's a lot to like about the product itself.