TagLens — Privacy Policy

Last updated: 4 November 2026

TagLens is a developer diagnostic tool. It records the analytics activity of a web page you are visiting so you can see what your tracking did and did not send. This policy describes exactly what it handles and where that data goes.

The short version

What runs on every page

TagLens is a diagnostic tool, so a small amount of it has to be in place before you decide to record — otherwise pressing record would always miss the beginning of the page, which is the part being diagnosed. On every page you open, in every frame, whether or not you are recording, TagLens:

• Watches dataLayer in the page so that a push made in the first milliseconds of a page load is not lost.
• Sets one attribute, data-tag-assistant-prod-present, on the page's root element. This switches on a reporting channel that Google's own tag already carries and that Google's Tag Assistant uses. It makes the tag write down, in the page, each event it sends, which is what lets TagLens tell apart events that leave together in a single batched request. The attribute has to be in place before Google's tag starts, and Google's tag reads it exactly once, so it cannot be switched on only when you press record.
  • It does not change what the site sends. This was measured across 138 runs against Google's own tag: the requests, their parameters, their values, the cookies and the headers are identical with the attribute and without it.
  • What it does do is leave a record of that page's recent Google hits inside the page itself, where other scripts on that same site could read it. If you would rather that did not happen on a particular site, do not open that site with TagLens installed.
• Asks the extension whether this tab is being recorded. Chrome attaches the page's address to that question as sender information. TagLens does not read it, but the browser makes it available, so the extension is capable of knowing the address of pages you open. The page's origin — the site name, not the full address — is also held in session memory for the tab, and is gone when the browser closes. Separately, whenever you open TagLens on a tab it writes that tab's site name to its own settings storage, which is on disk, so that a screen opened in a new tab can find its way back to the live timeline. It is overwritten the next time you open TagLens and it never leaves your machine.

One thing happens outside the page, and it is worth stating plainly. Chrome hands an extension that is allowed to read requests a copy of every analytics request any tab sends, headers included, before that extension gets to decide whether it wants it. TagLens looks at each one to see whether it is a tracking request at all, and on a tab you are not recording it is dropped without being stored, shown or counted. There is no way to ask Chrome for one tab's requests only; the choosing has to happen after they arrive.

Apart from that, nothing about the page or about you leaves a tab you have not recorded. Two things are worth stating precisely, because "not recording" is not quite the same as "never recorded":

• Recording is armed per page. A page you were recording keeps sending until you leave it, even after you press stop — the extension throws that away, and nothing from it is saved. It works this way because TagLens numbers the records it reads out of Google's tag, one run of numbers per page, and a gap in that numbering makes it distrust the whole page's evidence. A page that could stop reporting half way through would punch that gap itself.
• A new page opened after you stop sends nothing at all.

What TagLens records

While you are recording, and only on the tab you are recording, TagLens captures:

• dataLayer pushes made by the page, including their contents. When recording starts, up to the last 300 entries already sitting in the page's dataLayer are read as well, marked as having happened before recording began, because they are the part of the page load you pressed record to see.
• Analytics requests the page sends — the URL, the decoded payload (event name and parameters), and a summary of the request headers. The summary counts sizes and lists the names of the largest cookies sent with the request. It never keeps a cookie's value.
• How each of those requests ended, as Chrome reports it to the extension: the server's status code, or the network error when it never got through (blocked by the browser or an ad blocker, refused by the server, or failed to connect). When the site's own security policy (CSP) blocks a request or one of Google's tag scripts, TagLens records the address that was blocked and the policy rule that blocked it. It also notes Chrome's internal ID for each page, so a block on one page is not counted against another.
• The page's address, so that captured events can be attributed to the page that produced them. TagLens does not read the page's title; a title appears in a recording only if the site's own analytics put it in a request.
• Clicks and form submissions, so that a control that fired nothing can be told apart from one nobody pressed. What is kept is what Google Tag Manager's own click variables would see: the visible text of the control up to 60 characters, its tag, its id, its classes, its link address, and a selector for it. Typing is never recorded, and neither is the content of a form.
• Whether the site's consent banner says you have decided, and whether it reports consent for storing information on your device. This comes from the site's own consent API and explains a recording that is empty because nothing was allowed to fire. It is three true-or-false values, kept with the recording; no identifier from the banner is stored.
• Your own settings and saved comparisons, including your answer to being counted.

Because analytics payloads are the subject of the tool, a recording will contain whatever the site under test chose to put into them. On some sites that can include identifiers such as a user or account ID. TagLens surfaces this to you — that is frequently the defect being looked for — but it does not extract, separate, or transmit it.

Where it is stored

Recordings are kept in a database called taglens in your browser's own IndexedDB storage. Your settings, saved journeys and comparisons are kept in chrome.storage.local, and the recording in progress is mirrored into chrome.storage.session so that Chrome shutting the extension down mid-session cannot lose it. All three are areas of your own browser profile on your own device. The unlimitedStorage permission is requested so that a long recording is not silently truncated.

A recorded session is a draft until you press save this session. A draft is written to disk as it goes — so that closing your browser or Chrome suspending the extension cannot lose it mid-session — but it is not kept. It is discarded when you close the last TagLens view, once the recording it came from has finished. A draft whose tab you still have open is not thrown away underneath you; it waits, and goes the next time you close TagLens after that tab is gone.

A session you save with that button is kept until you delete it or remove the extension. Recordings made before saving existed are kept for 30 days. Recordings a saved journey was cut from, and journeys used as a comparison baseline, are kept for as long as the thing that refers to them. A recording made by replaying a journey is shown as saved, because you asked for the run; it is kept while the journey still refers to it, and otherwise ages out with the rest. Once there are more than a hundred recordings the oldest go first, counting only the ones you did not save yourself — what you saved is not deleted to make room.

