report_data attack/defend payload returned when you fetch a single report by id.
Report object
GET /api/public/competitor-monitoring/reports returns these fields per report (the heavy report_data blob is omitted from the list). GET .../reports/{reportID} returns the same fields plus search_params and report_data.
report_data
The body splits into a summary header, the atk and def account lists (each an array of account signals, ranked by distinct_reps, then comments, then interactions, then the latest touch), and a reps drill-down.
summary
atk / def (account signal)
Each entry inatk and def is one account the competitor touched. def accounts are those you own (matched to a CRM company or owner); atk accounts are everything else.
Each
targets entry:
reps
Per competitor rep, the interactions they made.
Each
interactions entry:
How accounts are ranked
Withinatk and def, the account the most competitor reps touched comes first, because several of their people on one account is the strongest sign. Ties go to the account with more comments, then more interactions, then the most recent touch.
Example report
GET /api/public/competitor-monitoring/reports/{reportID}:
Report-ready webhook
If the competitor report’s webhook is on (see Update Delivery Config), Clustr POSTs acompetitor_monitoring.report_ready event to your URL each time the report goes out. There is one report for the whole workspace, covering every competitor, so the payload lists the competitors and every account the report covers, uncapped. A workspace that splits its audiences into routes gets one POST per route, each carrying that route’s accounts.
The report covers everything since the previous one (the last 14 days for the first), at most once per monitoring period, and only when a competitor’s people engaged someone at a company in that time. An account is a company: people whose company is not known are counted in people_no_company.
Each element of
accounts:
The request carries
X-ClustR-Event: competitor_monitoring.report_ready and is not signed: the report’s delivery settings have no secret. It goes through the same queue as the alert webhooks, with the same retries; see Webhook payloads.
The matching email carries the same counts and a button to link.