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.

Logging in is optional, for up to three searches a day

You do not need an account for up to three searches a day. After that, TwelveTabs asks you to enter and confirm an email address before it runs another search, and a browser that is logged in has no daily limit. To count, we add up the searches started since midnight UTC under your tt_uid cookie, and the searches started since then by browsers that are not logged in and were last seen from your network address, so that opening a private window does not start the count again: three a day are free for one browser, and five a day behind one address. Nothing new is stored for this; it reads the searches and the address described below. If you want your preferences and searches on more than one device, you can log in with your email address: we email you a 6-digit code, and typing it into TwelveTabs logs that browser in. There is no password, we never ask for your name, and we never take a payment. The price-watch form is hidden, and its 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 Searches 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.

If you log in, a cookie, tt_session, can keep this browser logged in for up to a year. The login ends sooner if you log out, or if either tt_session or the tt_uid it works with expires or is cleared. Because tt_uid may be older than the login, you may need to log in again before that year is over. The tt_session holds a random value, and we store only a scrambled copy of it. The cookie is hidden from page scripts, and it works only together with the tt_uid of the browser that logged in.

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. One more browser storage entry, tt-heard-about-us, decides whether to ask how you heard about us: it remembers that you have seen your first result, that you answered or closed that question, or that you arrived on a link tagged with a campaign source. It does not hold your answer.

If you set what you value, a cookie, tt_prefs, keeps your answers for a year: what matters most, whether you would rather Amazon shipped it, whether you would rather it came with Prime, the lowest rating you will accept, and anything you typed. It is sent with your searches. What you typed can change which answer we suggest to our follow-up questions, and all of your answers go to the AI model that picks the winner, so the pick can follow them. Unless you log in, we do not copy the cookie into our database, though the questions and the pick it shaped are stored with the search like any other. If you save your answers with your email address, we store them with your account. If you log in on a browser that has answers and your account has none, we copy that browser’s answers to your account, and when your account has answers, logging in puts them in this cookie. Saving the default answers removes it.

Those are the general entries we issue ourselves. When Cloudflare Zaraz is available and you are logged in, we give it your random account identifier, not your email address, as user_id. Zaraz’s default keeps that value in your browser’s localStorage across sessions. When a page renders without a logged-in account, we ask Zaraz to remove the value from all its storage scopes. A pending pick rating also uses the temporary browser storage described below. PostHog stores its own cookie and its own browser storage entries as well, on every page including this one, and on our buying guides at twelvetabs.com/reviews/, where it records the pages you view, which Amazon link you open and which guide search you start. It uses them to tell one session from the next. They are named ph_ followed by our PostHog project key. Cloudflare also keeps cookies on this site for Google Analytics, as described in counting visits, below.

Voice input is optional

Voice input uses your browser’s microphone permission and speech recognition. It starts only when you select the microphone and may send audio to your browser’s speech service. TwelveTabs receives the recognised text, not an audio recording. The text appears in the search box for you to review or edit. Voice input does not submit a search. If you choose Search, we handle the text like a typed search, as described below.

What we store when you search

• The search you entered, 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.
• Each step of a search, as it happened. Which question was shown to you, whether you answered it with an offered option, typed your own answer or skipped it, when you pressed Back, whether you chose to search Amazon or see more questions after the third, when the research began, when the results appeared, and whether the tab was hidden or closed while the research was still running, with how long you had waited. It also records when you opened one of the collapsible sections of a result, and which section it was, and when you opened one of our Amazon links, which part of the page the link was in and, for a link in a list, which row of that list it was. Each recorded event is a row with your identifier, the search identifier and the timing. The row says what kind of answer you gave, not what it was. These rows are deleted with the search.
• 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 entered, 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: one for the follow-up questions, filed under your request and the answers you gave to reach that question, and one for the ranked results, filed under the Amazon phrase we derive. Different answers can lead to different cached questions and searches. Neither row carries a visitor identifier, but the words are kept. A search you run with cache=0 in the page address does not use or add to either shared cache: its follow-up questions are kept in the question cache under that search's own identifier instead.
• The raw verdict the model wrote. A separate cache files that verdict under a one-way fingerprint of everything that produced it, 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. The same cache stores the decision a search reached: the Amazon phrase, the products it shortlisted, the verdict when it can be reused and, if we set one of your answers aside to find more results, that answer. We use that decision for up to seven days. It is filed under a one-way fingerprint of your request, your answers and your preferences, including any note you typed, so a matching search can replay the decision while the current candidates and product facts still match.

What we store when you log in

