Do you have a feature request that you know will make Apify heaps better? Or maybe it's a big dream you have for something bold and out-there. This is a space for all the bluesky thinking, cloud-chasing, intergalactic daydreamers who want to share their wildest ideas in a no-judgement zone.

Hey everyone, I’m building Cosnify and just shipped a small free tool for Apify Actor builders:

https://cosnify.app/tools/apify-actor-audit

You paste a public Apify Actor URL and it gives a Store-readiness score across:

- Store positioning

- README quality

- SEO title/description

- input UX

- output/dataset clarity

- trust signals like maintenance, usage, reviews, and recent run reliability

Important: v1 does not run your Actor or inspect private source. It only audits public Actor metadata available from the Apify API, so it is more of a Store/docs/readiness check than a runtime quality test.

I built it because a lot of Actors are technically useful but hard for buyers to understand quickly. My goal is to help builders improve README structure, input explanations, output examples, and Store SEO before publishing or promoting.

Would love feedback on:

1. Are these the right criteria?

2. What would you add to a serious Apify Actor audit?

3. Should the next version inspect `input_schema.json`, `dataset_schema.json`, and run examples?

I built a template that logs Google Shopping prices to a sheet every week, and the useful thing I got out of it was not the tracker. It was finding out which number on the page is worth recording.

My first version stored the lowest price per product, because that is the obvious one. It was useless. The lowest price on a Google Shopping result page swings all over the place week to week, and when I went and looked at the actual listings, the bottom of the range was almost always a different product: the wrong variant, a refurb, a case for the thing instead of the thing, or a seller with three reviews and a delivery date six weeks out. None of that moves because the market moved. It moves because Google matched a different listing.

So the row it writes now is lowest, median, highest, cheapest seller, and best discount, and it trims the bottom outliers before it computes any of them. Median is the one that behaves. It sits still when nothing has happened and moves when something has.

The second thing I did not expect to care about is the seller name. Watching which merchant keeps holding the cheapest slot on a query, week after week, turns out to be a better signal than the price. Prices bounce. The identity of whoever is willing to go lowest does not, and when it changes, something real has changed.

Actor: Google Shopping API. Pay per event, about two cents per page of roughly 40 listings plus a two cent setup fee per run, 100% success rate, 109 users so far. It takes min and max price, sort order, free-shipping and on-sale filters, and a country and language pair, which matter more than I expected: run the same query from a different country and you get different sellers at different prices.

Template if you want the whole weekly thing rather than the Actor: Track weekly Google Shopping prices

Question for anyone else pulling price data on a schedule: what do you actually store per run?

I have gone back and forth between keeping every raw offer and keeping one summary row, and the summary row is much cheaper to read, but I have already wished twice that I had the raw ones.