Tagsmith privacy policy

This policy explains what data Tagsmith handles, where it goes and how to remove it. It covers:

• the Tagsmith WordPress plugin (WordPress.org slug tagsmith), and
• the Tagsmith sign-in relay at https://connect.shivaatripathi.com.

Tagsmith is made by Shivaa Tripathi, referred to below as "I" or "me". Contact: [email protected].

The short version

• Your analytics data goes from Google straight to your own WordPress site. It never passes through my servers.
• My relay only takes part when you connect your Google account and when your site refreshes its access token. It passes sign-in codes and tokens along, and it does not store or log them.
• The plugin sends me no telemetry and adds nothing of mine to your visitors' browsers.
• If you turn on Microsoft Clarity, your visitors' browsers send data to Microsoft, and your site asks Microsoft's Data Export API for numbers. None of that passes through my servers either.
• If you turn on an ad pixel, your visitors' browsers send data to that ad platform. None of that passes through my servers either.
• You can disconnect, revoke access and delete everything at any time.

1. The WordPress plugin

The plugin runs on your WordPress site, which you (the site owner) control. Everything it keeps is stored in your own WordPress database:

• Settings, such as your GA4 Measurement ID, property, Search Console site, consent settings and which roles may see reports.
• Your Google connection: the Google account email address that connected, the granted scopes, and the OAuth refresh and access tokens, encrypted with keys derived from your site's own WordPress salts. If you use your own Google client, its client secret is stored encrypted too. Its client ID is stored as-is, because it is not a secret (Google shows it in every sign-in link).
• Cached reports (temporary copies of the numbers Google returned), kept for minutes to days so pages load fast.
• If you use Microsoft Clarity: your Clarity Project ID, and your Clarity Data Export token, which is stored encrypted and is never shown again. Also daily snapshots of the aggregated behavior numbers that Clarity returns (see below), kept for 120 days.
• A few per-user preferences for the plugin's own screens.

I have no access to your WordPress database, and the plugin sends me no usage data, error reports or other telemetry.

Calls the plugin makes. When you view reports, your site calls Google's APIs directly (the Google Analytics Data API, the Google Analytics Admin API, the Search Console API, and Google's OAuth token and revoke endpoints). Those requests carry your access token and describe the report you asked for. Google's responses come back to your site only. In the default sign-in mode, token refreshes go through my relay (see below). In tracking-only mode, or with your own Google client, the plugin never contacts me at all.

Whenever the plugin's health checks run while your site is connected to Google (Settings, Health, and the last step of setup), your site also sends one HEAD request to analyticsdata.googleapis.com and notes only whether any answer comes back. It is not sent in tracking-only mode. The request carries no token, report request or analytics data. Google sees your server's IP address and WordPress's standard User-Agent, which names your WordPress version and site address.

Your website's visitors. When tracking is on, the plugin adds Google's gtag.js to your pages, and your visitors' browsers send page views and events to Google Analytics under your GA4 property. For that data, you are the controller and Google is your processor, under your agreement with Google. I receive none of it. The plugin supports Google Consent Mode v2 and the WP Consent API so you can respect your visitors' choices. In Advanced mode (the default) the tag loads for every visitor. Visitors whose default is "not agreed" (by default those in the EEA, the UK and Switzerland) send only cookieless pings, and nothing is stored on their device, until they agree. In Basic mode nothing is sent to Google before a visitor agrees. Excluded roles and non-production sites load nothing. Tell your visitors about Google Analytics in your own privacy policy.

