---
name: analyze-why-underperformers-fail
description: "Find out why an ad or page is not doing its job before you change it."
category: Strategy & Measurement
stage: —
definitive_article: GAP — to be written
status: needs-work
---

# Analyze why underperformers fail

Find out why an ad or page is not doing its job before you change it. This guide helps your team choose one fix that the facts support. Start with the weak results and the goal set before the test.

**The path:** Goal + data → Find the weak step → Test the cause → Fix proposal

**Start when:** A measured item missed its agreed target and needs a diagnosis before a change is proposed.

## Inputs

- [Show what works and what needs review](https://local-service-spotlight.github.io/task-library/?task=show-whats-working-and-what-isnt#task-show-whats-working-and-what-isnt) with item IDs, periods, targets and sample limits.
- [Goals, Content, Targeting: the result, proof and people for this work](https://blitzmetrics.com/gct-business-strategy/) brief from launch, actual content, audience settings and landing path.
- Funnel data and source records for delivery, clicks, visits, qualified leads and sales; previous changes and conversion delays.

## Steps

1. Check tracking and the evaluation window first. Missing tags, an unread source, a changed definition or unfinished conversion delay can explain a weak number. Keep the case unresolved until those checks permit a verdict.
2. Locate the weak step: were the intended people reached, did they engage or visit, and did visits become the agreed result? Compare like campaigns and periods; one ratio does not establish a cause.
3. Inspect creative, meaning the message, image or video. A weak hook or low watch time is a hypothesis. Compare its content and delivery with a relevant stronger item before blaming the message.
4. Inspect targeting: read actual geography and audience settings, the queries or comments, and eligible customer characteristics. An ad name alone does not prove who saw it.
5. Inspect the offer and follow-up path. Check message match, load/form function, price and proof, then lead handling. Strong clicks with few bookings can reflect tracking, an unclear offer or missed calls; separate those possibilities.
6. Name one best-supported primary constraint when evidence supports it, with source links and alternatives ruled out. Otherwise state unknown cause and the next discriminating check. Do not force every item into a proven creative, targeting or offer bucket.
7. Recommend one bounded fix, its expected signal, owner, test window and limit. Read previous attempts before recommending another retry or a pause; elapsed cycles alone do not justify a kill. Pass the diagnosis to the decision owner.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the result against its agreed requirements; see the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Each case has a supported diagnosis or an explicit unresolved question and next check.
- [ ] The evidence names the failure point without treating correlation as proof.
- [ ] The proposed test has an owner, bounded scope and acceptance rule; no ad changes are implied.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A made-up repair shop gets 100 paid visits and no recorded forms. A test submission fails on a phone. The first fix is the form, with a successful test and later lead count as checks. The data does not yet prove that the audience or price is wrong. The ad stays under its existing owner’s spend rules.

## Handoff and Content Factory context

[Pause weak tests and scale proven winners](https://local-service-spotlight.github.io/task-library/?task=kill-underperformers-scale-winners#task-kill-underperformers-scale-winners) receives the proposed action after review; [Write the agreed weekly report](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday) receives the evidence and unresolved cases.

This work supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/) across its relevant stages. It uses the actual inputs and next owner above; a strategy or measurement guide does not manufacture transcripts, clips or other unrelated stage outputs.

## Start with an agent

Give the AI worker this recipe, the real Inputs, the desired result and the actions already authorized. Ask for the saved output, source evidence, passed and failed checks, and the next owner. A skill is a set of instructions. Loading it does not prove access, install a scheduled job or complete the work. Use the [current installation guide](https://localservicespotlight.com/install/) only if reusable setup is needed; a ZIP contains instructions and is not an access grant.

Use the actual supported app and verified source access. A model name is not a promise of browser control, memory or unattended work. For recurring work, inspect the real job’s trigger, owner, timezone and observed firing; this recipe creates no schedule. Before any media playback, mute the player and set volume to zero. A silent review does not prove sound was heard.

## Record the real execution

Open the run record when work begins. Keep one execution ID, the exact starting recipe revision, input sources and actual state. Write a [meta article, the record of one real execution](https://blitzmetrics.com/meta-article-prompt/) with results, checks, failures and next owner. Link it to this task in the [Task Library](https://local-service-spotlight.github.io/task-library/). Writing is required; public release follows existing authority.

Reuse the same execution ID for internal reviews, meta writing, revisions and retries. A blocked run stays open with its dependency and owner, without an invented finish time. Keep historical public examples as dated evidence; article counts alone are not verified execution frequency. Use supported findings to propose and verify a recipe improvement.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- A dedicated canonical article is not mapped in this task’s source. Use the linked method references above and resolve the correct existing owner before creating another page.
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=analyze-why-underperformers-fail#task-analyze-why-underperformers-fail)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, account access, an actual execution or a client outcome.

A relevant real execution, source evidence, independent reviewer and accepted handoff remain to be recorded. The fictional example teaches the method and does not fill a real-run evidence gap. The opening and full method need a named semantic reviewer; the task-specific path is source guidance, with visible desktop/mobile presentation still to check.