Ad fatigue check

Ad Fatigue Check

PREREQUISITE: Read ../_mureo-shared/SKILL.md for auth, security rules, output format, and Tool Selection (Read/Write on Code, mureo_strategy_* / mureo_state_* MCP on Desktop / Cowork).

Find the ads whose audience has seen them too many times. Creative fatigue is a slow leak — the same creative keeps spending while frequency climbs, CTR erodes, and CPM drifts up as the algorithm works harder to place a tiring ad. This skill reads active ads per platform, measures the fatigue signals the tools genuinely expose, scores each ad against documented thresholds (with noise guards so a single slow day never triggers a rotation), and hands the fatigued ones to a creative refresh with the evidence attached.

Prerequisites

• STRATEGY.md and STATE.json must exist (run the onboard skill first)

Steps

Before you start: Run the Diagnostic preamble from ../_mureo-shared/SKILL.md — load learning insights (mureo_learning_insights_get) and consult advisors (mureo_consult_advisor) before drawing conclusions.

0. Establish today: call mureo_state_get first, on every host (including Claude Code, where you would otherwise Read the file) and take server_now from its response — ISO 8601 with UTC offset, e.g. 2026-07-28T10:12:33+09:00. Its date is the only source of the current date for this run: the observation_due you write in step 9 is server_now's date + 14 days. (The week-over-week windows in step 3 are platform-side period tokens — last_7d / LAST_7_DAYS — so the platform resolves those against its own clock; do not hand-build date ranges for them.) Do not shell out (this skill must run in Bash-less headless hosts) and do not read the date off STATE.json — last_synced_at, reports.*.period and action_log timestamps are history, never evidence of what day it is now. Never write server_now into STATE.json: it is a response field, and a persisted copy becomes tomorrow's stale "today".

1. Load context: Read STRATEGY.md (Goals, Operation Mode) and STATE.json. Note any learning insights about fatigue thresholds — a VALIDATED insight ("this account tolerates frequency 5 before CTR drops") overrides the default rubric in step 4.

2. Discover active ads per platform — not running is not fatigued, on every platform. Before scoring anything, exclude each ad whose delivery-status field (effective_status when the platform reports one, otherwise status) is not that platform's active value, and say so rather than scoring it: a stopped ad has no fatigue to measure, and its soft numbers are the stop, not a worn-out creative. This exclusion is platform-independent — the bullets below only say which tool and which value each platform uses.

   • Meta: meta_ads_ads_list, and keep only ads whose effective_status is ACTIVE — that is the field that says an ad is really delivering. An ad can read status: ACTIVE while its effective_status is PAUSED / ADSET_PAUSED / CAMPAIGN_PAUSED / DISAPPROVED, and it is effective_status that decides. In BYOD mode this response is wrapped as {"source": "byod_import", "as_of": <import time>, "data": [...]} — take the rows from data and treat them as of as_of, not as live.
   • Google Ads: google_ads_ad_performance_report scoped to ENABLED ads.
   • Also include any hosted connector (TikTok, key tiktok_ads) / mcp__mureo__<plugin>_* plugin platform best-effort, reporting only what its own tools expose and emitting analytics_not_available_for_<platform> for the fatigue value-adds below — <platform> being the canonical platform key (plugin:<dist>:<provider> for a plugin, tiktok_ads for the connector), never an analytics registry_name (see ../_mureo-shared/SKILL.md → Canonical platform key). BYOD data is reachable only through mureo MCP tools — do not look for raw CSVs in the project directory.

3. Measure fatigue signals — honestly, per what the tools expose:

   • Meta — frequency (derived, not a direct field). mureo's insights tools do not return a frequency field — but meta_ads_insights_report returns both impressions and reach, and frequency is defined as impressions ÷ reach. Compute it yourself from meta_ads_insights_report (level ad, window last_7d): frequency ≈ impressions / reach. This is Meta's own definition, so it is an honest derivation, not a guess. If reach is 0 or absent for an ad, the frequency is undefined — say so, do not divide.
   • Meta — CTR trend, week-over-week. meta_ads_insights_report (level ad) exposes ctr but no built-in trend. Get two adjacent weeks the same way weekly-report does: pull last_7d (this week) and last_14d, then derive the prior week as last_14d totals − last_7d totals. Compute the CTR change % between prior-week and this-week.
   • Meta — CPM drift. meta_ads_insights_report returns cpm; compare this-week vs prior-week CPM (same subtraction technique). Rising CPM on a flat audience is a fatigue corroborator. meta_ads_analysis_cost also decomposes a campaign's cost change into CPM inflation / CTR drop / creative fatigue drivers — use it to corroborate at campaign level.
   • Google Ads (Display / RSA whole-ad). Ad-level CTR trend from google_ads_ad_performance_report over adjacent windows (LAST_7_DAYS vs LAST_14_DAYS, same subtraction); Google Ads exposes no frequency at the ad level here, so score Google display/RSA ads on the CTR-trend signal only and say so.
   • Google Ads Search — RSA fatigue is asset-level, not ad-level. A Responsive Search Ad tires one asset at a time; whole-ad CTR hides it. Reference the RSA audit tools instead: google_ads_rsa_assets_audit (replacement recommendations) and google_ads_rsa_assets_analyze (per-asset performance_label + CTR) to find LOW/POOR assets to swap.

