The useful version of competitor ad research is not a folder of screenshots. It is a repeatable loop: define the market, collect public ads at enough scale, normalize the records, search across jobs, tag signals, and export the evidence.
Why this is not generic advice
This page is written from Pullmesh source-package behavior, buyer handoff boundaries, and the actual operational controls described on the product page: capability numbers, export surfaces, approval gates, provenance, and exclusions.
Key takeaways
- Start from a narrow market definition before collecting data.
- Preserve provenance fields so the research can be reviewed later.
- Use checkpoints and dedupe when the run is large enough to fail halfway.
- Export both analyst-friendly tables and raw records for technical buyers.
Start with a market definition
A useful run begins before collection. Define the country, advertiser set, active or inactive status, date range, platforms, language, destination domains, offer type, and creative format you want to inspect.
The query should map to a business question. A media buyer might ask which hooks competitors are repeating. A founder might ask which offers are active this month. A research team might ask which domains, CTAs, and creative variants are moving through a niche.
Collect enough records to see patterns
Manual browsing is fine for a quick look, but it breaks when the goal is market intelligence. Pullmesh positions the Meta console around high-volume public-ad research, including 50k+ research-run targets when the buyer environment can support the workload.
Large runs need operational controls: date-window collection, shared targets, checkpointed progress, duplicate verification, and resume state. Those controls matter because ad-library work is often interrupted by browser sessions, rate behavior, and long-running requests.
Search across runs instead of living in tabs
The center of the workflow is Search All: a way to interrogate collected jobs after the expensive collection step has already happened. Search by text, advertiser, destination domain, format, status, platform, recency, and transparency fields.
That changes the output from a browsing session into a reusable research store. One run can answer several questions: hooks, offer structure, landing-page patterns, CTA language, carousel use, dynamic creative variants, and advertiser concentration.
Export evidence, not decoration
A client-ready report should be backed by structured records. The Pullmesh package is designed around ZIP, CSV, JSONL, and JSON exports with summaries, assets, manifests, transparency rows, advertiser rollups, and optional raw records.
The export should let a strategist read a table, let an analyst re-run filters, and let a technical buyer inspect raw fields. That is the difference between an opinion deck and research that can survive review.
Competitor ad research checklist
- Define the market, query, country, date range, platforms, and status.
- Collect public ads with checkpoints, resume state, and duplicate checks.
- Normalize advertiser, creative, CTA, destination, format, and transparency fields.
- Search across jobs for hooks, offer patterns, media formats, and domains.
- Tag the findings that will become report sections.
- Export tables, manifests, summaries, assets, and raw records.
pullmesh package
Meta Ad Library collection console
This article maps to the working source package rather than a generic content campaign. Review the product scope, proof points, exclusions, and handoff path.
FAQ
Is Meta Ad Library research the same as scraping private user data?
No. The Pullmesh positioning is public-ad research. Buyers still need to review platform terms, local law, privacy posture, and operational risk before running their own environment.
Why not just use screenshots?
Screenshots are useful as visual references, but they are weak as a research system. Structured records let you search, filter, dedupe, export, and revisit the same evidence later.
What should a serious export include?
At minimum: ad identifiers, advertiser fields, text, CTA/domain signals, status, date fields, format fields, transparency rows, assets, query metadata, and a manifest that explains the run.