Michael Johnsonİki IG içerik üreticisini tek bir profil anlık görüntüsüne göre karşılaştırmak kolaydır; kimin düzenli olarak içerik paylaştığını ve hangi gönderilerin zaman içinde etkileşim aldığını anlamak ise daha zordur. Tek seferlik kontroller farklı yaşlardaki gönderileri birbirine karıştırır, manuel bir tablo da kısa sürede güncelliğini yitirir. Uygulanabilir çözüm, herkese açık medyaları düzenli olarak toplamak, her yanıtı ayrı bir gözlem olarak saklamak ve değişimleri kendi verileriniz üzerinden hesaplamaktır.
Aşağıda, aynı niş içindeki herkese açık hesapları haftalık olarak karşılaştırması gereken pazarlamacılar, analistler veya geliştiriciler için uygulanabilir bir yöntem yer alıyor. Verileri almak için jsonscraper'ın IG Scraper API'si kullanılıyor; zamanlama, normalizasyon ve geçmiş kayıtlarını saklama işlemlerini Python üstleniyor. Bu, profilleri ve rakip gönderileri izleme konusunun devamı niteliğinde: burada odak, karşılaştırmalı raporlamaya uygun, ortak bir gözlem modeli oluşturmaktır.
Önce tam olarak neyi karşılaştıracağınızı belirleyin
Görev genellikle geniş bir şekilde tanımlanır: “etkili içerik üreticilerini bulmak.” Teknik açıdan yararlı bir izleme için bunu ölçülebilir sorulara indirgemek gerekir: Gönderiler ne sıklıkla yayınlanıyor, hangi formatlar kullanılıyor, kontrol sırasında herkese açık kaç beğeni ve yorum görülüyor ve bu sayılar gönderi yayınlandıktan sonra nasıl değişiyor? Bu tür bir veri kümesi, hesapları elle incelemek üzere seçmeye veya karşılaştırmalı bir özet hazırlamaya yardımcı olur.
Herkese açık sayaçlar, isteğin yapıldığı andaki görüntülerdir. Bu nedenle mimarideki temel karar karmaşık bir model değil, değerle birlikte toplama zamanını da kaydetmektir. Her gece aynı medya hakkındaki bilgileri alıp önceki satırın üzerine yazarsanız, artışı hesaplamak için gereken geçmişi kaybedersiniz. Bunun yerine gözlemleri değiştirilemez şekilde saklayın: her gönderi ve toplama zamanı için bir satır.
Karşılaştırmayı aynı dönemlerle ve benzer gönderilerle sınırlandırın. Örneğin, ilk kez aynı takvim ayında fark edilen gönderilere bakabilir veya her anlık görüntüde gönderinin yaşını hesaba katabilirsiniz. Aksi takdirde dünkü video, etkileşim toplamak için daha az zamanı olduğu için eski bir gönderiden daha zayıf görünebilir.
İş akışı: istek, normalizasyon, geçmiş
En temel süreç dört adımdan oluşur: seçilen profillerin herkese açık medya listesini almak, yanıtı ortak bir şemaya dönüştürmek, satırları depolamaya yazmak ve programa göre rapor oluşturmak. IG Scraper API sayfası, parça parça gönderi almak için kullanılan kullanıcı rotası da dâhil olmak üzere temel adresi ve endpoint haritasını gösteriyor. Entegrasyondan önce her rotanın parametrelerini ve yanıt örneklerini Postman koleksiyonunda kontrol edin.
API'nin temel adresi https://ig.jsonscraper.com'dur. İlk kontrol için belgelerde, yayımlanan örnekte username, license_key ve cache_timeout parametreleriyle profil isteği gösteriliyor: GET /v1/user/by/username. Gönderileri almak için belirtilen rota GET /v1/user/medias/chunk'tır. Her rotanın kesin argümanlarını, devam alanlarını ve yanıt yapısını o isteğe ait belgelerden alın; bir rotanın şemasını diğerine taşımayın.
import os
import requests
BASE = "https://ig.jsonscraper.com"
KEY = os.environ["JSONSCRAPER_LICENSE_KEY"]
def get_profile(username: str) -> dict:
response = requests.get(
f"{BASE}/v1/user/by/username",
params={
"username": username,
"license_key": KEY,
"cache_timeout": 60,
},
timeout=30,
)
response.raise_for_status()
return response.json()
print(get_profile("example_account"))
Bu kısa örnek, belgelenmiş profil rotasını izler ve parametrelerin HTTP GET üzerinden nasıl gönderileceğini gösterir. Yayımlanmış örnekte cache_timeout=60 değeri bulunuyor; bu değeri yalnızca parametrenin desteklendiği rotalarda kullanın ve ayrıntıları belgelerden doğrulayın. Anahtarı koda veya tarayıcı uygulamasına değil, ortam değişkeninde saklayın.
Gönderileri almayı ekleyin
Profili doğruladıktan sonra medya listesine istek ekleyin. API sayfasında GET /v1/user/medias/chunk listeleniyor; sonucu işlerken belgelerde belirtilen parçalı alma mantığını kullanın. Parametre adlarını ve sayfalamanın bitiş koşulunu, rota adından tahmin etmek yerine Postman'daki bu isteğin güncel açıklamasından alın.
Aşağıdaki örnek, hazır bir endpoint sözleşmesi değil, taşıma çağrısı için bir iskelettir: çalıştırmadan önce params alanını belgelenmiş argümanlarla doldurun. Yanıt alındıktan sonra adaptör, yalnızca seçilen rotaya ait gerçek JSON ile doğrulanmış alanları okumalıdır.
def fetch_media_chunk(username: str, params: dict) -> dict:
query = {
**params,
"username": username,
"license_key": KEY,
}
response = requests.get(
f"{BASE}/v1/user/medias/chunk",
params=query,
timeout=30,
)
response.raise_for_status()
return response.json()
Ardından, yanıtı dahili biçime dönüştüren bir adaptör işlevi yazın. Analiz için sabit bir gönderi kimliği, yazar, bağlantı, yayın tarihi, medya türü ve erişilebilen herkese açık sayaçlar yararlı olabilir. Alan adlarını ve türlerini belgelerden ve JSON örneğinden doğrulayın. Bir metrik yoksa sıfır atamak yerine boş değer olarak saklayın: sıfır, ölçülen sayaç değerinin sıfır olduğunu; boş değer ise verinin bulunmadığını belirtir.
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# Anahtarları yalnızca seçilen endpoint'in JSON yanıtını doğruladıktan sonra belirtin.
return {
"username": username,
"media_id": item.get("DOCUMENTED_MEDIA_ID_KEY"),
"media_url": item.get("DOCUMENTED_MEDIA_URL_KEY"),
"published_at": item.get("DOCUMENTED_PUBLISHED_AT_KEY"),
"media_type": item.get("DOCUMENTED_MEDIA_TYPE_KEY"),
"likes": item.get("DOCUMENTED_LIKE_COUNT_KEY"),
"comments": item.get("DOCUMENTED_COMMENT_COUNT_KEY"),
"observed_at": observed_at,
}
Yer tutucu adları, belirli endpoint'in yanıtındaki kesin anahtarlarla değiştirin ve eşlemeyi kaydedilmiş bir JSON örneği üzerinde test edin. Böylece entegrasyon güncellenirken şema değişikliği fark edilir; örnek de varsayımsal alan adlarını doğrulanmış bir sözleşmeymiş gibi sunmaz.
Yalnızca güncel değerleri değil, gözlemleri saklayın
Bir prototip için CSV yeterli olabilir; düzenli kullanımda PostgreSQL, Supabase veya bir analitik veri deposu tercih edilebilir. Gözlem tablosunda username, media_id, published_at, observed_at, likes, comments ve ham JSON alanları bulunabilir. media_id ile observed_at çifti benzersiz bir anlık görüntü tanımlar. Ayrı bir profil tablosu, izlenen hesap listesini ve izlemeye eklenme tarihini saklar.
Ham yanıtı saklamak, hata ayıklama ve normalize edilmiş verileri yeniden oluşturma açısından yararlıdır. Saklama süresini projenin amacına ve kuruluşunuzun kurallarına göre sınırlandırın, tablolara erişimi denetleyin ve seçilen analiz için gerekmeyen bilgileri toplamayın. CRM ve doğrudan pazarlama faaliyetleri için geçerli hukuki dayanağı ayrıca belirleyin: verilerin teknik olarak herkese açık olması bu sorunu tek başına çözmez.
CREATE TABLE media_observations (
username TEXT NOT NULL,
media_id TEXT NOT NULL,
media_url TEXT,
published_at TIMESTAMPTZ,
observed_at TIMESTAMPTZ NOT NULL,
media_type TEXT,
likes BIGINT,
comments BIGINT,
raw_json JSONB,
PRIMARY KEY (media_id, observed_at)
);
Yanıt başarıyla doğrulandıktan sonra kayıtları toplu olarak ekleyin. Aynı görev yeniden çalıştırıldığında birincil anahtar birleşimi aynı anlık görüntünün yanlışlıkla yinelenmesini önler; uygulamada çakışmaları atlayan bir ekleme kullanabilirsiniz. Farklı bir zamanda yapılan yeni çalıştırma ayrı bir satır kaydeder ve zaman serisini sürdürür.
Sorunuza yanıt veren metrikleri hesaplayın
Paylaşım temposunu ölçen temel metrik, seçilen aralıkta hesaba ait benzersiz medya sayısıdır. published_at alanı varsa ve doğru biçimde tanımlandıysa bunu hesaplamak kolaydır. Herkese açık etkileşimlerdeki değişimi değerlendirmek için aynı media_id'ye ait iki gözlemi karşılaştırın: beğenilerdeki mutlak değişim, sonraki sayımdan önceki sayım çıkarılarak; göreli değişim ise bu farkın önceki değere bölünmesiyle bulunur. Aynı hesaplama yorumlar için de geçerlidir.
Önceki değer sıfırsa veya mevcut değilse göreli artış tanımlı değildir; mutlak farkı gösterin ve yüzde hesaplamak için bir başlangıç değeri bulunmadığını açıkça belirtin. Sayaçlar gözlemler arasında değişebileceği için raporda anlık görüntüler arasındaki süre ve son toplama zamanı yer almalıdır. Bu ayrıntılar, okuyucunun rakamları doğru yorumlamasına yardımcı olur.
def growth(previous, current):
if previous is None or current is None:
return {"delta": None, "rate": None}
delta = current - previous
rate = None if previous == 0 else delta / previous
return {"delta": delta, "rate": rate}
Hesapları, açıklanabilir ağırlıklar olmadan tek bir puana indirgemeyin. Uygulanabilir bir rapor genellikle gönderi sayısını, gönderi başına beğeni ve yorum medyanlarını, formatların dağılımını ve aynı yaş aralığındaki etkileşim değişimini birlikte gösterir. Medyan, tek bir sıra dışı gönderinin etkisini azaltır; gönderi sayısı ise karşılaştırmanın dayandığı örneklem büyüklüğünü belirtir.
Gönderi yaşı iki şekilde hesaba katılabilir. İlk yöntemde sayaçlar, örneğin medya ilk kez fark edildikten sonra eşit aralıklarla düzenli olarak kaydedilir. İkincisinde, yaklaşık aynı yaştaki gözlemler kullanılarak aynı zaman aralığına giren gönderiler karşılaştırılır. Zamanlanmış bir çalışma atlanırsa, gerçek aralığı zaman damgalarından hesaplamak yerine değişimi tam olarak bir günlük artış gibi göstermeyin.
Çalıştırmayı ve kalite kontrolünü otomatikleştirin
Veri toplamayı cron, GitHub Actions veya bir ETL düzenleyicisi üzerinden zamanlayın. Görev sırası basittir: hesap listesini okuyun, gerekli parçaları isteyin, HTTP durumunu ve yanıt yapısını kontrol edin, verileri normalize edin, anlık görüntüyü kaydedin ve çalıştırma günlüğü oluşturun. Her çalıştırmada işlenen hesapların ve medyaların sayısını, hataları ve süreyi kaydedin; bu, gerçek bir etkinlik değişikliğini veri toplama arızasından ayırt etmeye yardımcı olur.
Geçici hatalarda sınırlı sayıda yeniden deneme ve bekleme kullanın; hata yanıtı için bağlamı gizli anahtar olmadan kaydedin. İmleçlerle sonsuz döngüye girmeyin: durdurma koşulu, endpoint yanıtında belirtilen tamamlama şartlarına dayanmalıdır. Belgeler hız sınırları veya kullanım kuralları tanımlıyorsa sıklığı ve örneklem boyutunu bunlara göre ayarlayın.
cache_timeout parametresi, IG API sayfasında desteklenen rotalar için belirtilmiştir. Kısa süre içinde yinelenen bir istek yeni bir değer katmıyorsa önbellek yararlı olabilir; değişiklikleri izlemek için toplama aralığını analitik soruya göre seçin. Örneğin günlük bir anlık görüntü, aynı profillere belirli bir amaç olmadan sık sık yeniden istek göndermektense haftalık bir değerlendirmeye daha iyi yanıt verir.
Düzenli zamanlamayı etkinleştirmeden önce küçük bir örneklemle test edin. Bir yanıt örneği saklayın, kimlikleri ve tarihleri kontrol edin, normalize edilen alanları kaynak JSON ile karşılaştırın ve birkaç satırı elle doğrulayın. Eksik değerler, boş listeler ve beklenmeyen biçimler için testler ekleyin. API değiştiğinde bu kontroller, hafta sonunda tutarsız bir raporla karşılaşmaktan daha hızlı sorun bulmanızı sağlar.
Yapay zekâ burada ne işe yarar?
Yapay zekâ, hesaplanmış sonuçları kısaca açıklamak için son aşamada kullanılabilir. Modele ham arşivin tamamını değil, özetleri ve gönderi bağlantılarını iletin: örneğin haftalara göre medya sayısı, herkese açık etkileşimlerin medyanı ve belirli bir aralıkta en çok değişim gösteren gönderilerin listesi. Modelden gözlemleri ifade etmesini ve bunların elde edildiği kayıtların kimliklerini eklemesini isteyin.
Aynı kuralın tekrarlanabilir sonuç vermesi için metrik hesaplamalarını olağan kodda tutmak daha iyidir. Model, metinsel bir özet hazırlayabilir, açıklamaları önceden belirlenmiş temalara göre gruplayabilir veya elle kontrol edilmesi gereken sorular önerebilir. Tematik sınıflandırmada model etiketini kaynak açıklamadan ayrı saklayın ve sonraki değişikliklerin geçmişi fark edilmeden yeniden yazmaması için talimatın veya sınıflandırıcının sürümünü belirtin.
Otomatik raporu işe alım, sözleşme veya belirli bir kişiyi değerlendirme konusunda otomatik karara dönüştürmeyin. Herkese açık verileri sınırlı içerik analizi için kullanın ve özellikle iş kararlarını etkileyen sonuçları elle kontrol edin. Böylece izleme yararlı kalır ve ölçülebilir sayaçlarla yorumlar birbirinden ayrılır.
Sonuç nasıl görünür?
Birkaç veri toplama döngüsünden sonra her gönderinin ne zaman fark edildiğini, her gözlemde kaç etkileşim aldığını ve göstergelerin nasıl değiştiğini gösteren bir tablo oluşur. Haftalık bir özet şu pratik soruları yanıtlayabilir: Kim düzenli paylaşıyor, hangi formatlar daha sık kullanılıyor, karşılaştırılabilir anlık görüntüler arasında hangi gönderiler etkileşim kazanıyor ve güvenilir bir karşılaştırma için hangi hesaplarda henüz yeterli veri bulunmuyor?
Bu süreç, aralıklı manuel kontrolleri tekrarlanabilir bir araştırmayla değiştirmeye yardımcı olur. Nitel içerik analizinin yerini almaz: metrikler paylaşım sıklığını ve erişilebilen herkese açık etkileşimleri tanımlar; içerik anlamı, kitle ve markayla uyum ayrıca değerlendirilmelidir. Buna karşılık aynı zamanlama, saklanan geçmiş ve hesaplamaların açık mantığı bu değerlendirmeleri doğrulanabilir ve ekip için kullanılabilir hâle getirir.
Başlamak için IG Scraper API sayfasını açın, gönderi rotasının parametrelerini Postman belgelerinde kontrol edin, ardından bir test hesabında adaptörü uygulayıp ilk anlık görüntüyü kaydedin. Şema doğrulandıktan sonra zamanlamayı, hata kontrollerini ve seçilen metriklere göre raporlamayı ekleyin.