Purpose of this post: This post is not a feature request or complaint. Its purpose is to seek clarity from the Apify team and invite input from the developer community regarding the confusion around the PPE (Pay Per Event) billing model. I’d like Apify to clearly state what’s allowed and what’s not allowed when it comes to PPE billing practices, so that developers can align their actors accordingly and avoid policy violations. Recently, after a discussion with @Saurav Jain , I was informed that my current PPE charging method is considered unfair and against Apify’s policy — and that action might be taken on my actor. Hence, I’m outlining the key issues here to get clarification, so that: • PPE billing can be updated correctly, and • Other developers can learn from this discussion until it’s officially documented and published. I’ve thoroughly read: 🔗 Apify Docs - Best practices for PPE actors However, this article only provides recommendations, not clear policies defining what is or isn’t allowed. @Lukas Krivka @vladdy @Saurav Jain

message has been deleted

🧠 1. Memory Scaling I have been developing actors that can run on memory as low as 1 GB, and the user can choose to run the actor in 2 or 4 GB as well if they want faster execution. The actor also supports thread count as input, and if the user wants to use residential rotating proxy, they can choose to have 4 threads as well. That means memory can be 4 times higher, resulting in 16 GB as well. So, in summary, the same actor can span any memory from 1 GB to 16 GB. Since Apify charges developers multiple times more when memory grows, it seems logical that users should also be charged proportionally based on memory usage. 💬 Question to Apify: Is it allowed to charge users a multiplier based on memory usage? For example: • A run with 2 GB producing 10 results • vs a run with 16 GB producing 10 results → Apify’s cost is 8× higher, yet the user’s result count is the same. Currently, I apply a charge multiplier to compensate. If this practice is not acceptable, please clarify what the expected approach is. -----------------------------------------------------------

Hey Dhrumil, thanks for the message we will reply you on working day!

💾 3. Key-Value Store Usage (Incremental Crawling) Key-value platform usage cost is 12x that of dataset writes. I have scrapers that provide incremental scrapes, and customers love that feature. They come back after 1 week and just get new items added to the target site. This requires access to key-value storage. That means the crawl can run for 1 hour and still find only 10 new items. I can’t solely rely on pay-per-data item delivered here. I will be at a huge loss otherwise. This also means that a run can last 20 minutes checking 1,000 key values and crawling but may find no new items listed on the target site. However, the customer should be charged for crawling and all the key-value read/write operations to be fair. 💬 Question to Apify: Please provide the right way to do this. Also, when such key-value checks are involved, the cost of one record is significantly different from that of a normal customer who is not using the incremental update feature. To accommodate both customers, I have added a charge multiplier for the customer who prefers incremental updates and 0 additional charge for the customer who is not using it, to be fair. Is this an unfair practice? If so, what is Apify expecting as the right way? In this scenario, a customer might get 0 results but still get charged for crawling. Is this against policy? Currently, Apify is accusing PPE developers of charging customers even without results and mentioning that it’s strongly against it. But this idea of result-based thought process needs to be reviewed by Apify itself when it comes to PPE actors since underlying platform cost is not per result. ------------------------------------------------------------

@Dhrumil just advanced to level 4! Thanks for your contributions! 🎉

Hello @Dhrumil, I don't think we need to talk necessarily in terms of allowed of not allowed. But if your pricing is very different from the rest of Actors and also confusing or not well explained in the readme, we might expect more user issues and more work for our support teams. Because of that we might want to promote your Actors less than we would normally. I believe most of the problems you are trying to solve can be dealt with more "native" approach. 1. For now it is best to just allow only low memory to protect your margins, especially for single URL runs. For large runs, if you run a concurrenct workflow, the memory/CPU should be fully utilized. Soon we will release a "dynamic memory" feature where the memory will be set by yuor function depending on input. So you can tailor it for each run instead of user. Having these multiples in the results is just confusing. 2. You can add an event for charge extra if residential proxy is used. See e.g. https://apify.com/vdrmota/contact-info-scraper/pricing. You can also offer it as "country selection". In ideal case, if one proxy works much better than other, you just hardcode that, e.g. we use residential for Instagram but datacenter for Google Maps. 3. This is a tricky one and we ourselves didn't yet find a great model. I think something along paying a small amount for "cached data" or making the provided data more expensive is fine. 4. The problem is simply having two subscription levels, one for Apify, other for individual Actors. This is really hard for customers to orient themselves. In a lot of cases, you can use the Apify Store Discounts where you give better price based on their Apify subscriptions. Yes, they might spend it on other Actors too but often they only use 1 or 2 Actors. We know that developers would love type of rental subscriptions but developers also benefit from a good UX of plain PPE, many have very stable income just with that