API pemantauan pesaing untuk perunding: satu bagi setiap klien

Setiap kontrak retainer ada satu ayat tentang memerhatikan pasaran. Tiada sesiapa membilkan ayat itu secara berasingan, dan ia perkara pertama yang tergelincir dalam bulan yang sibuk.

Versi manualnya ialah satu tab pelayar bagi setiap klien dan ingatan yang baik. Versi yang dibina ialah sebuah scraper, yang bertahan sehingga projek ketiga. Menjelang itu, benda yang anda tulis untuk klien pertama sedang diam-diam membandingkan halaman yang telah direka semula pada bulan Jun, dan tiada siapa perasan, kerana monitor yang tidak menemui apa-apa dan monitor yang sudah mati kelihatan serupa dari luar.

Sebuah API pemantauan pesaing untuk perunding membawa satu kekangan yang tidak ada pada yang dibina untuk kegunaan dalaman. Anda memerhati beberapa pasaran serentak, bagi pihak orang lain, selama mana setiap projek itu berjalan.

Bagaimana anda mengasingkan pemantauan seorang klien daripada klien yang lain

Satu monitor bagi setiap klien. Sebuah monitor ialah satu nama, sehingga 20 URL, satu jadual cron dan satu zon waktu, dan satu akaun boleh memuatkan 50 daripadanya. Itu bermakna lima puluh projek dengan dua puluh halaman setiap satu sebelum mana-mana had patut difikirkan.

curl -X POST https://crawlforge.dev/api/v1/monitors \
  -H "X-API-Key: cf_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Northwind - competitor pricing",
    "targets": [
      { "url": "https://rival-a.com/pricing", "selector": ".pricing-table" },
      { "url": "https://rival-b.com/careers", "selector": "main" }
    ],
    "schedule_cron": "0 7 * * 1",
    "timezone": "Europe/London",
    "retention_days": 365,
    "notify_emails": ["you@yourfirm.com"]
  }'

Namakan ia mengikut nama klien. Ini bukan soal kemasan: setiap pemeriksaan menulis satu baris ke dalam log permintaan anda yang membawa nama itu, id monitor dan credits yang benar-benar dicaj, jadi berapa yang kita belanjakan memantau pasaran Northwind pada bulan Ogos menjadi soalan yang boleh dijawab oleh log tersebut, bukan soalan yang anda bina semula pada malam sebelum menghantar invois.

Tetapkan timezone bagi setiap monitor juga. Pagi Isnin klien belum tentu pagi Isnin anda, dan pemeriksaan pukul 7 pagi di hemisfera yang salah tiba selepas mesyuarat yang sepatutnya ia bantu.

Bolehkah anda memandunya daripada Claude Code dan bukan curl

Boleh, dan untuk minggu pertama sesuatu projek itulah alat yang lebih baik. MCP server CrawlForge mendedahkan jentera yang sama melalui track_changes, jadi kerja penerokaan — apa sebenarnya yang berbaloi dipantau di sini? — berlaku dalam editor yang anda memang sedang gunakan untuk menulis deck itu.

{
  "url": "https://rival-a.com/pricing",
  "operation": "create_scheduled_monitor",
  "trackingOptions": { "customSelectors": [".pricing-table"] },
  "scheduledMonitorOptions": {
    "hosted": true,
    "name": "Northwind - rival A pricing",
    "schedule": "0 7 * * 1"
  }
}

Ada dua perkara tentang panggilan itu yang patut anda tahu sebelum bergantung padanya, dan kedua-duanya tidak jelas daripada schema.

hosted lalai kepada false. Monitor berjadual tempatan berjalan di dalam proses MCP server, jadi ia berhenti sebaik sahaja anda menutup editor. Memadai untuk seminggu penerokaan, tidak memadai untuk kontrak retainer. Hantar hosted: true dan monitor itu berpindah ke scheduler CrawlForge sendiri, yang menyala sama ada komputer riba anda dibuka atau tidak.

goal dalam bahasa biasa tidak terselamat selepas perpindahan itu. Secara tempatan anda boleh menulis goal: "tell me when the Pro plan price changes" dan sebuah model akan menilai setiap diff terhadapnya. Monitor hosted mengabaikan goal dan memberitahu setiap halaman yang berubah, baharu, disekat atau tersilap. Alat itu memang mengembalikan amaran yang menyatakannya, yang mudah terlepas pandang. Hadkan skop monitor hosted dengan pemilih CSS, bukan dengan satu ayat.

