Mobil Uygulamadan Veri Nasıl Toplanır?

Uygulama scraping'i ekran okumak değildir. Sürüm değişiklikleri, konum ve dil parametreleri ve kimlik problemi toplamayı nasıl şekillendiriyor?

Mobil uygulama veri toplama, ekrandaki yazıyı okumak değildir. Uygulamanın kendisi de bir istemcidir: gösterdiği her fiyatı, her listeyi ve her teslimat süresini bir servisten ister ve gelen cevabı çizer. Toplamanın işi ekranı taklit etmek değil, o cevabı anlamaktır.

Bu ayrım pratikte her şeyi belirliyor. Ekranı okuyan bir yaklaşım, arayüz her değiştiğinde kırılır ve gördüğü şeyle sınırlı kalır. Servis katmanıyla çalışan bir yaklaşım, ekranda hiç gösterilmeyen alanlara da erişir — stok adedi, kampanya kimliği, sıralama skoru gibi kararı asıl belirleyen alanlara.

İki yaklaşım ve maliyetleri

Arayüz otomasyonu. Gerçek ya da sanal bir cihazda uygulamayı çalıştırıp ekranı gezmek. Kurulumu sezgisel, ölçeklenmesi pahalı: her gözlem bir cihaz-saniyesi tüketir, tek bir tasarım değişikliği tüm akışı bozar ve toplanan veri ancak ekranda gösterilen kadar zengin olur.

Servis katmanı. Uygulamanın konuştuğu arayüzü anlamak ve veriyi oradan yapılandırılmış biçimde almak. Kurulumu daha zahmetli, ölçeklenmesi kıyaslanamayacak kadar ucuz ve veri baştan tiplenmiş gelir.

Gerçek sistemlerde ikisi birlikte kullanılır. Servis katmanı hacmi taşır; arayüz otomasyonu doğrulama için tutulur — çünkü nihayetinde ölçmek istediğiniz şey kullanıcının gördüğü sayıdır ve o sayının doğruluğunu ancak ekranda kontrol edebilirsiniz.

Sözleşme değişir, kimse haber vermez

Web scraping'de bir sayfa yapısı değiştiğinde bozulma genellikle gürültülüdür: seçici tutmaz, alan boş gelir, hata sayacı artar. Uygulama tarafında bozulma sessizdir. Bir alan yeniden adlandırılır, bir kampanya tipi yeni bir kodla döner, bir liste varsayılan olarak kısalır — ve toplama çalışmaya devam eder, sadece artık başka bir şey ölçüyordur.

Bunun tek panzehiri şema doğrulamasıdır: her cevabın beklenen alanları, tipleri ve makul aralıkları karşılayıp karşılamadığının alan bazında kontrol edilmesi. Fiyatın sıfır gelmesi bir hata değil, geçerli bir sayıdır; onu hata yapan şey, dün on beş gelen alanın bugün sıfır gelmesidir. Aynı disiplini tek bir scraper neden yetmez yazısında toplama motorları için anlatmıştık.

Uygulama sürümleri bu problemi katmanlar. Kullanıcıların bir kısmı eski sürümde kalır, servis her ikisine de cevap verir ve iki sürüm aynı soruya farklı yanıt döndürebilir. Toplamanın hangi sürümü temsil ettiği yazılı bir tercih olmalıdır, kazara oluşan bir durum değil.

Konum, dil ve cihaz birer parametredir

Uygulama tarafında aynı istek, farklı koordinat, farklı dil ya da farklı platformla gönderildiğinde farklı cevap döner. Bu bir ayrıntı değil, kapsam tanımının kendisidir.

Dolayısıyla "şu uygulamayı izliyoruz" cümlesi eksiktir. Kapsam, uygulama ile bölge ve dil çiftlerinin kümesidir; bir platformu on şehirde izlemek, o platformu izlemenin on katıdır ve toplama planı buna göre kurulur. Bölge eksenini sabitlemeyen bir seri, kaynak varsayılanını değiştirdiğinde sessizce başka bir şehri ölçmeye başlar.

Kimlik: uygulamadaki ürün, web'deki ürün değil

Uygulamanın kendi ürün kimlikleri vardır ve bunlar ne web sitesindekiyle ne de sizin katalogunuzdakiyle eşleşir. Aynı ürün farklı platformlarda farklı isim, farklı gramaj yazımı ve farklı paket tanımıyla durur.

Yani uygulama verisi, toplandıktan sonra eşleştirilmek zorundadır; yoksa karşılaştırma yapılamaz. Bunun nasıl çalıştığını ürün eşleştirme nasıl çalışır yazısında ayrıntısıyla ele almıştık. Uygulama kanalında iş biraz daha zor, çünkü elinizde çoğu zaman barkod yoktur; ad, gramaj, marka ve görsel üzerinden karar vermek gerekir.

Ölçek, sıklık ve boşluklar

Uygulama verisi hızlı bozulur. Teslimat süresi on dakikada, stok saat başında, sıralama gün içinde değişir. Bu yüzden toplama sıklığı bir tercih değil, verinin kullanılabilir olup olmamasının koşuludur.

Sıklık arttıkça kesintinin maliyeti de artar. Günde bir kez toplanan bir seride bir günlük boşluk fark edilmez; on beş dakikada bir toplanan bir seride aynı boşluk, ölçmeye çalıştığınız zirvenin tam ortasına denk gelir. Güncelliğin neden bir taahhüt olması gerektiğini veri tazeliği bir SLA'dır yazısında ele almıştık.

Sınırı nerede çiziyoruz

Uygulama tarafında toplanabilecek her şey toplanmaz. Çalıştığımız kapsam, uygulamanın herkese açık olarak sunduğu ticari bilgidir: fiyat, katalog, bulunabilirlik, teslimat koşulları, kampanya ve sıralama.

Bunun dışında kalanlar kapsam dışıdır. Kişisel veri toplanmaz; kullanıcı hesaplarının arkasındaki özel içerik hedeflenmez; bir platformun altyapısına yük bindirecek hacimler kullanılmaz. Bu sınırlar teknik bir kısıt değil, verinin kurumsal bir ortamda kullanılabilir olmasının önkoşulu — hukuk ekibinin savunamadığı bir veri seti, ne kadar zengin olursa olsun kullanılamaz.

Ham cevaptan veri setine

Toplama işin yarısı. Gelen cevap normalleştirilmeden, birimler ve para birimleri standartlaştırılmadan, kimlikler eşleştirilmeden ve zaman damgası standardına oturtulmadan analiz edilebilir hale gelmez. Bu dönüşümü genel olarak ham HTML'den yapay zekaya hazır veri setine yazısında anlatmıştık; uygulama kanalında girdi HTML değil ama adımlar aynı.

Sonuç

Mobil uygulama veri toplama, ekran okuma problemi değil sözleşme problemi. Şema doğrulaması olan, sürümü bilinçli seçilmiş, bölge ve dili kapsam tanımına yazmış, kimliği eşleştiren ve sınırını çizmiş bir toplama güvenilir veri üretir. Bunlar olmadan üretilen şey, düzenli aralıklarla toplanmış bir belirsizliktir.

Mobil uygulama veri toplama tarafında kurduğumuz sistem bu adımların üzerine oturuyor — teslimat ve hızlı ticaret uygulamalarından EV şarj istasyonlarının doluluk verisine kadar aynı mimari çalışıyor.