Privacy Policy

You never have to say who you are, and we do not try to work it out. Our server, and the CDN in front of it, necessarily see the ordinary shape of a web request — the URL, the time, the browser string, the IP address it came from. That is how a request reaches a server at all; what matters is that none of it is assembled into a profile of you, and none of it is passed to anyone who would.

The one thing we set is a random session id in a cookie called sid, and only when you click through to a tool, when a listing reports that it was viewed, or when you send us something — a form, a sign-in, a save. Reading a page on its own sets nothing. The id is a random number: it is not derived from you, and it says nothing about you beyond tying your own actions together so a reload is not counted as a second visitor.

We do count the pages you open, but without a cookie and without remembering you from one day to the next — what that count holds is described under page counts.

When you view a listing, click out to a tool, save one, rate one or post on one, we append a row with:

• what happened (view, click-out, save, rating, post);
• which tool it was about;
• the random sid, and your account id if you are signed in;
• the page that referred you, when your browser sends one;
• a two-letter country code, from the CDN — country only, never a city, coordinates or an address;
• one of three device buckets — desktop, mobile or bot — derived from the browser string. The browser string itself is not stored.

No IP address is written to our database. Addresses are used only in short-lived abuse counters held in memory and in our cache — per-address request budgets counted over a minute, an hour or a day and gone within two such windows (two days at the very most), and a daily counter of how many distinct sessions one address presents, kept in a structure that counts without storing what it counted. Neither is joined to the events above. The page counts below use the address once more, inside a one-way daily hash, and drop it.

What these numbers are for: the counts you see on a card, the click-out totals a listed tool’s owner is shown for their own tool, and the demand signal in the effect score. Owners see aggregates for their own listing, never a list of people.

Every page you open sends our server a short note, from our own code, so that we can see how many people read the site and how they found it. The row it becomes holds:

• the page’s path, without the part after ?;
• whether you arrived from outside or clicked through from another of our pages, and for an arrival, the name of the site that sent you — its domain only, such as google.com, never the address of the page you came from, which can contain what you searched for;
• the campaign tags a link carried (utm_source, utm_medium, utm_campaign), when it carried them;
• a two-letter country code from the CDN, and desktop or mobile from the browser string;
• whether you touched the page at all — a click, a key, a tap, not which one or where — and how long it was on screen;
• a daily visitor code: a one-way hash of your address and browser string mixed with a random value that is generated each day and deleted after it. The same browser on the same day gives the same code, which is how we count one reader once; the next day it gives a different one. Once that day’s random value is gone, nobody — us included — can compute the code from an address again or connect it to any other day.

No cookie is set and nothing is stored in your browser for this. Crawlers that name themselves are not recorded, and neither are the site’s administrators.

One page is an exception to “anonymous”: when you open the listing-price page (/submit) while signed in, our team chat is told which account opened it — see Telegram under “Who else touches the data”. The row itself still holds no account.

Tools listed here can carry our badge — a small image served from our domain — on their own sites. When a page showing it asks us for the image, your browser normally says which site the page is on, the way it does for any image. From that we keep one thing: the site’s domain, such as acme.com, counted per badge per day, with the time of the latest request. It tells a tool’s owner where their badge is seen, and lets us confirm a badge our checker cannot read.

Never the address of the page itself, never your IP address, no cookie, nothing about you: the row is about the site, not its reader. Our cache answers most of these requests before they reach us, so the counts are rough floors. Owners see the domains and counts for their own badge only — and, from the page counts above, how many visits the badge’s link sent them: a number, never who.

When a search on /search finds two tools or fewer, the page tells our server what was searched, so that we can add the tools people look for and do not find. We keep the words of the search — in lower case, cut to 80 characters — with the day, how many times that day it was searched, and the fewest results it got.

Nothing that points back to you is kept with it: no account, no session id, no IP address, no browser string, no page you came from. A search that looks like personal data — anything containing an @, a run of six or more digits, a web address or a long unbroken code — is dropped before it is stored. Crawlers that name themselves, automated browsers and the site’s administrators are not recorded. The address the note came from only feeds the short-lived request budget described above. What you type before pressing search, while suggestions appear, is not recorded.

If a page fails in your browser after it has loaded — a script error, or the “something broke” screen — the page sends us a short crash note so we find out without you having to tell us. It holds the page’s path without the part after ?, the error’s name and the first line of its message, and an error ID when there is one. Our server adds one of the three device buckets above.

The note carries no session id and no account, it sets no cookie, and it is written to the server’s log rather than the database. The address it came from only feeds the same short-lived request budget described above.

Assistants such as Claude or ChatGPT can query the catalog through our MCP server. It answers with published cards only, sets no cookie, needs no account and writes nothing to the database.

The server’s log gets one line per request: which tool ran, whether it worked, how long it took, and the name the assistant gives for itself. Not the question or search text, and not the address the request came from — that only feeds the same short-lived request budget described above.