• Your account. Your email address in lowercase, a random account identifier, when the account was created, and the preferences saved with it, with when they were saved. One email address is one account.
• Each code we try to email. The email address, whether the code was for logging in or for saving preferences, the tt_uid of the browser that asked, and its IP address, or for an IPv6 address only its first half, the part that identifies the network. Also the preferences waiting to be saved, how many times the code was tried, when it was used and when it expires. The code itself is not stored, only a scrambled copy. These rows are how we limit how many codes can be sent, and rows more than 7 days old are deleted the next time anyone asks for a code.
• Each login. The account, the tt_uid of the browser, a scrambled copy of the tt_session cookie, when the login started and when it expires, and when it ended if you logged out or logged in again on that browser. These rows are kept as the record of which browsers have used your account.
• Which searches are yours. When a browser logs in, its searches that belong to no account are linked to yours, except searches you start as temporary.

Resend sends the code email and the other emails listed below. It receives your email address and the email, including the code when there is one, and keeps them under its own retention policy.

Giving us your email address, to log in or to save your preferences, means you agree to get emails from us. The 6-digit code we send you already proves the address is yours, so we do not ask you to confirm it a second time.

The emails we may send, and what starts each one:

• The login code. Sent when you ask to log in or to save your preferences. It is the one email with no unsubscribe link.
• Still deciding? Checks once whether you are still deciding, after one of your searches ends in a pick, you have an account and you do not open the Amazon link.
• Related products. Shows products related to one you picked, after you did open its Amazon link.
• Holiday reminders. A few a year, around holidays such as Black Friday and Christmas, to people with an account.
• The monthly guides email. You ask for it with the form at the bottom of a buying guide, where you also pick a category. On the first Tuesday of each month, at noon Eastern, we send one email listing the guides we added or updated in that category over the last 31 days. If there are none, nothing is sent.
• A guide’s shortlist. A box on some guides may offer to email you that guide’s picks. We send them once, and the same request also signs you up for the monthly guides email in that guide’s category. We send at most one shortlist to an address a day.
• News. Once in a while, news about TwelveTabs.

What the guide forms store. Your email address in lowercase, the category you chose, a yes or no for each email list below (yes means you left it), a random key that your unsubscribe link uses, and when the row last changed. A guide form does not create an account, and we do not send a confirmation email, so someone could type your address into one. The unsubscribe link in every email we send undoes it. If you use a guide form again after leaving, the guides email is turned back on, and a choice of “everything” is cleared. Your other choices stay as they were.

You can unsubscribe at any time. Every email except the login code has an unsubscribe link, and mail apps that offer an unsubscribe button get a one-click one. That button leaves everything. The link opens a page where you can leave one list: similar products, still deciding, holiday reminders, news or new guides; or leave everything. Unsubscribing takes effect right away.

Price watch is not currently offered

The price-watch form is hidden. 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. Sending a price-watch request does not create an account. 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 entered, 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.

Comparing two products

The compare page takes two Amazon product links, short links, bare product numbers or product names and, if you choose, a short note on what they are for. The same companies see this data as in a search, described under who else sees your search: a product name is sent to the data providers as the search phrase, the two product numbers are sent to them to fetch the listings, and the note and the two listings go to the companies that run the AI models. If you paste a short link such as a.co or amzn.to, our servers follow up to two redirects to find the product it points to. A comparison counts as one of your free searches for the day. We keep one record of each comparison: the two product numbers and titles, any price Amazon showed with the day it was read, your note, and the comparison we wrote, under your visitor identifier. We do not keep the text you typed into the two boxes. The record is not part of your Searches list and is never joined to your account, even when you are logged in. It has its own web address, which you can send to anyone. It works for 90 days after the comparison ran, shows the prices as they were that day and is never updated, and we ask search engines not to list it. The only thing protecting that 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. Each stored save row contains the tt_uid of the browser that saved it, the identifier of the search and when it was saved. Logged out, it is tied to the cookie on this browser, so another browser or device shows nothing, and clearing your cookies loses the list. Logged in, your saved picks belong to your account: we work out which saves are yours from the record of which browsers your account has used, so a pick saved on one device shows on all of them and removing it removes it everywhere. That record cannot tell two people apart, so if another account was also logged in on the same browser at or after the moment a pick was saved there, that pick stays on that browser instead of following either account. 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 before an ordinary save is refused. Because that limit is checked when you save, signing several browsers into one account or simultaneous saves can put the list over it; every pick stays visible, and new saves are refused until the list is below the limit. Removing a saved pick deletes every matching row in the current browser or account scope. 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.

