REST Campaign Summary object

For information about how REST API works, see rest main page.

Read-only daily performance figures per action, per campaign. This is the object to use when you want Personyze campaign results inside your own BI tool, data warehouse or reporting dashboard.

The endpoint URL is:

app.personyze.com/rest/summary_actions

GET only. One row per (day, action) pair.

This object returns per-action rows only. The underlying summary also holds rows aggregated per A/B group and per campaign, and those are deliberately not exposed here. The practical consequence: if you are running an A/B test, you can read each variant's own numbers — provided each variant is its own action — but you cannot reconstruct lift against the control group, because the control arm shows no action and therefore has no rows. The A/B verdict is computed by Personyze and read in the panel.

Identity columns

Delivery columns

Counted both as raw occurrences (n_*) and as distinct sessions (n_sessions_*):

Which sessions a row covers

A row covers every session that started on day in which the visitor matched the campaign and was served this action — whether or not the action then ran. A popup with an exit-intent, scroll or delay trigger is served to the page when the visitor matches, and runs only if the trigger fires; a visitor who never tries to leave is in the row but not in n_sessions_executed.

Goal and recommendation columns

products_goal_n_times, products_goal_n_sessions, products_goal_value — purchases made in the sessions the row covers: units bought (the sum of quantities), sessions with at least one purchase, and those units at the product's price in your catalog. The value is not the order total: discounts and coupons are not seen, and a product missing from the catalog adds units but no value. A purchase counts anywhere in the session: before the action ran, after it, or in a session where it never ran. So products_goal_n_sessions can be larger than n_sessions_executed, and it measures the buying of the visitors the action was aimed at, not purchases the action caused. To judge whether an action changes buying, compare it with a control group: read the campaign's A/B verdict rather than these columns alone.

For recommendations, the same three shapes repeat for products and for content, at each stage of the funnel:

products_recom_viewed_n_times, products_recom_viewed_n_sessions, products_recom_extra_n_times, products_recom_extra_n_sessions, products_recom_extra_value, products_recom_goal_n_times, products_recom_goal_n_sessions, products_recom_goal_value

…and the identical set prefixed articles_recom_ for content recommendations.

These count products the visitor clicked in this action, and what happened to those products next: viewed is every clicked product, extra the ones then added to the cart, goal the ones then bought (later in the same visit or a later one). Only a click on a product card counts, and only for the product that card showed:

• A click elsewhere in the widget (a heading, an arrow, a button) counts in n_extra but not here.
• Buying a different product after the click is not counted.
• The later view, add-to-cart or purchase must report the same product id as your catalog, so product tracking that reports a different id (a SKU where the catalog holds a numeric id, for example) will not connect.

A widget built from a design that does not mark its cards reports clicks in n_extra and zeros here. _value is quantity at the product's catalog price, and a row is dated by the day of the latest step.

Custom goal events

If your account defines goal events, each one adds four columns, numbered by its index:

goal_event_{N}_name, goal_event_{N}_n_times, goal_event_{N}_n_sessions, goal_event_{N}_value

goal_event_{N}_name returns the event's name as configured in the panel, so a report can label its own columns without hard-coding them. Which indices exist depends on your account — request all columns once to discover them.

Select example

Last 30 days, newest first:

curl 'https://api:FD09908F25BECB09D78EBEA1DADFB618651F612D@app.personyze.com/rest/summary_actions/order_by_desc/day/limit/1000'

A date range for one campaign, with just the headline numbers:

curl 'https://api:FD09908F25BECB09D78EBEA1DADFB618651F612D@app.personyze.com/rest/summary_actions/where/day>=2026-07-01&day<=2026-07-31&campaign_id=42/columns/day,action_name,n_delivered,products_goal_n_times,products_goal_value'

Performance

day is the only well-indexed column here. Always constrain or sort by day — an unfiltered scan across all history will be refused or truncated, as described in errors and limits. Pull history in date-ranged pages rather than in one request.