Marketing Radar

Marketing Radar

Collect first, separate claims from promotion, then test only what the available population can actually answer. Primary, research-method, trade/community and practitioner-audience evidence are separate populations. Platform narration, popularity, comments and proxy scores are leads, not proof of business impact.

1. Collect

Run the shared collector with this profile:

node "${CLAUDE_PLUGIN_ROOT}/scripts/framework-radar.js" \
  --config "${CLAUDE_PLUGIN_ROOT}/scripts/marketing-radar-sources.json" \
  --days 14

Append --video <ID-or-URL> for every supplied YouTube source. The collector stores transcripts outside the repository, reports source failures and writes a deduplicated manifest under .claude/reports/.

The registry spans first-party changes, research methods, trade/community feeds and practitioner video discovery. Never use the number of feeds as a confidence score: ten outlets repeating one vendor announcement are one underlying claim. Cross-foot both category and authority populations, and require a primary source before a platform-behavior claim can enter test.

Read only manifest items where requires_review is true. Read a transcript only from its recorded local path. Record whether captions are manual, generated or unknown. Never copy a full transcript into a report or repository.

When comments.status is ok, read the recorded local comments path. It contains top and recent samples with author identifiers pseudonymized. Report fetched, retained, excluded and distinct-author populations plus every exclusion reason. The filter removes only high-confidence repetitive, engagement-manipulation and off-platform promotional patterns. Call these excluded bot/spam-like comments, not verified bots: public metadata cannot establish that every retained account is human or every excluded account is automated.

Summarize audience feedback by theme, with a count and at most one short excerpt per theme. Separate sentiment toward the presenter/video from sentiment toward the actual tactic, and list recurring questions and contradictions. Show both unweighted theme counts and whether top-liked comments would change the reading. Comments represent commenters after creator and platform moderation, not all viewers, customers or business outcomes.

Completion: the manifest population and printed population cross-foot, and an all-source failure is reported as a failure rather than a clean run.

Read the adjacent marketing-radar-findings-latest.html dashboard before selecting claims. It clusters repeated coverage into underlying claims and keeps the independent-source count separate. Its source utility score is a shrunk history of executed outcomes, not proof, reach or popularity; keep untested sources eligible for exploration.

2. Build the claim ledger

For every source used, record:

• source URL, publication date, author and channel;
• what the author sells, sponsors or benefits from;
• the claim in falsifiable terms, not the proposed tactic alone;
• evidence tag: primary platform source, measured case, practitioner account, sponsored demonstration, opinion or contradiction;
• domain: traffic, creative, offer, funnel, lifecycle, measurement, SEO, operations or another explicit domain;
• verdict: HOLDS, CONDITIONAL, DEBUNKED, REFUTED or UNTESTED.

Before comparing claims, split them on these boundary axes:

1. Efficiency or spend claims: contribution margin, repeat-purchase profile and cash-payback constraint.
2. Funnel claims: whether conversion requires a human sales conversation.
3. Creative or targeting claims: existing-demand capture versus interruption.

Also record platform, objective, audience temperature, conversion volume, attribution window, geography and time period when known. Missing boundaries make a claim narrower, not universal.

Run these checks before accepting a claim: denominator, selection bias, attribution leakage, survivorship, seasonality, incentive conflict and whether the metric is only a proxy for profit or qualified demand.

Completion: every claim has a domain, incentive note, evidence tag, boundary conditions and verdict. Contradictions remain visible.

3. Corroborate

For each plausible practitioner claim, find a current primary platform source that supports, limits or contradicts the mechanism. Then inspect the current repository, anonymized dataset or workflow that would be changed.

Classify each lead:

• already handled: current evidence shows the process already does it;
• watch: plausible, but a representative population or authority is missing;
• test: a safe fixture and business-relevant outcome are available now;
• reject: mechanism or evidence fails a named check.

State what observation would change the classification. A lead may enter test only with one external source, one current-workflow artifact and a population that can measure the claimed effect.

4. Execute every selected hypothesis

Read the newest prior marketing-radar reports first. An earlier selected hypothesis without a verdict is pending work and takes priority.

Select at most three hypotheses. Every selected hypothesis must be executed in this run. Anything that cannot run now stays watch; do not disguise it as an experiment.