Ada juga masalah kiraan, bukannya perangkap. Laluan MCP mencipta satu monitor bagi setiap URL, memecahkan customSelectors menjadi sasaran pada halaman tunggal itu, jadi dua puluh halaman klien dengan cara itu memakan dua puluh daripada lima puluh monitor anda. POST REST di atas memuatkan kesemua dua puluh itu dalam satu. Gunakan MCP untuk minggu anda masih menentukan apa yang penting, kemudian satu panggilan REST untuk monitor yang anda memang mahu simpan.

Apa yang berlaku antara fasa projek

Jedakan ia. Buat PATCH pada monitor kepada status: "paused" dan ia mengekalkan setiap garis dasar serta tidak mendapat larian seterusnya, jadi ia tidak berbelanja apa-apa sementara menunggu. Sambung semula, dan pemeriksaan pertama membandingkan dengan tangkapan terakhir sebelum jeda itu. Bulan-bulan yang sunyi kembali sebagai satu perubahan, bukan sebagai lubang dalam rekod.

Apabila sesuatu fasa memerlukan jawapan hari ini dan bukan pada slot berikutnya, POST /api/v1/monitors/{id}/run menjalankan satu pemeriksaan serta-merta dan memulangkan halaman-halamannya.

Dari mana sebenarnya penyampaian kepada klien itu datang

Daripada sejarah pemeriksaan, bukan daripada ingatan anda tentangnya. GET /api/v1/monitors/{id}/checks menyenaraikan pemeriksaan dari yang terbaharu, dan membaca satu daripadanya memulangkan halamannya dengan change_percent, kiraan baris yang ditambah dan dibuang, serta sehingga 20 baris sampel daripada setiap belah diff. Itulah bahan yang boleh dipetik untuk slaid apa yang berubah suku ini, bukannya tangkapan skrin yang seseorang ambil pada bulan Julai.

Tetapkan retention_days pada hari pertama. Julatnya 1 hingga 365 dan lalainya 30, dan pemeriksaan yang lebih lama daripada tetingkap itu dicantas pada penghujung setiap larian dan tidak kembali. Projek dua belas bulan yang mahukan sejarahnya sendiri semasa penutupan mesti menyatakan 365 dari awal; tiada cara untuk memintanya pada bulan kesebelas. Rujukan endpoint ada dalam dokumentasi.

Berapa kosnya memantau pasaran seorang klien

Tiga credits bagi setiap sasaran yang diambil dan dibandingkan, iaitu harga track_changes, sama ada panggilan itu datang daripada REST atau MCP. Sasaran yang disekat dan tersilap tidak dicaj. Mencipta, mengemas kini, menjeda dan memadam monitor adalah percuma.

Dua puluh halaman pada jadual hari Isnin ialah empat atau lima pemeriksaan dalam tetingkap 30 hari, jadi 240 hingga 300 credits. Sepuluh klien dengan corak itu kekal di bawah 3,000 credits sebulan antara mereka semua. Tiada bayaran ikut pengguna dan tiada had berapa banyak halaman yang boleh anda pantau, dan itu cerita lain.

Kesimpulan yang berbaloi diamalkan ialah keluasan itu murah dan kekerapan itu tidak, jadi pantau lebih banyak halaman tetapi kurang kerap. Halaman kerjaya pesaing yang diam-diam mengiklankan jawatan account executive di Munich memberitahu anda lebih banyak tentang dua suku mereka yang seterusnya berbanding halaman harga mereka, dan halaman itu berubah mungkin dua kali setahun.

Apa yang ia tidak akan buat

• Tiada paparan untuk klien. Satu akaun, satu kunci, tiada log masuk bagi setiap klien dan tiada sempadan capaian antara monitor. Apa yang klien lihat ialah apa yang anda hantar kepada mereka.
• Ia tidak menyimpan data hubungan atau firmografik. Ia membaca halaman yang anda tunjukkan kepadanya, di atas apa jua pangkalan data yang sudah digunakan oleh kerja penyelidikan anda. Ia bukan Apollo atau ZoomInfo, dan ia tidak berpura-pura menjadi satu.
• robots.txt sentiasa dipatuhi, tanpa sebarang pengecualian. Laluan yang dilarang melaporkan ROBOTS_DISALLOWED pada setiap pemeriksaan dan tidak pernah dicaj untuknya.
• Sekurang-kurangnya lima minit antara larian, yang menjadikannya alat harian dan mingguan. Itu pun memang irama sesebuah laporan.

Jika yang anda mahukan ialah perubahan itu dihalakan ke CRM atau ke sebuah saluran dan bukannya ditulis ke dalam dokumen, bahagian webhook ada di sini.

Mula percuma dengan 1,000 credits, lebih kurang dua bulan pemantauan harian lima halaman bagi seorang klien, atau buka papan pemuka monitor dan baca satu pemeriksaan sebenar sebelum anda menulis sebarang kod.