Three, all first-party, all functional. There is no advertising cookie, no analytics cookie and no third-party script on the site; the page counts above are made by our own code without a cookie. The fonts come from our own domain, the map draws tiles we built and host ourselves, and a tool’s icon is fetched by our server and re-served from our domain rather than hot-linked — so reading the catalog does not hand your browser off to anyone else.

• sid400 days

  A random identifier with nothing in it — no name, no address, no fingerprint. It is what lets us count one visitor once instead of counting every reload. It is set only when you click out to a tool or when a listing reports a view, never merely for reading a page.

• eh_session30 days

  Your sign-in session, and only after you sign in. The server stores a hash of it, so the cookie in your browser is the only copy of the token itself.

• eh_oauth_state10 minutes

  Set only while you are signing in with Google, to tie the round trip back to the browser that started it and to remember where to send you afterwards.

Clearing them costs you nothing but a sign-in: delete sid and a new random one is minted the next time you click out, with no way to connect it to the old one.

One more thing lives in your browser’s own storage rather than in a cookie, and only if you start the listing form on /submit: what you type into it, so the form survives a sign-in that expired halfway through. It stays in that browser — we receive none of it until you press Submit. It is deleted when you submit; left unfinished, it expires after a week and is removed the next time the form opens. Your password is never part of it.

An account is optional. Everything in the catalog is readable without one; an account exists so that saves, reviews and questions have an author.

What we store:

• your email address, and either a hash of your password (never the password) or the id of the Google account you signed in with;
• a display name and an @handle, which is public — reviews, questions and answers are published under it, and the page of a listing you own links to your profile by it;
• anything you choose to add to your profile: bio, website, country, social links. All optional, all public, all editable at /settings/profile;
• a profile photo, if you upload one. We keep a 256-pixel square we make from your picture, on our own server; everything else in the file — camera details, location metadata — is discarded at upload. It is public wherever your name appears, and the file is deleted the moment you replace or remove it, or delete the account. We never load a photo from a link you paste, so no other site learns who views your profile;
• what you post and what you save, and the reputation points those earn;
• your up/down votes on tools. Only the two totals are ever shown — the list of who voted stays on the server. A vote lives until you retract it (clicking the same thumb removes it) or until the account is deleted, which deletes every vote with it. Votes cast during a calendar month also decide that month's awards among new tools (on /new): when the month closes we keep, for each tool that placed, its place and its vote totals — never who voted — for as long as the tool stays in our catalog. A maker's vote on their own listing and our staff's votes do not count toward an award.
• the tools and tasks you follow, and which of our emails you switched on. Nobody but you sees what you follow — no page shows a follower count or a list of followers. What the emails are, and how to stop them, is under email we send.

Sign in with Google is optional and asks Google for the standard sign-in scope only — openid, email and profile. It works only with a Google-verified email, and we store the account id, the email and the name. If you already have an EffectHub account with that address, Google signs you in to it. We are never given your Google password and never ask Google for anything else.

Submitting a tool needs an account, and stores what the form asks for — the site, the copy, the category and the plan you chose — under it, so we can tell you the outcome at the account’s address. It does not subscribe you to anything. Pressing “Fill with AI” sends the public page you named to OpenAI for a draft (see “Who else touches the data”); typing the form in yourself sends nothing anywhere.

If you own a listing, two more things are yours to write. Competitors you name for it are kept with your account, the time you named them and our answer; an approved pair is shown on the listing as “Named by the maker” and can get a comparison page, but your name and handle are never printed with it. Release notes you log are public: on the listing’s page, under “Recently updated” on /new, in its RSS feed and in our Telegram channel.

Two kinds, and the second one only if you ask for it.

About something you started. Your submission was received, approved, or rejected with the reason, or went back in the queue because our daily check found the badge you added after a “no badge” answer; a request about a listing was decided; a free listing came down because its badge went missing. These go to the address you gave us and need no subscription.

Alerts and the weekly digest — only if you turn them on. With an account you can press Follow on a tool or on a task page. Following a tool switches on alerts about it: when its listed price changes, when it stops responding to our checks or is marked as acquired, and when it publishes a release — collected into one email a day at most, and none on a day nothing happened. Following a task brings a note, once a week at most, when new tools are added to it. The weekly digest — the week’s new tools, the ones that shut down and the newest post from our blog — is off until you switch it on at /settings/notifications. Nobody is subscribed for having an account, for submitting a tool or for anything else they did not ask for.

Each of these emails says why it arrived and ends with a one-click unsubscribe link; mail apps that support it also show their own Unsubscribe button, which does the same. No sign-in is needed, and opening the link changes nothing until you press the button on the page. It stops that one kind of email and nothing else, and it does not contain your address or your account. You can also switch each kind off, or unfollow anything, at /settings/notifications.

There is no advertising or sponsored content in them and no tracking pixel, and we never sell, rent or share your address. Their links point at our own pages and say they came from an email, so a visit they bring shows up in the page counts as one from email — which, as everywhere, holds no account.

