Hi. Hope you guys can help with a conundrum I'm having.
I have a web app (ClarifyPDF) that lets people upload a PDF and then ask it questions (one of those "Chat to a PDF" apps). The answers come from OpenAI's API in the backend. I charge $1.99 per upload.
There is no signup, but they do have to provide an email address during upload. And I don't want to add signups and logins, etc.
I want users to be able to take it for a spin before paying $1.99. So I'm thinking of offering 3 free questions after upload, and then they pay if they want to ask more questions.
However, this opens it up for abuse, where a user can keep uploading the same document and keep getting 3 free questions. Of course, the inconvenience for them is that they don't get all the answers on the same page as each document has its own "chat" page history.
So, what do you think? Is the approach above safe? Am I overthinking it? Is there a better way to provide a trial without asking them to "sign up"?
Thanks for any help!
Forget about it until there is proven abuse of your service. Maybe it won't be a problem after all.
If it's a problem, I would do the following:
Make some kind of unique key based on the content of the pdf + the fingerprint of the visitor. (check out https://amiunique.org/)
That way, you can pretty surely prompt them to pay up, if the same pdf is being uploaded again by the same user.
No point in worrying about abuse when realistically you arent sure you're even going to get valid users.
Agreed, to both your comments. I'm over-optimising and overthinking it. Thanks for the clarity!
why don't you offer the free credits post-login?
I am assuming you already have integrated a Google Auth
Then the flow would be: Landing Page>Google Auth>Free credits>Upgrade
This way you can avoid maximum abuse as most people do not have a lot of free Gmail accounts lying around
I'm overthinking this exact question too much myself. But I must say, that you should probably worry about that once it happens.
BUT - probably have a contingency plan if it blows up, like spending limits, or some simple IP rate-limiting - most auth platforms should provide this if you decide to go the login route.
I like this. Just have a way to stop the bleed if it happens, but not to overthinking it right now.
Thanks!
You could create a hash of the document and count the number of questions against that hash. The downside of that is that if different users upload the same document, the number of questions are shared between all users. But since you don't really have a way of identifying users, it seems like a good solution, and it's easy to implement.
hash + user fingerprint will do the trick.
Thank you!
Probably good to ask them to create an account, and maybe offer a monthly subscription with unlimited use for a certain amount of money per month.
Best option is to add a simple sign up with their social accounts in that way, it takes the pain to create a new account with email and password etc. That's the best way to approach this else it's going to be a difficult one
Wait until this becomes an actual problem
Fingerprint the file + the user (as suggested)
or
@farez Have you gotten users yet to where this has become a problem yet, If yes how many users?
Great article! Offering a free trial can be a powerful strategy for attracting new users while minimizing abuse. One approach I've found effective is implementing usage limits or time restrictions during the trial period. This ensures that users can experience the value of the product without exploiting it. Additionally, leveraging user onboarding and educational materials can help set clear expectations and guide users towards making the most of the trial. If you're looking for more insights and tools to optimize your free trial strategy, be sure to check out 𝟏𝐭𝐨𝐨𝐥𝐬.𝐜𝐨. They offer a wealth of resources for entrepreneurs and product creators. Keep up the good work!
thanks for
I am working on a ChatGPT/Document problem right now as well with my start up. Why not keep a hash of the file and store it in memory when you want to begin throttling it after the 3rd question... This will allow you to even do things like "one question per day after first three". If the hash of the file is in memory then reject the question. Then you can kind of give users even more of an itch to spend money on unrestricted access.
The suggestion that users be able to ask 3 free questions after downloading and then pay for additional questions sounds interesting. However, to prevent abuse, try Implementing a reload check mechanism. For example, you can use technology that identifies unique documents, or associate each document with a unique ID to prevent re-downloads.
"Connect with LinkedIn"
Offer a refund if they didn't enjoy it. but charge it first.
Adding a sign up and authentication process is a lot of code to write, but if you are ultimately going to charge people, you are going to have to eventually set one up. I went through the same struggle before biting the bullet and setting-up authentication for products I built. In the long run, it will help you prevent against free trial abuse because you can tie a $0.00 authorization attempt to validate serious users before giving the a free 3-questions.
At the end of the day, you are planing to charge for your service ($1.99), you might as well charge now and see if there is a viable business model instead of wondering.
I don’t think you should worry about it, I also offer a 100% satisfaction or refund on my website convertixo, they can easily fake and get a refund, but no one has done it yet, no point of worrying until there is enough abuse that can impact your business.
I don't think it's really a problem.
If users don't want to pay, they won't pay. You can do what you want they will find a way to use for free your tool or use another one.
If users have value to use your tool, they will pay. Try for free is perfect to test, maybe let more that 3 answers to have a bigger test ?
Do you know how many search users do per day for example ?
I've always thought about such a problem, you could think of an email+ip address + document identification, it's easy to implement. but if the problem hasn't appeared yet, it doesn't exist for now.
If I were you I would think of a minimum of tolerated abuses, once exceeded, I would think about the implementation, you can also think of an account verification via sms, which is very difficult to bypass compared to an email verification, and is a cheap solution.