AdAce AdsTriage advertising incidents before choosing a campaign action
An alert is a reason to investigate, not a diagnosis or an instruction to change the budget. This suggested triage method classifies what may be failing, identifies affected scope and assigns the next evidence request. It helps the team respond quickly while avoiding a campaign edit that hides the original problem or makes a measurement incident look like a performance issue.
An incident card and four branches
Start an incident card with detection time, data time, client, account, affected objects, symptom, known impact and investigation owner. Detection time is when someone noticed the issue; data time is when the observed events happened. Record the first reliable evidence and its completeness. Separate confirmed impact, such as no recorded impressions for a mature interval, from possible impact, such as sales that may not have been attributed because tracking is incomplete.
Classify the working branch: measurement, delivery, payment or performance. Measurement covers missing or inconsistent events. Delivery covers eligible campaigns that are not reaching users or an explicit status problem. Payment covers an observed account funding or billing issue, confirmed through an authorized source. Performance covers a worsened business outcome after data quality and delivery checks. Multiple branches can be open; classification is a routing hypothesis, not a forced single-cause label.
In a teaching example, reported conversions fall to zero while impressions and spend remain present. A poor-creative explanation is possible, but the first branch is measurement: confirm event availability and website behavior. If qualified sales still exist in the separate business record, do not immediately label the campaign as producing nothing. AdAce Ads monitors create incidents and notify; the investigation method here is separate from monitor setup. Connection health, tracking audits and delivery information can contribute evidence when available.
Urgency, scope and evidence ownership
- Define urgency from current exposure and business consequence, not only from the metric's percentage change. A small account-wide payment stoppage may need faster attention than a large percentage move based on one immature conversion.
- Preserve the first observation before taking an authorized containment action. Capture the safe state reference, date and affected object. Do not place tokens, personal records or raw callback links into the incident notes.
- Assign one coordinator and distinct evidence owners. The coordinator keeps the timeline and escalation visible; a tracking owner, account owner or finance contact verifies the branch within their actual authority.
Investigate before intervening
- Confirm identity and dates. Ensure the alert refers to the intended client and account, and check whether the underlying data is mature, missing or delayed. Unknown data should produce an evidence request rather than an invented zero.
- Check the extent: one campaign, several objects or the entire account. Compare the last known healthy interval with the first affected interval. A common boundary can point to a shared connection or business event without proving its cause.
- Follow the most plausible branch with the smallest safe checks. Review saved statuses, event coverage and known account messages. Payment details must come from an authorized source; do not infer a declined payment solely from a delivery gap.
- If exposure requires containment, separate the proposed action from diagnosis and obtain the required authorization. Record its reason and expected consequence. If AI assists, require read-only analysis and text, forbidding propose_change and all writes.
- Close only after a defined recovery check: expected events return, the relevant status is verified or the business outcome is interpretable again. Record the root cause as confirmed, likely or unresolved and assign follow-up prevention work with evidence of completion.
Recovery and diagnosis are different claims
- An apparent recovery after a change is not proof that the change fixed the cause. Provider delays, restored data collection or unrelated client actions may coincide. Keep the incident timeline and alternative explanations.
- This card does not promise live availability of every provider diagnostic, payment detail or notification channel. Use capabilities actually available to the account and deployment. A monitor's notification-only role does not imply that separate agents or eligible proposals can never execute.
Sources and further reading
Try it on your own accounts
Create a workspace, connect Google or Meta in a couple of clicks and see your accounts clearly. Changes follow your approvals or the policy you configure.
Create your workspace