Microsoft Clarity's tag (your visitors to Microsoft). This happens only if you turn on Microsoft Clarity. Your visitors' browsers load Clarity's script from www.clarity.ms and send Microsoft how they use your pages: the pages they view, clicks, scrolling and mouse movements, which Clarity turns into heatmaps and session recordings, together with device, browser and approximate location data. The same consent decision, excluded roles and staging rules as for Google's tag apply, so your excluded roles and non-production sites load nothing. With WordPress context tags on (the default), recordings are also tagged with the page type, post type, first category slug and an author number (the author's user ID) of the page, and whether the visitor is logged in. These tags contain no names, email addresses or other personal data. I receive none of this data. What Microsoft does with it is set out in Microsoft Clarity's Terms of Use and the Microsoft Privacy Statement. Tell your visitors about Clarity in your own privacy policy.

The Microsoft Clarity Data Export API (your site to Microsoft). This happens only if you save a Clarity Data Export token. About once a day, your site asks www.clarity.ms for your Clarity project's behavior metrics for the last one to three days (two API calls). "Sync now" can ask again at most once an hour, and the plugin never makes more than 8 calls a day. Your site sends the token, and Clarity sends back aggregated numbers for the whole site and per page: sessions, bot sessions, scroll depth, engagement time, and how many sessions had rage clicks, dead clicks, quick-backs, excessive scrolling, script errors or error clicks. The plugin keeps these daily snapshots, for your own site's pages only, in your WordPress database for 120 days. These calls go from your site to Microsoft. My relay is not involved and I receive none of it. Removing the token stops the calls. The same Terms of Use and Privacy Statement apply.

Ad pixels (your visitors to the ad platforms). This happens only for a platform you switch on in Ads & pixels and give an ID. Your visitors' browsers then load that platform's own script and send it page views and the events you chose: viewing a post or page (the page title and its first category, to the platforms that take them: Meta, TikTok, Snap and Microsoft Advertising), searches (the search term, to Meta, TikTok, Pinterest, Snap and Microsoft Advertising), form leads and taps on phone, email, text-message or WhatsApp links (the kind of link only: never what a visitor types, never the number or address). LinkedIn, X and Google Ads receive only leads and contacts, as conversions you set up with the ID or label you enter. Every event carries a random event ID. A search term that looks like an email address or a phone number is dropped, and a search page that carries one loads no pixel at all, because the page address would carry it. Each platform's script also reads what any web script reads (the page address with its query string, the referrer, the visitor's IP address and browser details) and sets its own cookies. Nothing is sent before the visitor agrees to marketing cookies where your consent setting asks for it (Advanced mode: visitors whose default is "not agreed"; Basic mode: everyone). Google Ads waits for that too and, in Basic mode, for the Google tag's own grant as well. Excluded roles and non-production sites load nothing. The Google tag also records generate_lead (the form plugin and form ID) and contact (the kind of link) while an ad pixel is on. Tagsmith adds no names, emails or form entries. I receive none of this data. Tell your visitors about the ad platforms you use in your own privacy policy. The platforms, with their hosts, terms and privacy policies:

• Meta Pixel. Page views, content views (title, category), searches (term), form leads, contact taps. Hosts: connect.facebook.net, www.facebook.com, www.instagram.com. Terms and privacy policy.
• Google Ads. Page views and, as conversions you create, form leads and contact taps. It shares the Google tag's gtag.js. Hosts: www.googleadservices.com, googleads.g.doubleclick.net, www.google.com. Terms and privacy policy.
• TikTok Pixel. Page views, content views (title, category), searches (term), form leads, contact taps. Hosts: analytics.tiktok.com, analytics-ipv6.tiktokw.us, analytics.pangle-ads.com. Terms and privacy policy.
• LinkedIn Insight Tag. Page views, and form leads and contact taps as conversions you create. Hosts: snap.licdn.com, px.ads.linkedin.com. Terms and privacy policy.
• Microsoft Advertising UET tag. Page views, content views (title, category), searches (term), form leads, contact taps (the kind of link). Hosts: bat.bing.com, bat.bing.net. Terms and privacy policy.
• Pinterest Tag. Page views, content views (the visit only), searches (term), form leads, contact taps. Hosts: s.pinimg.com, ct.pinterest.com. Terms and privacy policy.
• Snap Pixel. Page views, content views (title, category), searches (term), form leads; no contact event. Hosts: sc-static.net, tr.snapchat.com, tr6.snapchat.com, tr-shadow.snapchat.com. Terms and privacy policy.
• X Pixel. Page views, and form leads and contact taps as conversions you create. Hosts: static.ads-twitter.com, analytics.twitter.com, t.co, ads-twitter.com, ads-api.twitter.com. Terms and privacy policy.

