Meta ads activity history: investigate changes without guessing
Find what changed. Keep the reason and the decision beside the record.
On this page · 6 sections
Meta ads activity history is the starting point for investigating a change in an ad account. Inspect the affected campaign, ad set or ad and look for the history view available in your Ads Manager interface. Record the object identifier, event time, actor, application and change type where those fields are available. Meta’s official Business SDK exposes these concepts through its AdActivity object and an activities connection on AdAccount. An edit appearing before a decline is evidence of timing, not proof that the edit caused the decline. Compare the record with your approval notes, website changes and reporting settings before deciding what to reverse. Keep a separate decision log for the reason, approver, expected outcome and review date. This guide proposes an investigation method; it does not claim that every interface exposes every API field, that history is complete, or that an arbitrary retention period is guaranteed.
TL;DR
- Identify the account and object before searching.
- Record time zone, actor and application separately.
- Timing alone does not establish causation.
- Keep approvals and reasons in a separate decision log.
Rewritten October 3, 2026. The SDK confirms field names, not the exact menu or coverage in every Ads Manager account. The investigation method and example are editorial recommendations.
Where should you start an activity-history investigation?
Start with one object and one question: which campaign changed, roughly when, and what symptom prompted the review? Confirm the account before looking for a history view. A campaign name alone is a weak reference because names can change and may be repeated across accounts. Keep the stable object identifier with your notes.
In Ads Manager, select the relevant campaign, ad set or ad and look for View history or the equivalent history control in your current interface. Menu labels and availability vary. If you cannot find it, use the account’s help interface rather than assuming that a missing button means nothing changed.
Set the investigation window to include the period before the symptom. Record the account time zone beside it. Avoid searching only after the decline: an earlier edit or website change may be the thing you need to examine.
- Choose the object
- Set the time window
- Record the event
- Compare other changes
- Decide and review
What can the recorded fields tell you?
A useful record distinguishes the object that changed, the actor associated with the event, the application and the time. These fields answer different questions. An application name can identify a tool involved in an edit; it does not by itself explain the person’s intent or establish that the action was approved.
The official SDK defines actor_id, actor_name, application_id, application_name, event_time, date_time_in_timezone, event_type, object_id, object_name, object_type, tool and extra_data. Inspect what is actually present in your interface or authorized export. Do not assume that a defined API field is populated for every event.
Preserve the record as observed. If a field is missing, write unknown rather than filling it from memory. Keep any account identifiers or personal information private when sharing the diagnosis. Review the permissions checklist if the access available prevents a complete investigation.
| Record | Question it helps answer | What to add yourself |
|---|---|---|
| Object identifier | Which entity changed? | Business role of the entity |
| Actor and application | Who or what is associated? | Approver and authorization |
| Event time and type | When and what operation? | Reason and expected outcome |
| Observed final settings | What is now active? | Review date and rollback plan |
How do you connect a change with a performance shift?
Build a timeline that includes the edit, the performance change and other plausible explanations. First confirm that the reporting settings and business outcome stayed comparable. Then formulate an explanation you can test. An edit and a decline close together justify investigation, but several concurrent changes can prevent a clean attribution of the result.
Hypothetical example: a budget was edited on Tuesday and CPA rose on Wednesday. A promotion also ended Tuesday evening, and the report switched attribution settings. The evidence does not justify writing “the budget increase caused the higher CPA.” First compare the offer and reporting basis, then assess the budget hypothesis.
Use the ROAS decline guide for that comparison and calculate the actual business threshold with the ROAS calculator. Keep notes on stock, price, delivery, checkout and tracking releases beside the advertising changes.
What belongs in your own approval log?
Record the reason for a change, the approving person, the expected outcome, a budget constraint and the review date. A platform event is a record of an operation; your decision log explains the business judgment behind it. Keep both linked by the account, object and timestamp so a colleague can reconstruct the decision.
Separate an intended action from the confirmed action. For example, “approved a test budget” and “verified the published budget” are different entries. Save the before state, the proposed state and the state you actually observed after publication. A successful button click is not enough evidence if the final settings were not checked.
Adwize prepares work for review through its approval workflow. Keep the same discipline for a manual edit, an automated rule and an agent proposal. No tool name removes the need for an accountable owner.
- Evidence
- = what you observed
- Hypothesis
- = what might explain it
- Action
- = one change and its owner
- Review
- = when you will check it
How should you handle an unexplained or suspicious edit?
Preserve the evidence before changing settings again, then identify whether the event fits a known workflow. Ask the relevant owner and inspect the authorized applications or rules involved. If access may be compromised, escalate through the business’s security process. A performance investigation should not quietly become a series of untracked account changes.
An application name is a clue, not a verdict. A missing actor is a gap, not evidence that Meta made the change. Record what was confirmed, what remains unknown and which source could resolve it. The account audit checklist helps separate an access defect from a measurement or delivery problem.
Do not post screenshots containing access tokens, billing details, customer data or recovery information in a public forum. Share a redacted description and use the appropriate account-support channel for private records.
What are the limits of activity history?
Treat history as one source of evidence, not a complete explanation of the account. The SDK field list does not guarantee interface parity, complete coverage or a retention period. Your website, CRM and other systems have their own records. Keep those records aligned by time and object before drawing a conclusion about performance.
This guide does not prescribe an API version or ask you to create a token. Developers must verify current permissions, version support and field availability for their authorized integration. Operators can use the records available through their existing access without building a new integration.
Archive decision notes under the business’s retention policy. Keep the report template beside the change log so outcomes and reporting settings remain understandable when somebody reviews the account later.
Frequently asked questions
Does an edit prove why CPA increased?
No. It establishes a timing relationship to investigate. Compare other changes, reporting settings and business outcomes before concluding causation.
Can I rely on campaign names?
Use identifiers with names. Names can change and may repeat, so a name alone can point to the wrong object.
How long does Meta keep activity history?
This guide does not assert a guaranteed retention period. Preserve your own decision records under the business’s policy and verify current availability in your account.
Is the history the same as an approval log?
No. Add the business reason, approver, expected outcome and review date to your own log, linked to the recorded event.
Sources
- Meta: AdActivity fields in the official SDKAccessed 10/03/2026
- Meta: AdAccount activities in the official SDKAccessed 10/03/2026
