# WooCommerce Telemetry: What's Collected, What's Default, and How to Turn It Off

WooCommerce has a usage tracker that POSTs a weekly snapshot of your store to `tracking.woocommerce.com`. It's off by default. There's a checkbox in Settings → Advanced for anyone who wants to change that, and a one-line filter for anyone who'd rather manage it from code.

There are two exceptions: the setup wizard shown on install has a pre-checked "share my data" box that wraps tracking in vague language like "tailor your setup experience" (though it *does* link to their usage tracking docs). And when connecting your store to WordPress.com from WooPayments or the Woo mobile app, WooCommerce silently flips the option to `yes` and fires off an immediate snapshot.

## What the tracker is

`WC_Tracker` lives in `<a href="https://github.com/woocommerce/woocommerce/blob/e37907fccdc464c4596b6f475ec43decfb8cfb27/plugins/woocommerce/includes/class-wc-tracker.php">includes/class-wc-tracker.php</a>`. WP-Cron fires `woocommerce_tracker_send_event`, the class builds a payload in `get_tracking_data` and pushes it to `https://tracking.woocommerce.com/v1/` at most once a week. The whole thing is gated on one option: `woocommerce_allow_tracking`.

There's a second system hiding next to it called `WC_Tracks` (plus `WC_Site_Tracking`). It fires per-event pixels for admin UI stuff: clicking things in the setup wizard, toggling settings, stepping through onboarding.

## How connecting to WordPress.com enables tracking

