Platform guide
Smart Add-Ons analytics personal data: what does it actually store?
No name, email, or IP address — but the analytics_events table does record a logged-in shopper's WordPress user ID (null for guests) and, for every field a shopper interacts with, the actual value they entered, truncated to 255 characters. That includes free-text fields: a gift message or personalization field's real text is what gets recorded, not just "this field was used." No WordPress privacy exporter or eraser is registered for this table, so a built-in Tools → Export/Erase Personal Data request won't include it automatically, and nothing currently trims old rows — events accumulate indefinitely unless removed manually.
Smart Add-Ons analytics personal data is worth knowing precisely, not assuming about — this is what the analytics_events table’s schema and the code that writes to it actually capture, read straight from the migration and the tracking pipeline on both ends.
Smart Add-Ons analytics personal data: the schema itself
The migration that creates the table lists every column:
CREATE TABLE {$analytics_events} (
event_type varchar(30) NOT NULL,
product_id bigint(20) NOT NULL,
group_id bigint(20) NULL,
field_id bigint(20) NULL,
option_value varchar(255) NULL,
order_id bigint(20) NULL,
revenue decimal(19,4) NULL,
session_id varchar(64) NULL,
user_id bigint(20) NULL,
created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
...
);No email address, no name field, no IP address column anywhere. user_id is the one column that’s directly identifying — it’s set with get_current_user_id() ?: null, so a logged-in shopper’s real WordPress user ID is recorded on their events, and it’s null for a guest. session_id is a per-visit token, not tied to an account, but it is a pseudonymous identifier that could link a guest’s events together across a session.
option_value can be real free text, not just a category label
This is the detail easy to assume away. A dropdown selection’s option_value is a category label like "red" — but a text-type field’s option_value is whatever the shopper actually typed, converted to a string and recorded as-is:
option_value: Array.isArray( value ) ? value.join( ',' ) : String( value )A personalization field where a shopper writes “Happy birthday Grandma” has that literal text land in the analytics table, truncated to 255 characters (matched on both the client and server so nothing gets silently rejected), with the truncation done by Unicode code point specifically so an emoji or other multi-byte character never gets split mid-character. It’s a well-built truncation — the point worth taking away is simply that free-text field content is tracked, not summarized.
No built-in export or erase hook, and no automatic cleanup
WordPress core’s own privacy tools — Tools → Export Personal Data, Tools → Erase Personal Data — only reach data a plugin explicitly registers with wp_privacy_personal_data_exporters or wp_privacy_personal_data_erasers. Smart Add-Ons doesn’t register either hook, confirmed by grep across the whole plugin. A store owner running a customer’s data request through WordPress’s built-in tools today won’t have this plugin’s analytics rows included or removed automatically — that’s a manual step if a specific customer’s user_id needs to be found and handled.
Separately, nothing in the codebase deletes old analytics rows on any schedule — no cron job, no retention window. Events accumulate for as long as the plugin is active, growing the table indefinitely unless a site owner prunes it themselves. That absence of a retention policy is as much a part of Smart Add-Ons analytics personal data as the columns the table actually has.
Common questions
Is Smart Add-Ons GDPR compliant?
That’s a legal determination for a store’s own compliance review, not something this article can answer — what it can do is describe exactly what’s stored and how, which is the input a real compliance review actually needs. The facts above are the complete picture of Smart Add-Ons analytics personal data as the table currently holds it.
Does disabling analytics on the Starter plan remove this concern?
Analytics event recording (analytics_basic) runs on every plan — it’s the dashboard visualization that’s Pro-gated, not the underlying event capture. Turning off tracking entirely isn’t a plan-tier toggle in the plugin’s own settings today.
Can a store owner manually delete one customer's analytics rows?
Yes, at the database level — every row carries either a user_id for a logged-in shopper or an order_id tying it back to a specific order, so a targeted DELETE against the analytics_events table by either column is possible. There’s no admin-UI button for this today; it’s a direct database operation, which is exactly the gap the missing privacy-eraser hook leaves open.
For how add-on revenue attribution works from the order side, see the add-on analytics guide, and WordPress’s own privacy-related hooks documentation (opens in new tab) for how the export/erase hooks referenced above actually work.
Comments