Uninstalling the extension removes them with it. TagLens has no ability to recover a recording once deleted, because it never held a copy.

Network activity

TagLens makes exactly three kinds of outbound network request in its entire codebase. The second happens only if you connect a key to the AI analysis feature, and the third only if you answered yes to being counted (see Being counted below).

While you are recording, when it detects that the page has loaded a Google Tag Manager container, it performs a single GET for that container's public definition in order to determine which tags should have fired. Where TagLens saw the page request the container, it fetches that same URL — the identical URL the page itself has already requested, on whichever host the page loaded it from: usually googletagmanager.com or the site's own server-side Tag Manager domain. Where the page holds a container TagLens never saw requested (a container loaded through a first-party loader path), it fetches the container's public definition from the URL the page's own script tag names, or failing that from googletagmanager.com by the container's public id. No data is sent with that request and no cookies or credentials are attached to it. On a tab you are not recording, this request is not made at all.

The second is the AI analysis feature. With a key you have connected, TagLens sends your question and the fact sheet described above to the endpoint you chose — Google AI Studio, or another OpenAI-compatible endpoint you name — and shows you the answer. That request carries your key and nothing about you or your browser beyond the fact sheet. What the provider does with what it receives is governed by that provider's terms; on Google's free tier, for example, Google states that content may be used to improve its products, and TagLens says so on the screen where you connect. No question is sent until you ask one. When a question needs a row the fact sheet does not carry, the model may ask TagLens for rows by event name and time window; TagLens answers with at most twenty rows per request, a few requests per question, each row scrubbed by the same rules as the fact sheet, and the answer's footer names every lookup it made.

The ask ChatGPT button on the header (the same press as for ChatGPT in the export menu) saves the raw export on your device — every recorded event with its full payload, values as recorded, the same file as the json export — and opens chatgpt.com with TagLens's reading instructions typed into the message box; you attach the file there yourself. It exists so you can ask about your own recording without connecting a key. TagLens sends nothing; the file leaves your device only when you upload it, under that service's terms.

There is no other fetch, no XMLHttpRequest, no sendBeacon and no WebSocket anywhere in the extension.

Being counted

The Chrome Web Store can say how many people installed TagLens; it cannot say how many open it. So TagLens asks you, once, on its live screen: Count you as a TagLens user? Nothing is sent until you answer count me. No sends nothing, and so does never answering. You can change your answer at any time under view ▾ › settings › count me as a user.

If you said yes, then the first time each day you do one of six things — open TagLens, start a recording, see what a container expects, replay a flow, ask the AI, or export — TagLens sends one small request to Google Analytics, to a property that belongs to TagLens. It carries:

• the name of that feature (tl_open, tl_record, tl_container, tl_replay, tl_ask, tl_export);
• the TagLens version, and whether this copy came from the Web Store;
• the week you said yes;
• a random id made on your computer when you said yes. It is tied to nothing — not your Google account, not your machine, not the sites you visit — and it exists only so that the same person is not counted as a new one each day. Removing the extension removes it.

It never carries the site, its address, an event, a parameter, a value, a payload, a recording, or anything typed. The same feature is sent at most once a day, so the numbers mean people who did this today, not how often. Google receives the request from your connection, as it does any request to Google; TagLens reads only the counts, uses them for nothing but knowing how many people use TagLens and which parts, and does not sell or share them. If a later version ever changes what is sent, it asks the question again before sending anything new.

What TagLens never does

• It never sends your recordings, browsing history, or any captured payload off your device. The AI analysis feature sends a fact sheet of names, counts and values, and rows the model asks for under the same rules — never a whole recording, never a raw payload, never an identifier — and only to an endpoint you chose, with a key you supplied, when you ask a question. Being counted, if you said yes, sends a feature name, a version, a week and a random id — never a site, an address or a recording.
• Limited Use. TagLens's use of information received from Google APIs, and of any data it handles, adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements. It transfers that data nowhere, uses it for no purpose other than showing you the diagnosis you asked for, sells it to nobody, and no human at TagLens ever reads it, because it never reaches TagLens: it stays on your machine, and the only things that ever leave are the fact sheet the AI analysis feature sends to the AI endpoint you chose and, if you said yes, the count described under Being counted.
• It never sells or shares data. The only data it ever receives is the count under Being counted — anonymous, from people who said yes, used for nothing but knowing how many people use TagLens and which parts.
• It never blocks, redirects, or modifies the requests it observes — it only reads them.
• It contains no eval, no new Function, and no remotely-loaded code. All code that runs is the code reviewed and shipped in the package.

The debugger permission

The debugger permission is granted when you install TagLens, and Chrome shows it to you at that moment. It cannot be made optional: Chrome refuses to accept debugger in an extension's optional_permissions and silently drops it, which is why an earlier version of TagLens that tried to ask for it only on demand had a replay button that could never work.

It is used for one thing: re-driving a recorded journey when you press replay. TagLens opens a new window of its own for the replay and attaches the debugger only to the tab inside it, for the length of that run, detaching when the run ends or is stopped. It is never attached to a tab you are browsing in, and never while you are recording by hand or reading a recording back. A replay is itself recorded, in the separate window, so for the length of a replay TagLens is both recording and attached — to the window it opened, never to yours.

While the debugger is attached, Chrome displays its own banner across the top of the tab saying TagLens is debugging it. If you would rather not grant it, the only way to decline is not to install the extension — but nothing is sent anywhere either way; see “What TagLens never does” above.

Contact

Questions about this policy: hnkhan123.hk@gmail.com