• Cloudflare

  DNS and CDN in front of the site. It terminates the connection, so it sees your IP address and the request, and it is where the country code on an event comes from. Mail you send to [email protected] passes through its email routing on the way to our inbox.

• Resend

  Sends the email described above — the messages about something you started, and the alerts and digest only if you turned them on. It receives the recipient address and the message, one message at a time; no list of addresses is ever uploaded to it.

• Google

  Only if you choose Sign in with Google. We ask for openid, email and profile, and Google tells us your account id, email address and name.

• OpenAI

  Only if you press “Fill with AI” on the listing form. We send the public homepage you named — its address, title, description and visible text — and our category list to OpenAI’s model through the Codex service we already use for our own work, and get back a draft of the listing. Nothing about you goes with it: no account, no email, no address. The draft is shown to you to edit, not stored on our side; the request is not stored for training. Without the service configured the button fills the form from the page’s own title and description instead.

• Telegram

  Posts a short note to our own team chat when an account is created, when a signed-in account types a site's address into the listing form or presses “Fill with AI” on it (with whether the draft came back or the service failed), when a tool is submitted, when someone claims, or asks us to promote or hide, a listing, when someone opens the listing-price page, and when a review, question or answer is held for moderation. It carries the account's email address, how the account was made, the tool's name and site, the plan you chose, a country code, for the listing-price page the site you came from — and the account's email only if you were signed in — and, for a held post, its text and star rating (and, for an answer, the question it answers), so the post can be read before it goes live. Never your IP address, your password or your session.

Nobody else. We do not sell data, we do not share it with advertisers or data brokers, and there is no third-party tracker embedded in these pages. We would disclose data if a valid legal order compelled us to, and we would say so publicly where the law allows it.

The site runs on our own server rather than a platform, so the database and the cache are ours and the data in them is not passed to anyone beyond the services listed above.

• Abuse counters — two windows of the budget for a request budget (a minute, an hour or a day each, so at most two days), at most a couple of days for the per-address session counter. Then they are gone.
• Sign-in sessions — 30 days, or until you sign out. Changing your password, or “sign out of other devices” at /settings/security, ends every session but the one you are using, on the spot.
• Profile photo — until you replace or remove it, or delete the account. The previous file is deleted on the spot, not kept as a version.
• Event rows — kept while they are useful for the counts and rankings they feed. We do not yet run an automatic purge, and we would rather say that than print a retention period no job enforces.
• Page counts — 13 months, then deleted automatically. The daily random value behind the visitor code is deleted within two days of the day it served.
• Badge sightings — the domain of a site showing our badge and the daily count, 13 months, then deleted automatically by our daily badge check.
• Searches that found nothing — 180 days, then deleted automatically. They hold only the words searched, a day and a count.
• Crash notes — never in the database; they live in the server’s log, which the system rotates out as it fills.
• Account data — until you ask us to delete it.
• Follows and email settings — until you unfollow, switch the email off, or delete the account, which deletes them with it.
• Email journal — for each alert or digest we send: which account, which kind, which day or week it covered, how many items it named and whether it was delivered. Never the address and never the content. It is what stops us from emailing you twice, and it is deleted automatically after 180 days.
• Listing requests — when you claim a listing as yours, or ask us to promote one or take it off the site, we keep the request: your account, the listing, the note you wrote and our answer. It is the record of who was given which listing, so it lives as long as your account does.
• Competitors you name — the pair, your account, when you named it and our answer, for as long as the listing exists. Withdrawing a pending or approved name deletes it; a name we turned down stays as the answer. If your account is deleted, the pair stays with the listing and the link to you is removed.
• Moderation records — when a moderator approves or rejects something you submitted, or changes your account's role, we record which moderator did it, when, and what changed. The record holds internal ids and the changed fields — never an email address, a password or an IP address. It is kept without a time limit, because it is how we answer “who approved this, and why”; once an account is deleted, the bare id left in it no longer leads to anyone.

You can read the catalog without an account, edit or empty your profile at any time, sign out to drop your session — or, at /settings/security, change your password and sign out every other device — and clear our cookies from your browser. Any alert or digest email stops with the one-click link at its bottom, or at /settings/notifications.

Ask us and we will give you a copy of what your account holds, correct it, or delete the account and the content posted under it. There is no self-service delete button yet — a person handles the request — and we will confirm when it is done. Content already published under your handle is removed with it; the anonymous event rows are not tied to your identity and are not individually recoverable from it.

Depending on where you live — the EU, the UK, California and others — the law gives you rights of access, correction, deletion, portability and objection. We will honour a request on those grounds. What we will not do is claim a compliance certification nobody has audited: this is a young site describing its actual practice, and the practice is meant to be the honest one rather than the well-worded one.

Requests reach us through the channels on the contact page.

The site is not directed at children, and we do not knowingly collect data from anyone under 16. If you believe a child has created an account, tell us and we will remove it.

When this changes we update the date at the top. A change that affects what we collect, rather than how it is worded, will be said plainly rather than folded into a paragraph.

Questions about any of this go through the contact page.

Terms of ServiceHow we verifyAbout