Before results, preregister:

• hypothesis and exact population or fixture;
• primary business outcome plus correctness, cost and guardrail measures;
• adoption threshold, failure signal and rollback;
• held-constant variables and the boundary axes above;
• A: current behavior, B: proposed behavior, C: simpler alternative.

Use the strongest safe test available:

1. Historical replay on anonymized event, campaign or funnel data.
2. Read-only shadow analysis against a current export.
3. Draft-only creative, offer, landing-page or lifecycle variants evaluated on a preregistered representative task set.
4. Synthetic fixtures only for pipeline correctness, never for a marketing performance claim.

An LLM score, click prediction, aesthetic rating, platform-reported ROAS or engagement rate does not by itself prove profit, incrementality or qualified demand. Report the inference boundary explicitly.

Predeclare the sample horizon and analysis. Repeatedly checking a generic significance calculator inflates false winners; use a fixed final analysis or a valid sequential-testing correction. Treat Ads Library longevity as a creative candidate signal only, because ordinary-ad visibility does not expose the performance outcome needed to call it a winner.

Safety and isolation

Use a dedicated worktree and codex/marketing-radar-* branch for framework changes. Preserve raw commands, exit codes, elapsed time and evidence paths.

Scheduled runs are read-only toward ad accounts, analytics properties, CRM, email systems, domains and product repositories. They may create local fixtures, draft artifacts and reports. They must not publish content, send messages, change tracking, upload audiences, alter campaigns or budgets, or start spend. Those actions require fresh explicit authorization and their own rollback plan.

Verdict

Record A/B/C measurements and choose adopt B, adopt C, no winner or reject. When a workflow variant wins, implement only that variant and run its targeted tests plus the repository gate.

A scheduled run may push a winning codex/marketing-radar-* branch and open a review PR only when its automation prompt explicitly grants that exact standing authorization. Interactive runs require fresh push authorization. Never merge, deploy, tag, release, update installed plugins or mutate a live marketing system.

Record outcomes and adoption state

After every selected hypothesis has a verdict, write .claude/reports/marketing-radar-verdicts-YYYY-MM-DD.json with schema_version: 1, the exact manifest run_id, and one hypotheses[] row per experiment. Each row needs a stable id, falsifiable claim, manifest source_keys, verdict (adopt-b, adopt-c, no-winner, or reject), string measurements under variants.a/b/c, tested_at, and at least one raw evidence location.

node "${CLAUDE_PLUGIN_ROOT}/scripts/radar-learning.js" \
  --manifest <manifest-path> \
  --verdicts .claude/reports/marketing-radar-verdicts-YYYY-MM-DD.json

Read back the printed HTML, Markdown and JSON artifacts. The ledger is idempotent and rejects evidence keys outside the collected population. Adopted winners start as candidate; use the same command's --transition mode to move them through evidence-backed shadow, canary, and dated default states. Every default needs --revalidate-by; expired defaults are stale until they return to shadow or retire.

Discovered source hosts are proposals only. Add one to the source registry only after provenance, feed stability and useful yield have been measured across three runs. Discovery must never edit a registry automatically.

5. Report and review

Write .claude/reports/marketing-radar-YYYY-MM-DD.md with:

1. Population and source health, by authority and category.
2. Primary platform changes plus independent/trade leads kept separate.
3. Video audience feedback with comment sampling and exclusions.
4. Claim ledger with incentives and boundary conditions.
5. Executed A/B/C experiments, maximum three.
6. Already handled, rejected and contradictory claims.
7. Watch list and missing populations or authority.
8. Winning branches and review PRs.
9. Learning ledger changes, adoption lifecycle and proposed source discoveries.

The count of selected hypotheses must equal the count with executed verdicts. Zero is valid when no lead is both relevant and safely testable.

After the report is complete and any PR is remotely readable, mark the exact manifest reviewed:

node "${CLAUDE_PLUGIN_ROOT}/scripts/framework-radar.js" \
  --mark-reviewed <manifest-path>

Completion: report totals cross-foot, every selected hypothesis has a verdict, all proxy limitations remain explicit, the user-facing HTML/Markdown/JSON artifacts exist, and the review heartbeat matches the changed-item population.