Telegram neden hâlâ ilginç bir hedef?
Telegram’a dışarıdan bakan biri için “bir mesajlaşma uygulaması” deyip geçmek kolay. Ama işin aslı bambaşka. Mesela kamuya açık kanallar söz konusu olduğunda ortada bayağı zengin bir veri katmanı var: mesajlar, görseller, öne çıkan paylaşımlar, görüntülenme sayıları, reaksiyonlar… Sadece metin değil yani; bir kanalın nabzını tutmak için gereken ipuçlarının tamamı orada duruyor, sizi bekliyor.
Geçen ay İstanbul’da bir haber akışını takip ederken public bir Telegram kanalının ne kadar düzenli arşiv tuttuğunu görünce şaşırdım açıkçası. 2024 Kasım’ında yaptığım küçük testte şunu — en azından ben öyle düşünüyorum — fark ettim: aynı içerik bazı platformlarda kaybolup giderken Telegram’da daha derli toplu kalıyor, sanki biri özenle etiketleyip raflamış gibi. Bu da onu OSINT çalışanlar, araştırmacılar. Rekabet analizi yapan ekipler için epey cazip hale getiriyor — belki de beklenenden çok daha cazip.
Gel gelelim… “kolay” kelimesine fazla güvenmemek lazım burada. Evet, Telegram web önizlemesi ilk bakışta sade görünüyor, hatta aldatıcı derecede sade. Ama küçük bir CSS seçiciyi yanlış aldığınız anda ya eksik veri çekiyorsunuz ya da çöp gibi yarım JSON üretiyorsunuz. Ben bunu 2023 yazında kendi denememde bizzat yaşadım; iki saatlik uğraşın sonunda sorun meğer tek satırlık bir selector hatasıymış. Klasik.
Çok konuştum, örnekle göstereyim.
İki yol var: Web önizlemesi mi, API mi?
Public Telegram kanallarından veri almak için kabaca iki yol var. Birincisi herkesin elinin altında olan web önizlemesi. İkincisi ise daha ağır ama daha güçlü olan API tabanlı yaklaşım. İkisi de işe yarıyor — ama aynı soruna çözüm değiller, bunu baştan söyleyeyim.
Web önizlemesi “hızlıca bakıp çıkayım” diyenler için iyi bir seçenek. Giriş yapmadan erişiliyor ve çoğu durumda HTML doğrudan geliyor; yani tarayıcı açıp JavaScript’in yüklenmesini beklemenize gerek yok. Bu taraf bana hep eski usul katalog okur gibi geliyor: raflar belli, etiketler belli, ne alacağınızı az çok görüyorsunuz zaten.
Şimdi gelelim işin can alıcı noktasına.
Size bir şey söyleyeyim, API tarafıysa başka bir ligde oynuyor. Mesaj geçmişi daha geniş, medya dosyaları daha (belki yanılıyorum ama) erişilebilir ve ilişkilendirme katmanı çok daha derin. Fakat bunun da bedeli var tabi: kimlik doğrulama süreci, telefon numarası gereksinimi ve çeşitli kurulum dertleri… Açık konuşayım, hızlı prototip için bazen fazla ağır kaçıyor bu seçenek.
Web önizlemesinden veri çekmek nasıl çalışıyor?
Mantık oldukça düz aslında. t.me/s/kanaladi adresine gidiyorsunuz, sayfanın HTML’ini çekiyorsunuz ve içindeki mesaj bloklarını ayrıştırıyorsunuz. Ekran görüntüsüyle uğraşmıyorsunuz; ham DOM ile konuşuyorsunuz. Bu da işi epey hafifletiyor.
Bunu biraz açayım.
Ben bu yöntemi ilk kez bir kripto duyuru kanalında test ettiğimde — Ankara’da ev ofisimdeydi, sabahın erken saatleriydi — beklediğimden çok daha temiz sonuç aldım (en azından benim deneyimim böyle). Mesaj metni geldi, tarih geldi, görüntülenme sayısı geldi… hatta bazı durumlarda forward bilgisi bile düzgün çıktı. Fena değil yani, gerçekten fena değil.
Aşağıdaki örnek yapı işinizi başlatmak için yeterince net: Amazon deposunda bir ölüm: Güvenlik soruları yeniden masada yazımızda bu konuya da değinmiştik.
import httpx
from bs4 import BeautifulSoup
async def scrape_telegram_channel(channel_name: str):
url = f"https://t.me/s/{channel_name}"
async with httpx.AsyncClient() as client:
response = await client.get(url, headers={
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
})
soup = BeautifulSoup(response.text, "lxml")
messages = []
for widget in soup.select(".tgme_widget_message_wrap"):
message = widget.select_one(".tgme_widget_message")
if not message:
continue
msg_data = {
"id": extract_message_id(message),
"text": extract_text(message),
"date": extract_date(message),
"views": extract_views(message),
"reactions": extract_reactions(message),
"media": extract_media(message),
}
messages.append(msg_data)
return messagesDikkat etmeniz gereken seçiciler
- .tgme_widget_message_text — mesaj metni
- .tgme_widget_message_date time — tarih bilgisi
- .tgme_widget_message_views — görüntülenme sayısı — ciddi fark yaratıyor
- .tgme_widget_message_forwarded_from — ileri yönlendirme kaynağı (bu kritik)
- .tgme_widget_message_photo_wrap — fotoğraf kapsayıcısı
- .tgme_widget_message_video — video öğesi
Şöyle söyleyeyim, Lafı gevelemeden söyleyeyim: en sık patlayan nokta sadece seçiciler değil. Bazen encoding yüzünden Türkçe karakterler paramparça (söylemesi ayıp) geliyor, bazen sunucu boş cevap dönüyor gibi davranıp aslında yarım HTML gönderiyor — ve siz bunu ancak saatler sonra fark ediyorsunuz. O yüzden parser yazarken biraz sabır, biraz da şüphecilik gerekiyor.
Peki pagination meselesi?
Küçük bir detay: İşin can sıkıcı kısmı burada başlıyor. Gerçekten can sıkıcı.
Web önizleme size bütün geçmişi tek seferde vermiyor; genelde son mesajları gösteriyor ve eski kayıtlara ulaşmak için ek adımlar gerekiyor. Kullanıcı deneyimi açısından güzel tasarlanmış, bunu teslim edelim — ama veri toplama açısından bakınca biraz cimri davranıyor diyebilirim.
Küçük bir startup için bu belki kabul edilebilir. Siz son 50-100 mesajla trend okumaya çalışıyorsunuzdur muhtemelen. Ama enterprise seviyede çalışan bir ekipseniz ve regülasyon takibi ya da marka izleme yapıyorsanız bu sınırlılık hemen göze batıyor (ciddiyim). Kağıt üstünde süper görünse de pratikte eksik kalıyor — bazen ciddi biçimde eksik.
Benzer bir problemi 2024 Şubat’ında İzmir’de yürüttüğümüz ufak bir sosyal dinleme projesinde bizzat gördüm. İlk kurduğumuz scraper yalnızca güncel postları alıyordu; müşteri ise üç haftalık geriye dönük kıyas istiyordu. E sonra? İşte o noktada pagination desteği olmadan hiçbir şey ilerlemiyor, sıfır. Daha fazla bilgi için Xbox Game Pass pahalı mı oldu? Microsoft’un zor denklemi yazımıza bakabilirsiniz.
| Yaklaşım | Artıları | Eksi tarafı |
|---|---|---|
| Web önizlemesi | No login, hızlı kurulum, basit HTML ayrıştırma | Sınırlı geçmiş, eksik medya detayları |
| API / Telethon | Tam veri erişimi, uzun tarihçe, daha fazla kontrol | Kurum setup’ı zorlayabilir, kimlik doğrulama gerekir |
| Karma model | Hız + derinlik dengesi sağlar | Mimarisi biraz karışır |
Nerede hata yapılıyor? En yaygın tuzaklar
Bence en büyük hata şu: insanlar Telegram’ı sıradan bir blog sayfası gibi ele alıyor. Değil işte. Mantıklı değil mi? Sayfa statik gibi görünse de bazı parçalar zamanla değişebiliyor ve içerik tipine göre farklı bloklar ortaya çıkabiliyor — bazen hiç beklemediğiniz yerden.
Bir diğer tuzak da hız yönetimi yokluğu. Public erişim var diye üst üste istek yağdırırsanız kısa süre içinde tutarsız sonuçlar almaya başlarsınız. Ben bunu geçen yıl kendi testimde yaşadım; beş dakika boyunca sorunsuz çalışan script altıncı dakikada garip biçimde boş liste döndürdü. Meğer çok agresif bir istemci kullanmışım. Hmm, en basit hatalar böyle geliyor işte. Daha fazla bilgi için Nylas Audit Konfigürasyonu: Log Ayarlarını Anında Görün yazımıza bakabilirsiniz.
Bir de medya alanını hafife alanlar var ki onlara ayrı not düşmek lazım. Fotoğraf linki başka yerde olabiliyor, video gömülü ayrı bir yapıdan gelebiliyor veya paylaşılan dosya aslında belge. Siz onu düz metin sanıyorsunuz… Böyle ince ayrıntıları atlarsanız raporunuz cılız kalır — ne kadar güzel dashboard kurarsanız kurun.
Telegram scraping’de başarıyı belirleyen şey “veriyi çekebilmek” değil; veriyi tutarlı biçimde normalize edebilmektir.
Kendi pratiğimden birkaç kısa not
İnanın, Editör masasında bu konuyu görünce dayanamadım, küçük bir deneme yaptım. Telgraf vari akışların neden bu kadar popüler olduğunu anlamak aslında zor değil; özellikle finans ve kripto kanalları günlük gürültüye rağmen canlı kalabiliyor, insanlar oraya dönüyor. Neden? Çünkü içerik kaybolmuyor.
Bazı projelerde ben önce web preview ile başlıyorum — hızlı geri bildirim veriyor, ne işe yarayıp yaramayacağını erken anlıyorsunuz. Sonra ihtiyaç büyüyünce API’ye geçiyorum. Bu kademeli yaklaşım bana hep mantıklı geldi; önce düşük maliyetli doğrulama yapıyorsunuz, sonra ciddi mimariye oturtuyorsunuz. Tersini yapanları gördüm; ilk günden API kurulumuna giren ekipler haftalarca setup’ta kayboldu.
Küçük ekipler ne yapmalı?
Tek kişi ya da iki kişilik bir ekipseniz işi fazla karmaşıklaştırmayın. Gerçekten. Önce public kanallardan sınırlı veri alın, sonra hangi alanların gerçekten kritik olduğuna bakın — çünkü her şeyi toplamaya çalışmak çoğu zaman sizi yorar ve dashboard’unuz bir süre sonra anlamsız veri çöplüğüne döner. Bu kadar mı? Evet, bu kadar.
Büyük kurumlar neyi farklı yapmalı?
Kurum tarafında loglama, tekrar deneme politikası, rate limit yönetimi ve şema versiyonlama şart oluyor — bunlar olmadan dün çalışan pipeline bugün sessizce bozuluyor ve siz saatlerce neyin yanlış gittiğini anlayamıyorsunuz. En sinir bozucu senaryo bu zaten. Ben kurumsal projelerde “sessiz hata” görmeye hiç tahammül edemiyorum açıkçası; en azından bağıra bağıra bozulsun, nerede patladığını görelim.
Daha sağlam bir mimari kurmak mümkün mü?
Tabi mümkün. Hatta doğru kurgulanırsa gayet temiz olur — şaşıracaksınız belki ama karmaşık görünen şey aslında üç katmana sığıyor.
Web preview’den gelen veriyi hızlıca alıp normalize ediyorsunuz, ardından gerekirse eksik tarihçe için API katmanına yöneliyorsunuz (en azından benim deneyimim böyle). Bu hibrit yapı özellikle araştırma ekiplerinde bayağı işe yarıyor; hız ile derinliği aynı anda elde edebiliyorsunuz, ikisinden birini feda etmek zorunda kalmıyorsunuz (ilk duyduğumda inanamadım)
Her şey tek parça olmak zorunda değil. Bazen tam tersine parçalı sistem daha sağlıklı çalışıyor — özellikle ekip büyüdükçe. Farklı kullanım senaryoları ortaya çıktıkça bu modüler yapının değeri çok daha net anlaşılıyor.
- İlk katman: public HTML çekimi
- İkinci katman: schema validation / temizlik (bu kritik)
- Üçüncü katman: gerektiğinde API ile zenginleştirme
Sıkça Sorulan Sorular
Telegram kanal kazıma yasal mı?
Eriştiğiniz kanal kamuya açıksa teknik olarak veri çekmek mümkün ama kullanım amacınız önemlidir.Telif,gizlilik ve yerel mevzuat konularını ayrıca değerlendirmek gerekir.Kurumsal kullanımda hukuk ekibine danışmak iyi fikirdir.
T.me/s/ adresi her kanalda çalışır mı?
>
Kamuya açık çoğu kanalda çalışır,ama gizli ya da kısıtlı kanallarda çalışmaz.Ayrıca kanal sahibi görünürlüğü değiştirebilir;bu yüzden yönteminiz tek başına yeterince güvenilir olmayabilir.
Sadece Python ile yapmak yeter mi?Küçük işler için evet,Python gayet yeterlidir.httpx,BeautifulSoup ya da lxml ile hızlıca başlanır.Ama ölçek büyürse kuyruk sistemi,retry politikası ve loglama eklemek şart olur.
Neden API yerine web önizlemesini tercih edeyim?Daha az kurulum istediği için tercih edebilirsiniz.Kimlik doğrulama yoktur,başlangıç barajı düşüktür.Yine de uzun tarihçe veya gelişmiş ilişki verileri lazımsa API tarafına geçmeniz gerekir.
Kaynaklar ve İleri Okuma
Kaynaklar ve İleri Okuma
Bazı yazılarımızda benzer veri toplama ve altyapı konularına da değindik; mesela AWS VPC’yi Terraform ile Kurmak: Laboratuvardan Gerçeğe, Apache Arrow Neden Önemli: Veri Taşımanın Gizli Vergisi, İçeride Yapay Zekâ Ürününü Doğru Yayına Almak Sakin Plan.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
