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 signal_score descending), 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 the signal score works
signal_score weights each interaction by its type (comments score higher than reactions), applies recency decay (interactions in the last 6 months count fully; older ones decay toward 0.7x past 24 months), and adds a bonus for the target’s seniority. The per-account total is then multiplied by the number of distinct competitor reps that touched the account, so concentrated, multi-rep pushes rank highest.
Example report
GET /api/public/competitor-monitoring/reports/{reportID}:
Report-ready webhook
If your workspace has webhook delivery enabled, Clustr POSTs acompetitor_monitoring.report_ready event to your configured URL when a run completes. The payload is a summary plus a deep link; fetch the full report by id for the detail.
The matching email notification carries the same attack/defend counts, the interactions and people-tracked totals, and a “View Full Report” button to
report_link.