Analytics
Analytics
Smart Add-Ons records every add-on view, selection, and add-on order on your storefront, then summarises the last 30 days in wp-admin. Tracking starts on activation — there is nothing to switch on.
Plan requirement: analytics is included on every plan (analytics_basic). It does not need a Pro licence. Storefront add-ons themselves are licensed, so no groups render — and no events are recorded — while a licence is missing or expired beyond its grace period. See Licensing.
How tracking works
Two sources feed one table. The add-on form on the product page posts events to the plugin REST API as customers interact with it, and WooCommerce orders that contain add-ons are recorded server-side. Both end up in wp_saue_analytics_events.
Storefront events are sent as they happen — each change to a field is its own request, with no batching or delay.
Events that get recorded
| Event | Recorded when |
|---|---|
addon_view | The add-on form loads on a product page — one event per add-on group shown to that visitor. |
addon_select | A customer gives a field a value: ticks a checkbox, picks an option, types into a text field. |
addon_deselect | A customer clears a field: unticks it, empties it, or deselects every option. |
order_complete | An order containing add-on selections or add-on revenue is recorded server-side. One event per order. |
What an event stores
| Column | Contents |
|---|---|
event_type | One of the four events above. |
product_id | The product being viewed. Required — events without a valid product are rejected. |
group_id | The add-on group the event belongs to. |
field_id | The field that was selected or cleared. |
option_value | The chosen value, comma-joined for multi-value fields, stored up to 255 characters. |
session_id | The storefront session identifier, up to 64 characters, so a visit can be followed across events. |
user_id | The logged-in WordPress user, when there is one. |
order_id, revenue | Set on order events: the order and the add-on revenue attributed to it. |
created_at | Timestamp used for every period filter. |
The analytics dashboard
Go to Smart Add-Ons → Analytics (any user who can manage WooCommerce). It reports the last 30 days and shows:
- Views — add-on groups rendered on product pages.
- Selections — field selections, counting only fields that still exist.
- Conversions — distinct orders that contained add-ons.
- Add-on revenue — the add-on portion of those orders, in your store currency.
- Top performing fields — the five fields with the most selections in the period.
Opening the dashboard also sweeps recent orders and records any add-on orders it has not seen yet, so figures fill in without a cron job. The dashboard itself is fixed to 30 days; the REST endpoint below accepts any window from 1 to 365 days.
How add-on revenue is attributed
For each order item, the recorder takes the first figure it can trust:
- The hidden
_saue_addon_revenueorder item meta written at checkout. - Failing that, the visible Add-ons subtotal order item meta, parsed back into a number.
- Failing that, the stored
_saue_addonsselections, re-costed against the item base price and quantity.
An order is only ever recorded once. If it is picked up again later — after a refund or an edit changes the add-on total — the existing event has its revenue updated rather than a second event being added. The sweep looks at orders in the period with a completed, processing, on-hold, or pending status.
Deleted fields
Deleting an add-on field also deletes its selection events, so totals do not count options customers can no longer choose. A one-off cleanup does the same for fields that were deleted before this behaviour existed. Anything still pointing at a missing field is listed as Field #12 (removed).
Sending events yourself
The event endpoint is public, so the storefront can post to it without a logged-in user. It accepts only the three storefront events — order_complete is written by the plugin and cannot be posted. Requests are capped at 20 events and roughly 16 KB, and every event needs a valid product_id.
POST /wp-json/saue/v1/analytics/events
Content-Type: application/json
{
"events": [
{
"event_type": "addon_select",
"product_id": 123,
"group_id": 7,
"field_id": 12,
"option_value": "Wood",
"session_id": "t_1a2b3c4d"
}
]
}Reading the summary
The summary endpoint needs a user who can manage WooCommerce. days is optional and defaults to 30.
GET /wp-json/saue/v1/analytics/summary?days=30
{
"period_days": 30,
"views": 1840,
"selections": 412,
"conversions": 96,
"revenue": "1284.50",
"currency": "$",
"top_fields": [
{ "field_id": 12, "label": "Gift wrapping", "removed": false, "selections": 118 }
]
}Events and Dhyan Cloud
When the site is connected to Dhyan Cloud, recorded events are also forwarded there under a namespaced name such as addonflow.addon_select, carrying the same product, group, field, value, revenue, and session identifiers. The wp-admin dashboard reads your own database either way.