Product names belong to their owners, with no affiliation.

2. The sign-in relay

Google does not allow a plugin to ship the client secret that one-click "Connect with Google" needs, so a small relay service that I run holds it. The relay is used in exactly two situations.

When you connect. Your browser visits the relay, which shows a confirmation page naming your site, then sends you to Google. After you approve, Google sends your browser back to the relay with a one-time authorization code. The relay exchanges that code with Google for tokens and immediately passes them to your WordPress site in your browser (a form that posts directly to your own site's address). During this, the relay processes:

• your site's address (where to send you back),
• a random, single-use state value created by your site,
• the authorization code from Google,
• the tokens Google issues: an access token, a refresh token and an ID token. The relay reads your Google account email address from the ID token so your site can show which account is connected, and does not forward the ID token itself.

When your site refreshes its access token (roughly once an hour while reports are being viewed, and about once a week when WordPress's Site Health runs its background checks, which include the Tagsmith connection check), your site sends its refresh token to the relay, which adds the client secret, asks Google for a new access token and returns it to your site.

What the relay does not do:

• It has no database and does not store codes, tokens, email addresses or site addresses. They exist only in memory for the length of the request.
• It does not log tokens, codes, email addresses, request bodies or query strings. Its logs contain only the route, the response status, the time and how long the request took.
• It never calls Google's Analytics or Search Console APIs, and never sees your analytics data.
• It sets no cookies and uses no analytics or tracking.

IP addresses. The relay uses your IP address, in memory only, to limit how many requests one address can make per minute (to prevent abuse). Rate-limit entries expire within minutes and are never written to disk.

Where the relay runs. On a server in Germany (Hetzner), behind Cloudflare, which protects the service and passes traffic to it. Cloudflare processes network data such as IP addresses to do this, under its own privacy policy.

Legal basis (GDPR). I process this data because you asked me to connect your Google account (performance of the service you requested), and for rate limiting, in my legitimate interest in keeping the service secure and available.

3. Google user data

This section covers the data Tagsmith receives from Google when you click "Connect with Google" and allow access. It explains what is accessed, how it is used, who it is shared with, how it is protected, and how long it is kept.

3.1 What Google user data Tagsmith accesses

Tagsmith asks Google for these permissions, all of them read-only:

Google also issues Tagsmith an OAuth access token and refresh token, which let your WordPress site make these read-only requests. Tagsmith does not access any other Google data. It never changes your Analytics or Search Console data or settings. Google Analytics reports are aggregated, so they do not identify the individual visitors to your website.

3.2 How Tagsmith uses Google user data

Tagsmith uses Google user data only to provide its features to you, inside your own WordPress admin:

• The account email is shown in your Tagsmith settings, so you can see which account is connected.
• The lists of accounts, properties, data streams and Search Console sites let you choose which ones Tagsmith reports on. The chosen stream's Measurement ID is used to set up the Google tag.
• The report numbers are shown on the Tagsmith dashboard, the WordPress dashboard widget and the posts list, only to the WordPress users you allow to see reports (administrators, plus any roles you add).
• The tokens are used only to make the read-only requests above.

I do not use Google user data for advertising, for selling, for credit decisions, or to build user profiles. I do not use it to develop, improve or train generalized artificial intelligence or machine learning models. No person reads your Google user data, unless you explicitly ask me to look at something while helping you, it is needed for security purposes, or the law requires it.

3.3 Who Google user data is shared with

I do not sell, share, transfer or disclose Google user data to anyone. Your report data goes from Google straight to your own WordPress site and never passes through my servers.

The only Google user data that reaches a server I run is the sign-in data handled by the sign-in relay: the authorization code, the tokens and your account email, while you connect and when your site refreshes its access token. The relay passes them to your site and keeps nothing. On the way, this encrypted traffic is carried by two service providers: Hetzner, which hosts the relay's server in Germany, and Cloudflare, which protects it and passes traffic to it. They only carry and protect the traffic, and do not receive the data for any other purpose.

I would disclose data only if the law required it. Because the relay keeps nothing, there is no stored Google user data that I could disclose.

3.4 How Google user data is protected

• Encrypted in transit. Every request between your site, the relay and Google uses HTTPS (TLS). The relay refuses to send you back to a site address that does not use HTTPS, except a local test site on your own computer.
• Encrypted at rest. Your site stores the access and refresh tokens encrypted with libsodium authenticated encryption (XSalsa20-Poly1305). The key is derived from your site's own WordPress secret keys, so a copy of the database alone does not reveal the tokens.
• Nothing stored on my servers. The relay has no database, keeps tokens in memory only for the length of one request, and never writes tokens, codes or email addresses to its logs. It holds the Google client secret so that it is never shipped inside the plugin.
• Access control. Only logged-in WordPress users with permission to see reports can request them, and every request is checked by WordPress. Only administrators can connect, change or disconnect the Google account.
• Protected sign-in. Each sign-in uses a random, single-use state value, so a sign-in cannot be replayed or forged. The relay limits how many requests one address can make.
• Least access. Tagsmith asks only for read-only permissions.

3.5 How long Google user data is kept, and how to delete it

• On my servers: nothing is kept. The relay forgets each request's data as soon as the request ends.
• Tokens and account email, in your WordPress database: kept until you disconnect, revoke Tagsmith's access in your Google account, or delete the plugin.
• Cached reports, in your WordPress database: kept for at most 6 hours as the current copy, and at most 7 days as a backup copy shown if Google cannot be reached. They then expire by themselves.

To delete it all: disconnect in Tagsmith's settings, which revokes access at Google and deletes the stored tokens, or delete the plugin, which by default removes all its data. You can also revoke access at any time at myaccount.google.com/permissions. Step-by-step instructions are in section 4. To ask about your data, email [email protected].

Limited Use. Tagsmith's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

4. How to disconnect, revoke and delete

Disconnect from Google. In WordPress, go to Tagsmith, Settings, Connection, and click Disconnect. The plugin asks Google to revoke its access and deletes the stored tokens.

Revoke access from your Google account (works even if your site is gone): open https://myaccount.google.com/permissions, choose Tagsmith, and remove its access. Your site will show "Reconnect required" until you connect again.

Delete everything the plugin stored. In WordPress, go to Plugins, deactivate Tagsmith, then click Delete. By default this removes its settings, the encrypted connection, saved reports, the Clarity token and snapshots, and user preferences from your WordPress database, and asks Google to revoke its access. If your site cannot reach Google at that moment, remove the access yourself with the link above. On a site with an external object cache, cached report copies are not in the database; they expire by themselves within a week. (If you turned off "Delete all Tagsmith data when the plugin is deleted" under Settings, Sign-in & data, turn it back on first.)

Data held by me. The relay keeps nothing to delete. If you still want to ask about your data or exercise your rights (access, correction, deletion, objection or complaint), email [email protected]. You can also complain to your local data protection authority.

Data in Google Analytics (your visitors' data, and your reports) belongs to your Google account and is governed by Google's Privacy Policy. Manage or delete it in Google Analytics itself.

Data in Microsoft Clarity (recordings, heatmaps and the numbers behind them) belongs to your Clarity project and is governed by the Microsoft Privacy Statement. Manage or delete it in Clarity itself. In WordPress, removing the Data Export token stops the plugin's calls to Clarity, and deleting the plugin removes the stored token and snapshots.

5. Children

Tagsmith is a tool for website owners and is not directed at children.

6. Changes to this policy

If I change how Tagsmith handles data, I will update this page and the "Last updated" date, and describe significant changes in the plugin's changelog.

7. Contact

Shivaa Tripathi
Email: [email protected]
Plugin support: the Tagsmith support forum on WordPress.org, or email [email protected].