Privacy

TwelveTabs is a free tool. This page describes what the software actually does today, not what a policy of this kind usually says. It is a factual description.

There is no account

You cannot sign up and there is nothing to sign in to. We never ask for your name or a password, and we never take a payment. The site does not currently show any form that asks for your email address. The price-watch storage endpoint remains live, as described below. We do not sell or share anything for advertising, and there are no advertising trackers on this site.

How we recognise you

On your first visit we set a cookie, tt_uid, holding a random identifier. It lasts a year, and it is how we tell a returning visitor from a new one. That single question, whether anyone comes back, is why this early version exists. The identifier is not a password. The cookie itself is hidden from page scripts, and your browser does not send it to other websites. We also put the identifier in page data, where page scripts can see it, and share it with PostHog so the analytics described below can be joined to searches stored under the same label. We use it to match your stored searches and saved picks, so anyone who obtained the identifier could see your Recent and Saved picks lists and change which picks are saved. They could also rename or permanently delete your searches, or add to a search you started, and what they send is stored as part of that search.

Two more values are stored only to make the page look the way you left it: a cookie, tt_rail, remembering whether you collapsed the sidebar, and a browser storage entry, tt-theme, remembering light or dark.

Those three are the ones we issue. PostHog, described below, stores its own cookie and its own browser storage entries as well, on every page including this one, so it can tell one session from the next. They are named ph_ followed by our PostHog project key.

What we store when you search

• The search you typed, the answers you gave to our follow-up questions, and both the research and the recommendation or refusal we produced. Those are kept as messages in a conversation, in the order they happened. The saved research includes the Amazon search phrase, ranked products, follow-up questions and live product details, and the pick, if any, and the reasoning we wrote are kept alongside it. Only follow-up questions you reached before choosing the search are kept with the conversation, including ones you skipped. A later question prepared in advance stays only in the shared question cache described below, without a visitor identifier. The conversation also keeps how its latest search ended and, when there is one, the reason, such as no suitable match, a spending limit or an error. While a search is running, copies of its research events are also kept in a reconnect log attached to the conversation, so a backgrounded tab can recover what its stream missed. See what we use it for, below.
• Your IP address, unaltered, along with the country, city and network that Cloudflare reports for it, and the user agent string your browser sends. This version is shared by link with roughly fifty friends and family, and a real address is more use than a scrambled one when one of them says something broke. We intend to scramble it, and have not done so yet. We also keep when we first saw your identifier, when we most recently saw it, and a count that increases on every search request.
• What each search cost us and how long it took: which model ran, how many tokens it used, the price and the latency. No message content. This is also what enforces the daily spending limits that keep the tool switched on for everyone.
• The words you typed, the follow-up questions we generated, the Amazon search phrase we derived from your request and answers, and the ranked results. These are kept in two caches shared by everyone. The question cache is filed under your request and the answer path used to reach that question, lowercased with punctuation removed from the request. When you skip, that cache path follows the recommended option even though your Amazon search leaves the skipped property open. The search cache is filed under the derived Amazon phrase in the same form, so different answers can lead to different cached questions and searches. Neither row carries a visitor identifier, but the words are kept.
• The raw verdict the model wrote. A separate cache files that verdict under a SHA-256 hash of its generation inputs: the model, its output schema and its whole prompt, including your query, any answers to the follow-up questions, and the live product details. The row has no dedicated query, tt_uid or email field. It is not directly keyed to a visitor, and its rows cannot be reliably located from a visitor record.

Price watch is not currently offered

The price-watch form is hidden, so the site does not currently ask you for an email address. The endpoint behind that form is still live. If someone sends it a valid request after a search, it stores the email address in lowercase, the product’s ASIN, the tt_uid and the time of the request. There is still no account and no password. No alert emails are sent yet, so an address sent directly to that endpoint is collected and not used. Deleting the visitor record also deletes the watch and its email address automatically.

Sharing a search

A finished search has its own web address, which you can copy from the page and send to anyone. Whoever opens that link sees the search as it was when it ran: the words you typed, the product we picked, the alternatives we listed and the reasoning we wrote. For searches run since 2 September 2026 we also keep the answers you gave to the follow-up questions. The page does not list them as separate chips. For searches run since 4 September 2026, the answers are used to derive the Amazon search phrase it shows. That phrase can omit details such as prices and exclusions, but other answer details may still appear there, and the reasoning may repeat details from them. The link works for anyone who has it. There is no sign-in. The person whose browser created the search can permanently delete it, which stops the link working for everyone. Until then, opening a link is a visit like any other page here: it is counted, and it may be recorded, under the visitor identifier of the person who opened it, exactly as described on this page. The page itself shows nothing about the person who ran the search: not your identifier, not your address, not your other searches. The link works for 90 days after the search ran, counted from the search itself and not from when it was last opened. After that, opening it shows a message saying the saved search has expired, and the search itself stays stored under the rules in how long we keep it, below. The address is a long random code that cannot be guessed, and we ask search engines not to list those pages, but the only thing protecting a link is who you send it to.

Saved picks

A search that ends in a pick can be saved with one click, from your own result or from a link someone sent you. A saved pick is one row in our database: your tt_uid, the identifier of the search and when you saved it. It is tied to the cookie on this browser and not to an account, so another browser or device shows nothing, and clearing your cookies loses the list. If you have never searched, the first save also creates a visitor record containing that identifier, its first- and last-seen timestamps, and a search count of zero. It does not add your IP address, location or user agent to that record. You can keep up to 20 at a time. Removing a saved pick deletes that row. A saved pick stops appearing 90 days after the search it points at ran, the same cut-off as a shared link, and saving does not extend that. The search itself is kept under the rules in how long we keep it, below. Saving and removing are each counted as an event in the analytics described below, with the identifier of the search and not its text.

