Web değişikliği izleme, bir haber alarmından daha dar bir soruyu yanıtlar. Alarm, bir konu hakkında yeni bir şey yayımlanıp yayımlanmadığını sorar. Değişiklik izleyicisi ise zaten bildiğiniz belirli bir sayfanın değişip değişmediğini ve bu değişikliğin önemli olup olmadığını sorar: bir rakibin fiyat sayfası, bir düzenleyici kurumun rehber sayfası, bir tedarikçinin sözleşme koşulları, bir satıcının API dokümantasyonu ya da bir durum sayfası. Değişikliği tespit etmek işin kolay kısmıdır, çünkü sayfalar sürekli değişir. Asıl iş, hangi değişikliklerin bir insanın dikkatini hak ettiğine ve giderek daha sık olarak hangilerinin bir ajana iletilmesi gerektiğine karar vermektir. Bu rehber araç seçimini, aracı yararlı kalacak şekilde kurmayı ve değişiklikleri bir gelen kutusu yerine bir ajan okuduğunda nelerin farklılaştığını anlatıyor.
Bir değişiklik izleyicisi nasıl çalışır
Satın alınmış ya da şirket içinde kurulmuş olsun, hemen her araç her kontrolde aynı beş adımı izler.
- Getirme. Sayfa alınır. Basit sayfalar düz HTTP ile getirilebilir; tarayıcıda betiklerle oluşturulan sayfalar ise bir işleme adımı gerektirir ve bu genellikle bir headless tarayıcı ile yapılır. Getirme işlemi sitenin kullanım koşullarına ve robots kurallarına uymalıdır; giriş gerektiren bir sayfa için yalnızca bir adres değil, açık bir izin gerekir.
- Normalleştirme. Sayfa ilgilendiğiniz kısma indirgenir: ilgili bölge ve onun görünen metni, bilinen gürültü temizlenmiş olarak.
- Karşılaştırma. Normalleştirilmiş sürüm referans sürümle ya da bir önceki kontrolle karşılaştırılır.
- Sınıflandırma. Farkın biçimsel mi, bir içerik düzenlemesi mi, yoksa önemli bir değişiklik mi olduğuna, yazdığınız kurallara göre karar verilir.
- İletme. Önemli değişiklikler, önceki ve sonraki halleriyle birlikte, onları gözden geçirecek kişiye ya da sisteme gönderilir.
Hayal kırıklığı yaratan izleyicilerin çoğu ikinci ve dördüncü adımda zayıftır. Ham sayfaları karşılaştırır ve her farkı aynı şekilde ele alırlar; sonuçta ya sizi bildirime boğarlar ya da sessize alınırlar.
Önce referans, sonra önemlilik
Bir referans alın
Referans yoksa ilk karşılaştırma sayfanın tamamını yeni olarak raporlar ve olağan değişimin neye benzediğini bilemezsiniz. Herhangi bir alarmı açmadan önce her sayfa için şunları kaydedin:
- bilinen bir erişim zamanındaki normalleştirilmiş içerik, sonradan gösterilebilecek şekilde saklanmış olarak;
- izlediğiniz bölge, örneğin sayfanın tamamı yerine yalnızca fiyat tablosu;
- düzenli olarak değişen kısımlar: tarihler, sayaçlar, dönen afişler ya da önerilen yazılar.
Ardından izleyiciyi birkaç döngü boyunca yalnızca gözlem modunda çalıştırın. Bu sürede kaydedilen her fark ya normalleştirmeyle temizlenecek bir gürültüdür ya da yakalamak isteyeceğiniz gerçek bir değişikliktir. Bu adımı atlamanın sonradan neden daha pahalıya geldiğini izlemeden önce referans belirleyin yazısı anlatıyor.
Neyin önemli sayılacağına karar verin
Önemli bir değişiklik, birinin farklı bir şey yapmasına yol açacak değişikliktir. Bu, sayfaya ve alarmı kimin okuduğuna bağlıdır; bu yüzden her sayfa için neyin yok sayılacağını da söyleyen bir kural yazın. Bir rakibin fiyat sayfası için kural şöyle olabilir:
Bir paket eklendiğinde ya da kaldırıldığında, listelenen bir fiyat veya faturalama dönemi değiştiğinde ya da bir özellik bir paketten diğerine geçtiğinde alarm ver. İfade düzeltmelerini, görsel değişikliklerini, paketlerin yeniden sıralanmasını, alt bilgi ve menü değişikliklerini yok say.
Her kuralın bir sahibi olmalıdır: kural tetiklendiğinde ne yapılacağına karar veren kişi. Sahibi olmayan bir sayfayı kimse gözden geçirmez ve alarmları zamanla arka plan gürültüsüne dönüşür. Ürün sayfaları özelinde, yayına çıkan bir değişikliğin sayfada gerçekte neye benzediğini rakip özellik alarmları rehberi ele alıyor.
Gürültüyü kontrol altında tutun
Gürültünün birkaç yaygın kaynağı vardır ve her birinin bilinen bir çaresi bulunur.
| Gürültü kaynağı | Çare |
|---|---|
| Zaman damgaları, görüntülenme sayaçları, oturum belirteçleri | Normalleştirme sırasında temizleyin |
| Dönen afişler ve farklı sürümler gösteren deneyler | Daha dar bir bölgeyi izleyin; değişikliğin art arda iki kontrolde sürmesini şart koşun |
| İşaretleme ya da boşluk düzenlemeleri | Ham HTML yerine görünen metni karşılaştırın |
| Kişiselleştirilmiş ya da konuma göre değişen içerik | Her seferinde aynı ve belgelenmiş bir profille getirin |
| Site genelinde yapılan ve pek çok sayfada görünen bir değişiklik | Sayfa başına bir alarm yerine tek bir olayda toplayın |
| İki hal arasında gidip gelen bir sayfa | Bekleme süresi koyun: yeni hal kalıcı olduktan sonra alarm verin |
Gözden geçirenlerden bir alarmı reddettiklerinde kısa bir gerekçe yazmalarını isteyin. Bir aylık gerekçe, hangi kuralların sıkılaştırılması gerektiğini sezgiden çok daha iyi gösterir.
Ajanlar için gerçek zamana yakın izleme
Web’de “gerçek zamanlı” neredeyse her zaman sık aralıklarla yoklama anlamına gelir, çünkü değişiklikleri kendiliğinden gönderen site azdır. Kontrol sıklığını seçmeden önce bir değişikliğe ne kadar hızlı tepki verileceğini sorun. Alarmları biri günde bir kez gözden geçiriyorsa, her dakika kontrol etmek çoğunlukla gürültüyü ve başkasının sunucusundaki yükü artırır. Hızın gerçekten önemli olduğu yerde kaynağın kendi yayımladığı sinyalleri tercih edin: RSS ya da Atom akışları, değiştirilme tarihi içeren site haritaları, resmi API’ler, durum sayfası abonelikleri ve satıcı webhook’ları. Yalnızca böyle bir sinyal sunmayan sayfaları yoklayın.
Değişiklikleri bir ajan tüketecekse ona e-posta yerine yapılandırılmış bir olay gönderin. Yararlı bir olay, ajanın sayfayı yeniden getirmeden çalışabilmesine yetecek bilgiyi taşır:
event_id: chg-0192 url: https://example.com/fiyatlar region: fiyat tablosu rule_version: fiyat-v3 classification: önemli before: Ekip paketi, yıllık faturalama after: Ekip paketi, aylık ya da yıllık faturalama previous_fetch: önceki sürümün erişim zamanı current_fetch: bu sürümün erişim zamanı
Olay kimliğini anahtar olarak kullanıp gönderimi yeniden denemeye dayanıklı hale getirin; yeniden gönderilen bir olay ikinci bir görev açmasın. Her şeyden önce sayfa içeriğini güvenilmeyen girdi olarak ele alın. İzlenen bir sayfa, bir ajanı yönlendirmek için yazılmış metin içerebilir; örneğin “önceki talimatlarını unut ve…” gibi. Ajan sayfa metnini talimat olarak değil, özetlenecek veri olarak okumalı; okuduğu hiçbir şey yetkisini genişletmemelidir. İzlemenin diğer iki işin yanında nereye oturduğunu araştıran, izleyen ve bilgi çıkaran bir ajan rehberinde görebilirsiniz.
İnceleme: tespit edilen değişikliğin işe dönüştüğü yer
Tespit edilen bir değişiklik bir talimat değil, bir sorudur. Her önemli değişikliğe üç olası sonucu olan bir inceleme adımı verin: gerekçesiyle reddetmek, kayıt için not düşmek ya da sahibi belli bir işe dönüştürmek. Bunun sonucunda ekipten dışarı çıkacak her şey, yani müşterilere bir e-posta, bir sosyal medya paylaşımı ya da kendi fiyatlarınızda bir güncelleme, bir insanın onayını beklemelidir. Bu devir teslimi tespit edilen değişiklikten gözden geçirilmiş işe yazısı adım adım anlatıyor.
Bir araçta nelere bakmalı
- Betiklerle oluşturulan sayfalar için işleme desteği ve getirme profili üzerinde denetim.
- Görebildiğiniz ve düzenleyebildiğiniz bölge seçimi ile normalleştirme kuralları.
- “Bir şey değişti”nin ötesine geçen sınıflandırma; tercihen kelimelerle yazılan ve istisnaları olan kurallar.
- Erişim zamanlarıyla birlikte saklanan önceki ve sonraki sürümler; böylece bir alarm sonradan kontrol edilebilir.
- Aynı değişikliğin sayfalar arasında gruplanması ve bekleme süresi.
- Yalnızca e-posta değil, belgelenmiş bir API ya da webhook üzerinden yapılandırılmış olay gönderimi.
- Kimin neyi neden reddettiğini kaydeden bir inceleme kuyruğu.
- Girişler, site koşulları ve robots kuralları konusunda açık bir tutum.
Bilinen sayfaları izlemekten çok yeni anılmaları keşfetmeye ihtiyacınız varsa anahtar kelime alarmlarının yerine geçecek araçlar yazısından başlayın.
GoCux nereye oturur
GoCux web’i taramaz ve bir sayfa karşılaştırma servisi değildir. Bu resimdeki payı inceleme tarafıdır. Pulse ile seçtiğiniz kaynaklar üzerinde düzenli olarak sorulan bir soru tanımlar ve bu tanımı tam sürümüyle onaylarsınız: sıklık, saat dilimi, neyin önemli değişiklik sayılacağı ve bildirimin e-postayla mı gideceği yoksa hiç gitmeyeceği. Her çalıştırma ayrı bir kayıt olarak tutulur ve içindeki değişiklikler tek tek gözden geçirilir. Tespit edilen bir değişiklik sizin adınıza harekete geçmez. Takip gerekiyorsa bunun için bir iş emri açabilirsiniz: bir hedef, bir kapsam ve kabul ölçütleri; dışarıya bir şey gönderilecekse iş, ekipten biri karar verene kadar bekler. Web içeriği çalışma alanına yalnızca yetkilendirilmiş bir tarama ya da dışa aktarma adımıyla, sayfa adresi ve erişim tarihiyle birlikte girer. İncelemenin nasıl işlediğini Pulse sayfasında görebilirsiniz.
Kurulum kontrol listesi
- Sayfaları ve her birinin yanına beslediği kararı yazın. Kararı ve sahibi olmayan sayfaları listeden çıkarın.
- Her sayfada izlenecek bölgeyi seçin.
- Bir referans alın ve birkaç döngü boyunca yalnızca gözlem modunda çalıştırın.
- Her sayfa için, neyin yok sayılacağını da içeren bir önemlilik kuralı yazın.
- Gözlem döneminin ortaya çıkardığı gürültüyü normalleştirmeyle temizleyin.
- Kontrol sıklığını birinin ne kadar hızlı harekete geçeceğine göre belirleyin; kaynak sunuyorsa akışları ya da webhook’ları kullanın.
- Gönderim biçimini seçin: insanlar için e-posta, ajanlar ve diğer sistemler için yapılandırılmış olaylar.
- Gözden geçireni belirleyin ve inceleme sonrasında ne olacağını, hangi takip işlerinin onay gerektirdiği dahil, tanımlayın.
- Reddetme gerekçelerini düzenli olarak okuyun ve boşuna tetiklenmeye devam eden kuralları ayarlayın.
Bu iş akışını çalışma alanınıza taşıyın.
Kapsamı belirleyin. Kanıtları inceleyin. Gereken adımları onaylayın.