Rating a pick

A search that ends in a pick shows two thumbs, good and bad, to the browser that ran it. Tapping one submits the rating and stores one row in our database: your tt_uid, the identifier of the search, the rating, and a copy of that search as it was shown to you, so the rating can be read later without rebuilding it: your question, the questions we asked and your answers, the phrase we searched on Amazon, and the rated product with the price, rating and review count we showed. The optional feedback popup adds the reasons you chose and anything you typed to that same row. Tapping the other thumb changes the rating and clears those details. A rating is counted as an event in the analytics described below with the identifier of the search and the rating. The reasons you choose are counted the same way, by their labels. If a rating could not be stored after its silent retries, an event says so, with the identifier of the search. A separate event says when the rating was stored but its optional details were not. The text you type is never sent to PostHog; it stays in our database, where our own daily report reads it. A thumbs-down with reasons or text also emails that same stored row to the person who runs this site, through Resend, so it can be read the moment it arrives; if that email could not be sent, an event records the search identifier and the failure, but no feedback text. If our server refuses a valid rating request for one of your searches, an event records the search identifier and the reason, but no feedback text. The row is deleted with the search.

Until its write succeeds, a pending rating is kept in browser storage for that tab only and is gone when the tab is closed. Its key is twelvetabs:pick-feedback: followed by the search id. The record holds the rating and a version number, plus the reasons or text if you sent them; it holds no visitor identity. We retry each step, the rating and then its details, up to five times, so a rating with details is sent at most ten times. It is deleted after the write succeeds or after the fifth attempt.

Feedback about the app

The Share Feedback button at the foot of the sidebar or phone menu opens a form about the app as a whole. Opening or closing it stores nothing, anywhere. Pressing Send feedback stores one row in our database: your tt_uid, the reasons you chose, anything you typed, the page you were on, and the identifier of the search on screen if there was one. Sending feedback about the app is counted as an event in the analytics described below, with the reasons you chose, whether you typed text, the page and that search identifier, and never the text itself; the text stays in our database, where we read it. Pressing Send also emails that same stored row to the person who runs this site, through Resend, so it can be read the moment it arrives; if that email could not be sent, an event records the search identifier, if there was one, and the failure, but no feedback text. Deleting a search removes only its link from that row. The row is deleted with your visitor record.

Thanking you after a fix

If you are signed in and we later ship a fix for a product rating or app feedback you sent us, we may email the address on your account to say so and quote back what you told us. That email is sent once per fix, per person, and never compares a price to an earlier one; if a thank-you email about a fix could not be sent, an event records the failure, but not what you told us.

When we send an email, Resend tells us that the send was accepted and whether it was delivered, delayed, bounced, marked as spam, opened or clicked, and we record which of those happened for that email. It also tells us whether the send failed outright, and we record that too. Opened is not a reliable signal because some email apps automatically load a hidden image before anyone reads the message, so we never treat an open the way we treat a click.

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. If you log in, the searches linked to your account and the picks you have saved can appear on your other devices too.
• 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. For seven days, a matching request with the same answers and preferences reuses the shortlist while all its products remain in the current candidates, and reuses the pick while the same products are offered to the verdict and the product details it was written from remain the same.

The Searches list and Saved picks are live now. Price watch is not. The Searches list shows your finished searches while their shared links still work, under the lifetime described above, except searches you start as temporary, which it never lists. 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

Apart from the code rows described above, which go after 7 days, 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 groups of data. First, from our database we delete the conversations linked to your account and their messages, reconnect events, search-step records, saved picks, candidate-pool records, product feedback and ratings, and related email delivery records; your account and its logins; the codes sent to your address; and, only where separate ownership is established, whole visitor records with their app feedback and price watches. Second, we delete the cached question and search rows we can locate from those messages. Third, we delete matching people and screen recordings in PostHog only when we can establish they are yours. A login on a shared browser does not show that its whole history or analytics belong to one account. If records are mixed or ownership is uncertain, we keep them until that scope is resolved, and we do not say the request is complete meanwhile. 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:

• Google, Anthropic, OpenAI and TypeSafe run the AI models. The text you entered, and any answers you gave to the follow-up questions, are sent to Google, Anthropic and TypeSafe, and to OpenAI if one of those steps has to be retried. For the first product check, TypeSafe also receives each Amazon listing title and decides whether it fits, is unclear or contradicts what you asked for. To prepare possible next questions, the model that writes them also receives the listed answer paths already 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. If you set what you value, those answers, including anything you typed there, go with the products when the winner is picked. This page names the companies configured today.
• Third-party product data providers run the Amazon search and fetch the full listings for the finalists. Each receives the Amazon search phrase and those Amazon product numbers. The phrase is usually the short one the model writes from your question. A short question can be sent exactly as you entered it so the search can start sooner.
• 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.
• Google Analytics, a Google service, counts visits to the site, through Cloudflare. For each page you open it receives the page’s address and title. For a search, that address can hold the search’s identifier and the title can name the product we picked. Your search text is not sent to it, except when a search button on one of our guides opened the page. See counting visits, below.
• 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, once it is set up, receives errors from our side, the server: the address of the page that failed and the technical stack trace. Never your messages. Until then, Resendemails those errors to the person who runs this site instead: what failed and where, without the stack trace, and 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 in 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 each step of the questions: which question was shown, whether it was answered, typed or skipped, when Back was pressed, the choice made after the third question, when the research started and when the results appeared, and whether the tab was hidden or closed while the research was running, with the time waited. Opening one of the collapsible sections of a result is counted as an event, with the name of the section, and it is counted when you open it and not when you close it. Opening one of our Amazon links is counted as an event too, with which part of the page the link was in and, for a link in a list, which row of that list it was, so we can see whether our top pick was the one you wanted. For searches that have a conversation, the same step events are kept in our own database so we can compare the records and count where searches stop. If your search ended with a pick, you have an account, and you never opened the Amazon link, we record a step event before we try to send its one follow-up email, between 12 hours and 2 days after the search ended. Each scheduled run sends at most one such email to an address. The step record holds the conversation identifier, which is what stops the same search from being emailed to you twice. It also holds the Amazon identifier of the pick, which is what stops the same product found by a different search from being emailed to you twice; that second protection works only where the earlier email was sent on or after 20 September 2026, because records written before that day do not name the product. If your search ended with a pick, you have an account and you did open the Amazon link, we may send one related-products email about that pick between 1 and 7 days after the search ended, and at most one such email to an address in any 7 days. Before we send it we record a step event that holds the conversation identifier and the Amazon identifier of the pick, which is what stops the same search from being emailed to you twice. The email shows up to three related products by title. PostHog 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, spending or free-search limits refuses a search request, PostHog records which limit refused it and which search route was called, but no conversation identifier. When a comparison runs, PostHog records whether it worked, whether the written comparison came from answers we had already stored, a rough cost range, whether each box held a link or a name, whether you added a note, and how many typed names resolved to a product whose title lacked one of your words, but never what you typed and no conversation identifier. When the service that collects Amazon results for a search fails and a backup service takes over, PostHog records which step switched and why, again with no conversation identifier. When an AI model fails during a search and another model takes over, PostHog records which step switched, the two models and the kind of failure, but no error text and no conversation identifier. Opening a search from your Searches 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. Opening the preferences sheet is counted as an event, with where you opened it from, and saving it records which answers changed, never what you typed. When you log in, PostHog records whether it was a login or a save of your preferences, with your account identifier, and adds your email address and account identifier to your PostHog person. When a code email is refused by one of our sending limits, or could not be sent, PostHog records which limit or why, with no email address and no code. 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. When a search button on one of our guides opens TwelveTabs, the page address it opens holds the search the button starts and the name of that guide, and PostHog can record that address with the page view. We take both out of the address as soon as the page has read them, and that first search records which guide sent you. From your second search on, once a search has shown its results, we may ask once how you heard about us, unless you arrived on a link tagged with a campaign source. Answering is optional. If you choose an answer, PostHog records which one, and if you close the question instead, it records that you closed it.

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 entered 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.

We also count visits with Google Analytics, a Google service. No Google script runs on the page. Instead, a second small Cloudflare script reports each page you open to Cloudflare, and Cloudflare’s servers pass the visit on to Google. For each page, Google receives its address and title, the page you came from, your screen size, your browser’s language and user agent string, and how long the page stayed in view. The address of a search’s page can hold that search’s identifier, and its title can name the product we picked. Your search text is not sent, with one exception: when a search button on one of our guides opens TwelveTabs, the address it opens holds the search the button starts and the name of that guide. A random identifier, kept in cookies Cloudflare sets on this site, tells Google Analytics a returning browser from a new one. It is not your tt_uid. Cloudflare does not pass your IP address on to Google. Google Analytics is not linked to any advertising account, and Google signals, which would connect visits to people signed in to Google, is off. Google explains how it uses this information in How Google uses information from sites or apps that use our services.

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