[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2u5x2oa1qygvp":3},{"code":4,"message":5,"data":6,"timestamp":26},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":22,"homepage":23,"updated_at":24,"history":25},"surendrapandar\u002Fminilytics",8,"Opensource Revenue-first analytics for indie hackers & solo founders ","TypeScript",221,57,112,2,[],"A self-hosted web analytics app that connects payments to traffic sources, built for indie founders who want revenue attribution.","Minilytics is worth a look if you run your own site and your main question is \"which traffic source actually paid me?\" rather than \"how many pageviews did I get?\". It is a self-hosted, Cloudflare-based analytics stack that records visits, goals and Dodo Payments transactions in one place.\n\n## The problem\n\nMost simple analytics dashboards stop at traffic: you can see that a launch tweet sent 400 visitors, but not whether any of them bought anything. To answer that, a solo founder typically stitches together a web analytics tool, a payment provider's dashboard and a spreadsheet, and then manually matches timestamps or customer emails. Minilytics changes that step by storing the visitor and session identifiers alongside payment webhooks, so the dashboard can show revenue per channel, per campaign and per individual customer journey. The result is a single view where a tweet, an article or a ChatGPT referral carries its own revenue figure.\n\n## What's different\n\nThe core mechanism is a first-party cookie pair (`ml_vid` and `ml_sid`) that the 9 KB tracker sets on your root domain. Dodo Payments webhooks are recorded server-side, and the app uses a documented priority order to attach each payment to a prior visit: last non-direct touch first, then the checkout return page (`?payment_id=`), earlier payments from the same customer, an `identify()` email, and finally checkout timing when only one visitor clicked a Dodo checkout link in the preceding three hours. That order matters because the simplest attribution signal — a direct return visit — is deliberately not allowed to overwrite the original source. The README is also explicit that refunds are subtracted and that each payment's matching method is visible in the Journey tab, which makes the attribution decisions inspectable rather than hidden. The important trade-off is that this is not a general-purpose attribution engine: the documented deep integration is Dodo Payments, while other providers must post to a generic payments API with the visitor cookie, and currency conversion only occurs when Dodo supplies a settlement amount in the site's currency.\n\n## Who should try it\n\nA good fit is an indie founder selling through Dodo Payments, running a content or social launch strategy, and comfortable deploying a Cloudflare Worker. They get source-level revenue attribution and a Journey view without paying a per-event SaaS bill. A poor fit is a team that needs multi-provider billing attribution out of the box, or one whose compliance or marketing stack requires a hosted vendor with an established integrations catalogue. The documented setup is a full self-deployment: clone the repository, create a D1 database, set an admin password and session secret, and deploy through Wrangler. The README also describes a “Copy AI prompt” button that lets Claude Code or Cursor perform the site-script install inside your codebase, which lowers the integration effort for the tracker itself but not the Cloudflare deployment.\n\n## Requirements and limitations\n\nThe constraints that matter most are operational. You need a Cloudflare account, Node.js 20+ and Git, and you maintain your own database and deployment; updates involve stashing the `wrangler.jsonc` edit, pulling, restoring it and redeploying. On the free plan, the documented limits are about 100k Worker requests per day, roughly 10k pageviews per day from D1 row writes, several hundred dashboard loads per day at 10k visitors per month, and 5 GB of D1 storage; the README says side-project traffic uses a few percent and that Workers Paid is $5\u002Fmonth if you outgrow it. Accuracy has documented gaps: ad blockers can block the script, Safari caps JavaScript-set cookies at seven days so returning visitors can be counted as new, bots are filtered by user agent and `navigator.webdriver`, and exact post-level attribution for X, Medium and LinkedIn requires tagging links because those platforms hide the specific post. Payments are still recorded by webhook when browser tracking is blocked.\n\n## HotRepo's take\n\nHotRepo only has a single dated snapshot: a 2026-10-25 observation on the NEW-REPOSITORY board for TypeScript showing 135 total stars and rank #9. That is not a daily growth measurement, and with no comparable daily-board history, persistence cannot yet be judged. The README is unusually specific about attribution order and accuracy gaps, which is the right thing to inspect before adopting: verify that your payment flow actually populates the visitor cookies in the place your provider expects, because the fallback order is doing real work when metadata is missing.\n\n[Project source and documentation](https:\u002F\u002Fgithub.com\u002Fsurendrapandar\u002Fminilytics)",{"slug":19,"name":20},"data","Data",[],"MIT",null,"2026-10-25T12:46:30Z",[],1792968257]