4. Fatigue scoring rubric (document the thresholds; let learning insights override them):

   • FATIGUED — frequency ≥ 3.5 AND CTR decline ≥ 20% week-over-week (both signals present).
   • WATCH — exactly one signal present (frequency ≥ 3.5 alone, or CTR decline ≥ 20% alone, or a clear rising-CPM + softening-CTR pair).
   • FRESH — neither signal. These are defaults, not laws — a VALIDATED learning insight for this account/Persona replaces them, and Google display/RSA ads (no frequency) can reach WATCH on CTR decline alone but not the two-signal FATIGUED bar unless corroborated by CPM drift.

5. Noise guards (apply before assigning any verdict):

   • Minimum impressions per window: require ≥ 1,000 impressions in each of the two adjacent windows before reading a CTR trend (the CTR sample floor from ../_mureo-learning/SKILL.md). Below that, the ad is insufficient-data, not fatigued.
   • Single-day dips never count — the comparison is week-over-week on 7-day windows precisely so one bad Tuesday cannot trigger a rotation.
   • Learning-state noise is not fatigue. An ad whose ad set is in its Meta learning phase (new, or recently reset by a significant edit), or whose Google Ads bid strategy shows "Learning", has unstable delivery by design — soft CTR and drifting CPM there are the learning window, not a worn-out creative. Mark those insufficient-data / re-check after the window, never FATIGUED, and do not rotate creative on that basis (a creative swap resets the phase again). See ../_mureo-pro-diagnosis/SKILL.md → Allocation & Learning-State Discipline.
   • Note confounders: a new competitor, a seasonal lull, or a landing-page change can mimic fatigue — flag them rather than blaming the creative.

6. Ranked table — worst first:

   Ad	Campaign	Frequency	CTR w/w	CPM w/w	Impr (this/prior)	Verdict
   Ad A	Prospecting	4.2	−27%	+14%	32k / 30k	FATIGUED
   Ad B	Retargeting	3.6	−8%	+3%	18k / 17k	WATCH
   Ad C	Brand	1.8	−4%	+1%	21k / 20k	FRESH

7. Recommendations — rotate / refresh, with the evidence as the brief: For each FATIGUED (and borderline WATCH) ad, hand off to a creative workflow, passing the fatigue evidence (frequency, CTR decline, the tiring asset) as the input brief:

   • New visuals + composed banners → /creative-generate.
   • Copy / headline refresh, RSA asset swaps, Performance Max asset-group text → /creative-refresh. Do not silently produce new creative here — this skill diagnoses and routes; the creative skills generate under their own approval gates. Route, do not promise. Whether mureo can apply a rewrite depends on the surface, not on the verdict: /creative-refresh runs its Apply or draft check per item and may come back with copy for the operator to paste in by hand (every image, video and logo asset today, and any surface whose write tool is absent from the session). Hand the fatigue evidence over as the brief; do not tell the operator here that the creative will be rewritten, and do not offer the rewrite yourself — from this skill you cannot see which write tools cover the tiring asset.

8. Pausing a clearly-fatigued ad — approval gate: Pausing is a write. Apply the Confirm Before Write Operations rule from ../_mureo-shared/SKILL.md: list the ad(s), their current spend/frequency/CTR, and confirm before pausing via meta_ads_ads_pause (Meta) or google_ads_ads_update_status (Google Ads). Prefer rotate-in-a-replacement over pause-into-a-gap unless the ad is actively harmful — pausing without a fresh creative ready starves delivery. Never bulk-pause without listing the total impact first.

9. Record outcome context: For each ad paused or queued for refresh, append to action_log via mureo_state_action_log_append with metrics_at_action (frequency, ctr, cpm, impressions, conversions, cpa) and observation_due 14 days out from server_now's date (the creative-change window from ../_mureo-learning/SKILL.md). A pure diagnostic run with no writes still logs a summary entry (the verdict table), with no observation_due.

10. Persist the report summary (best-effort): Call mureo_state_report_set with report="fatigue" and a concise summary object so the read-only dashboard can render this check without re-running you. Follow this convention:

    • generated_at: ISO 8601 timestamp of this run — use server_now
    • period: the two adjacent windows compared (this week / prior week)
    • totals: the account's headline figures, using the canonical metric vocabulary — spend, conversions, cpa, ctr, clicks, impressions. This is the block the dashboard renders as figures. Raw numbers only: 773957, not "¥773,957"; 0.0466, not "4.66%" — one of those keys carrying a string is refused, because it sits where the view reads a figure and renders as nothing. A key outside the vocabulary may ride along: it is stored, just not shown as a headline number. Omit totals entirely if this run gathered no account-level figures.
    • kpis: counts by verdict (fatigued / watch / fresh / insufficient-data) and the worst-frequency + worst-CTR-decline ads — the breakdown, not the headline row
    • flags: notable items (e.g. ["3_ads_fatigued", "meta_reach_missing_frequency_undefined", "google_display_ctr_only"])
    • narrative: the verdict (creatives fresh / rotation needed) and what you propose next, at most 400 characters — the tool refuses a longer one rather than truncating it (a sentence cut in half is worse than a long one). Do not restate the figures and do not list the findings here: numbers belong in totals, findings in flags.

    Reflect the FINAL state, and persist this LAST — after every action_log entry and any pause you applied this run. This is best-effort: if mureo_state_report_set is unavailable (e.g. a pure file-mode host without the context MCP), skip it silently — the rest of this skill still works.