Hard-coded default in [`class-wc-settings-advanced.php`](https://github.com/woocommerce/woocommerce/blob/e37907fccdc464c4596b6f475ec43decfb8cfb27/plugins/woocommerce/includes/admin/settings/class-wc-settings-advanced.php):

```
'id'            => 'woocommerce_allow_tracking',
'type'          => 'checkbox',
'default'       => 'no',
'autoload'      => true,

```

The OAuth callback lives in [`includes/admin/helper/class-wc-helper.php`](https://github.com/woocommerce/woocommerce/blob/e37907fccdc464c4596b6f475ec43decfb8cfb27/plugins/woocommerce/includes/admin/helper/class-wc-helper.php), and runs after a successful "Connect to WordPress.com" / WooCommerce.com Helper handshake:

```
// Enable tracking when connected.
if ( class_exists( 'WC_Tracker' ) ) {
    $prev_value = get_option( 'woocommerce_allow_tracking', 'no' );
    update_option( 'woocommerce_allow_tracking', 'yes' );
    WC_Tracker::send_tracking_data( true );
    ...
}

```

The option flips to `yes`. The weekly throttle gets bypassed because of that `true` override, and a full store snapshot goes out immediately.

There is no second confirmation screen, no mention in the connect dialog that tracking is about to be turned on, and if the store owner later disconnects from WooCommerce.com the option stays `yes`.

Plenty of WordPress plugins send telemetry, and many of the people running those sites would rather they didn't. WooCommerce's version is more thorough than most because WooCommerce has more to report. I don't think anyone involved is acting in bad faith, but I do think "connect" isn't the right wording to use when opting someone into telemetry.

## What actually gets sent

`WC_Tracker::get_tracking_data()` builds a JSON object with around a hundred top-level keys. Some of those keys expand into nested arrays: every installed plugin, every payment gateway, a 40-order sample.

Here's the shape, grouped by category, with field names quoted from the source:

| Category | Fields |
|---|---|
| Identity | `url` (home URL), `store_id`, `blog_id` (Jetpack site ID if present), `email` (admin email, filterable via `woocommerce_tracker_admin_email`), `theme` (name, version, child theme, block theme) |
| WordPress | `wp.version`, `wp.debug_mode`, `wp.locale`, `wp.memory_limit`, `wp.multisite`, `wp.env_type`, `wp.dropins` |
| Server | `server.software`, PHP version, MySQL version, timezone, `max_upload_size`, socket support |
| Plugins | `active_plugins[]` and `inactive_plugins[]` — each with name, version, author, plugin URI |
| Connections | `jetpack_version`, `jetpack_connected`, `jetpack_is_staging`, `connect_installed`, `connect_active`, `helper_connected` |
| Features | `enabled_features[]` — every WooCommerce feature flag on the site |
| Users | `users.total` plus counts broken down by role (administrator, shop_manager, customer, subscriber, …) |
| Catalog | Product counts by type (simple, variable, grouped, external, subscription, bundle, …), `categories`, `brands` |
| Orders | Counts per status, first/last order dates, per-status totals |
| Revenue (explicit) | `gross` (sum of completed + refunded), `processing_gross`, and per-gateway `gateway_<method>_<currency>_total` and `_count` |
| Order snapshot | First 20 + last 20 orders with `order_rank`, `date_created`, `currency`, `total_amount`, `payment_method`, `payment_method_title`, `refund_amount`, `woocommerce_version`, `recorded_sales` |
| Gateways | All active gateways with title and supported features |
| WooPayments | `wcpay_settings` — the full settings blob |
| Shipping | All active shipping method IDs + zones |
| Reviews | Counts by status (pending, approved, trash, spam) |
| Storefront | `cart_checkout` block usage and attributes, pickup locations, additional fields, `mini_cart_block`, `template_overrides[]` (every overridden template file path) |
| Emails | `email_improvements`, `store_emails` (which email types are enabled, CC/BCC usage) |
| Other | `address_autocomplete` providers, Migrator CLI stats, `wc_mobile_usage`, `woocommerce_allow_tracking_first_optin`, `woocommerce_allow_tracking_last_modified`, `settings` (a broad slice of `wc_*` options) |

The admin email goes out in every payload. There's a filter (`woocommerce_tracker_admin_email`) that'll let you strip it, but you have to know it exists and you have to apply it. As a default, every snapshot ties a store's revenue numbers to a specific person's inbox. Individual customers aren't in there by name, which is the sort of thing WooCommerce tends to point at when the "is this personal data?" question comes up. But "we send aggregate order counts plus the admin's email address" is a different claim from "we send anonymous usage data," and both claims get made.

The User-Agent is also worth a look: `WooCommerceTracker/<md5(home_url)>;`. That's not anonymous. It's a stable hash of the site URL that ships on every request, which means every payload from the same store is trivially joinable on the receiving end.

## Why any of this matters

The most obvious reason is that revenue is commercially sensitive data, and a weekly revenue export to a third party is the kind of thing a lot of agencies have written contracts specifically to prevent. If you build WooCommerce stores for clients, there's a reasonable chance one of your NDAs would be unhappy about `gross` and `processing_gross` being POSTed to `tracking.woocommerce.com` every week since the store went live. The client almost certainly doesn't know it's happening.

The other thing is the word "aggregate," which WooCommerce leans on when describing what gets sent. Individual customer records aren't in the payload, and that's true. But a stable site-URL hash, plus gross revenue, plus a full list of installed plugins and themes, plus your admin email, is not anonymous data. It's a fingerprint tied to a specific store and a specific person.

## How to turn it off

Pick whichever of these matches how you manage the site. They all do the same thing: keep `woocommerce_allow_tracking` reporting `no` so the payload never gets built.

### In the admin UI

**WooCommerce → Settings → Advanced → WooCommerce.com**, uncheck **Allow usage of WooCommerce to be tracked**, save.

If the box is already unchecked but the site has ever been connected to WordPress.com, check the option directly before you trust the UI.

```
wp option get woocommerce_allow_tracking
```

### With a filter

Into an mu-plugin:

```
add_filter('woocommerce_apply_user_tracking', '__return_false');

```

If you want to be sure the weekly tracker send is also blocked:

```
add_filter('woocommerce_tracker_send_override', '__return_false');

```

### With a constant

In `wp-config.php`:

```
define('WC_ALLOW_TRACKING', false);

```

### Making the option permanently "no"

If you want the option to stay `no` regardless of what code path writes to it, including the connect callback:

```
add_filter('pre_option_woocommerce_allow_tracking', fn() => 'no');

```

This is heavier than the filter approach, and it makes the option permanently read-only from WordPress's point of view. It also makes the "connect to WordPress.com silently enables tracking" behavior a no-op.

### Keeping tracking but dropping the email

If you have a reason to leave tracking on but don't want the admin email going out:

```
add_filter('woocommerce_tracker_admin_email', '__return_empty_string');

```

## What to do on stores you've already connected

1. `wp option get woocommerce_allow_tracking`. If it returns `yes`, the tracker has been sending weekly snapshots since the connect.
2. Uncheck the setting in the admin, or apply one of the filters above.
3. If you want a clean slate, delete `woocommerce_tracker_last_send` (the weekly throttle) and `woocommerce_allow_tracking_first_optin` (the record of when this site first opted in).

```
wp option delete woocommerce_tracker_last_send
wp option delete woocommerce_allow_tracking_first_optin
wp option update woocommerce_allow_tracking no
```

**None of this is hidden.** There's a documentation page at [woocommerce.com/usage-tracking](https://woocommerce.com/usage-tracking/), and the setting has a checkbox. What I don't love is that connecting to WordPress.com quietly flips that checkbox for you, and the connect dialog doesn't say so. If you're building and maintaining WooCommerce sites on behalf of clients, this is something you probably want to know about.