What we use it for

Here is what we use it for. We do not sell it, we do not share it for advertising, and we do not use it to build a profile of you.

• To make the product better. Reading real searches is how we learn what people actually ask for, where the app confuses them, where a recommendation was wrong, and which parts to build next.
• To show your own history back to you. Your past searches, the picks you save and the products you ask us to watch are all meant to appear in the sidebar so you can pick up where you left off. That is why the conversations are stored against your tt_uid rather than thrown away after each search.
• To reuse the research for a matching search. The shared question cache lets a matching request and answer path reuse its next follow-up question. The shared search cache lets a matching Amazon phrase reuse its ranked candidates. If the verdict's complete generation inputs also match, the separate verdict cache reuses the raw model answer.

The Recent list and Saved picks are live now. Price watch is not. Recent shows your finished searches while their shared links still work, under the lifetime described above, and the sidebar, the menu on a phone and the History tab all show that same list. Saved picks lists the finished searches you chose to keep, newest save first, under the rules in the saved picks section above. The Price watch item is hidden from that sidebar and stores nothing, and the separate price-watch form is hidden too, though its storage endpoint remains live as described above. When it arrives, this page will say so plainly rather than quietly starting to be true.

How long we keep it

Nothing in our own database is erased on a schedule. A shared link stops working 90 days after its search ran, but that only closes the link: the search behind it is kept unless it is deleted. You can permanently delete one of your finished searches from its menu. That removes the search, its messages and reconnect logs, and any saved pick pointing to it from our database, and it stops the shared link working. It does not remove the cost record, shared cache rows, or your PostHog person and screen recordings. Renaming a search from the same menu replaces the name in your lists with the words you type, and we keep that name until the search is deleted. PostHog keeps screen recordings under its own retention policy and removes them when that period expires. If you want all the data we can identify as yours removed, email info@twelvetabs.com and say so. We will delete three things: the visitor record, conversations, messages, reconnect logs and saved picks, and price watches including their email addresses in our own database; the cached question and search rows we can locate from those messages; and the matching person and their screen recordings in PostHog. An unusual search-cache row whose phrase was cached but not recorded in the conversation cannot be reliably located from a deletion request, so we do not promise to clear it. The same is true of the verdict cache: it holds no visitor identifier and is not directly keyed to you, so it is not included.

Who else sees your search

Running one search calls out to several other companies. Each is given only what it needs to do its part:

• Anthropic and Google run the AI models. What you typed, and any answers you gave to the follow-up questions, are sent to them. To prepare possible next questions, Anthropic also receives the listed answer paths it generated, including options you do not choose. A skip follows the recommended path for deciding what to ask next, but that option is left out of your Amazon search phrase. Today Anthropic turns your question into Amazon search terms and writes the follow-up questions, and Google picks the winner and writes the reasoning. Which company runs which step is a setting and can change between those two.
• DataForSEO runs the Amazon search. It receives only the short search phrase the model produced, never your question.
• Apify fetches the full listing for the few finalists. It receives only their Amazon product addresses.
• Cloudflare hosts the site, stores the database, applies the request limits that protect it from scripts, and runs the one-off check on your first search that tells a person from a script.
• PostHog measures whether people come back, records the screen, records how searches end, and records when the stored first question changed before its answers arrived. It also receives any error your browser hits while using the site, so the failure sits next to the recording of the session that caused it. See below.
• Sentry receives errors from our side, the server: the address of the page that failed and the technical stack trace. Never your messages.

The screen recording, specifically

PostHog records what the page looked like as you used it, which is the only way to see where a search goes wrong. Text you type into the search box is masked and is not in the recording, and so is the heading that repeats the query on a shared search page. The rest of the page is: the Amazon search terms we derived from your question, the progress messages and the results we showed you all appear as they were drawn on screen. The recording is filed under the same tt_uid.

PostHog also records interactions such as clicks automatically. It records when you loaded and left a page so time on page can be measured, when you started a search, how long each step took, and how the search ended. It also records a diagnostic when the stored first question changed between showing the questions and receiving the answers. That diagnostic includes the conversation identifier and counts of submitted answers and answers treated as typed. The event about the ending includes the conversation identifier and, when known, counts of candidates, Amazon results and follow-up answers. It also says whether this was a follow-up and how long the search took. When one of our request or spending limits refuses a search request, PostHog records which limit refused it and which search route was called, but no conversation identifier. Opening a search from your Recent list is counted as an event, with the identifier of that search and not its name. Deleting or renaming one of them is counted the same way. The text of your question is deliberately not attached to our search or timing events. Neither the text of your answers nor the Amazon search phrase we derive is attached either.

One more diagnostic tells us when a page failed to load its own stylesheet, which is what makes the site come out unstyled. It carries the web address of that stylesheet file, how many stylesheets the page had in total and how many of those were ours, whether your browser still listed that one as loaded, how many bytes of it came over the network, which is zero when your browser used a copy it already had, how large the file itself was, how long the request took, the status your browser reports for it if it reports one, and the user agent string your browser sends. It carries nothing you typed and no address of your own.

Counting visits

Cloudflare adds a small script to every page, which reports the visit back to Cloudflare so we can see how much traffic the site gets. It sets no cookie and it does not identify you.

Amazon

We link out to Amazon. The moment you follow one of those links you are on Amazon’s site under Amazon’s own privacy notice, and we cannot see what you look at or what you buy. TwelveTabs is not affiliated with, endorsed by, or sponsored by Amazon.com, Inc.

Children

This is not built for children and we do not knowingly collect anything from anyone under 13.

Changes, and how to reach us

This page changes when the software changes, and the date at the top says when it last did. Anything at all: info@twelvetabs.com.

Back to TwelveTabs