/apify-buying-signal-detection

name: apify-buying-signal-detection
description: Set up a recurring buying-signal detection pipeline that finds companies showing buying intent across three signal types — job postings (hiring for the persona), fundraising events (recent raises), and LinkedIn content (pain-point posts, hiring announcements) — then aggregates results into a deduplicated leads.csv with the signal source, evidence URL, and detection timestamp per row. Split-schedule architecture — Apify Actor Tasks pull raw data on their own cadence, a Claude-side aggregation task normalizes, deduplicates against a blacklist, and appends new leads with a weekly-idempotent guard. Use when the user says "find companies with buying signals", "detect intent signals for outbound", "set up a weekly lead pipeline", "monitor hiring signals for lead gen", "track startup funding leads", "find LinkedIn buying signals", "schedule Apify Actors for prospecting", "build a signals-based lead list", or "set up buying-intent monitoring for my ICP".
author: Fabian Maume
author_url: https://github.com/fmaume
metadata:
  keywords: "buying-signals, intent-data, lead-generation, outbound, prospecting, hiring-signals, funding-signals, linkedin-signals, sales-triggers, icp, scheduled-pipeline, b2b"

Buying-Signal Detection

Turn an ICP description into a recurring pipeline that surfaces companies showing buying intent across three signal types — job postings, fundraising events, and LinkedIn content — and appends them to a single deduplicated `leads.csv` you can pipe straight into your CRM.

What this skill does (and what it deliberately does not)

This skill **sets up and runs** a scheduled workflow. It does not draft cold emails, score leads by fit, or push rows into a CRM. Its output is a clean, evidence-linked `leads.csv` — the *input* to whatever outreach process you already have. Cold outreach drafting for these leads is deliberately a separate concern (that's what `apify-link-prospecting-outreach` and similar skills exist for).

Three design commitments worth knowing before you start:

1. **The Apify side and the Claude side run on separate schedules.** Apify runs the Actors on its own cron; Claude runs the aggregation on its own cron. Claude Code doesn't need to be up when the Actors run. This decoupling is what makes the pipeline actually recurring, not just "you have to remember to trigger it." 2. **Weekly idempotency is enforced at aggregation time.** If the leads CSV already has an entry from the current ISO week, the aggregate script exits early with no HTTP calls made. The Claude-side schedule can fire more often than weekly (safety net) without cost impact. 3. **First-seen wins on dedup.** A lead surfaced by the jobs signal on Monday stays a jobs-signal lead even if the same company shows up in the funding feed on Wednesday. The signal that first surfaced a company is the more useful one.

Prerequisites

• Apify account ([sign up](https://apify.com))
• Authentication via one of:
• `apify login` (OAuth, if using the Apify CLI)
• `APIFY_TOKEN` environment variable
• Token from [Apify Console → Settings → Integrations](https://console.apify.com/settings/integrations)
• Python 3.10+ (for `scripts/aggregate.py` and `scripts/setup_apify_tasks.py`; only stdlib is required — `requests` is used when available but has a `urllib` fallback)
• Optional: a way to trigger the Claude-side aggregation on a schedule — the local `scheduled-tasks` MCP is the recommended path when you're on Claude Code; cron / Task Scheduler / GitHub Actions all work too if you'd rather run it headlessly

Workflow

Copy this checklist and mark items done:

Task Progress:
- [ ] Step 1: Collect ICP inputs (block on these)
- [ ] Step 2: Write icp.json + blacklist.csv (if any)
- [ ] Step 3: Provision Apify Actor Tasks (setup_apify_tasks.py)
- [ ] Step 4: Verify Actor picks in the Apify Console
- [ ] Step 5: Register the Claude-side aggregation schedule
- [ ] Step 6: First manual run of aggregate.py — sanity check the output

Step 1: Collect ICP inputs (block on these)

Ask the user for all of the following before writing any file. The setup script needs every field to route correctly, and reworking a scheduled task after it's provisioned means either editing it in the Apify Console or re-running setup — both worse than asking once.

1. **Campaign name** — a short slug (lowercase, dashes). Used as the prefix on every Apify Task name (e.g. `emea-saas-hiring-aes-bebity-linkedin-jobs-scraper`). If the user already runs multiple campaigns, prevent collisions upfront. 2. **Signals to track** — subset of `["jobs", "funding", "linkedin_content"]`. Rarely will a campaign want only one; the strength of the workflow is the intersection of signals per company. Recommend all three unless there's a specific cost concern. 3. **Geo (ISO country codes)** — uppercase two-letter codes. Drives regional Actor routing (Stepstone for DE/AT/BE, Seek for AU/NZ, France Travail for FR, Maddyness for FR-funding). Global campaigns should list every country the user actually sells into — passing `["US", "GB", "DE", "FR", "AU"]` will fan out to five regional job Actors, which is 5× the weekly cost. See [`references/gotchas.md`](references/gotchas.md#cost-guardrails). 4. **Industry keywords** — the category descriptor. Passed to funding trackers as `industry`, to LinkedIn as `keywords` when no explicit content search terms are provided, and to job scrapers as a fallback when no persona titles are given. 5. **Persona (if jobs signal enabled)** — job titles the ICP hires for. Concrete titles beat categories: `"Account Executive"`, `"SDR"`, `"BDR"` are hits; `"sales"` is noise. Optional seniority (`entry`, `mid`, `senior`, `manager`, `director`, `vp`, `cxo`) and company-size bands (`"11-50"`, etc.) get applied post-hoc in the aggregator. 6. **Funding config (if funding signal enabled)** — stages (`seed`, `series_a`, `series_b`, etc.) and `max_days_since_announcement` (defa