Loglama
Barkodla Yemek Kaydı: Türkiye'de Asıl Belirleyici Hız Değil, Veritabanı
Türkiye’de bir barkod tarayıp öğün kaydetmenin alışkanlığa dönüşüp dönüşmeyeceğini tarama hızı değil, veritabanının o barkodu doğru tanıyıp tanımadığı belirler. İki saniyede açılan bir kamera, karşısına çıkan ürünü bulamıyorsa ya da yanlış besin değeriyle eşleştiriyorsa, kullanıcı üçüncü denemeden sonra kaydı bırakır — hız orada bir işe yaramamış olur.
Neden hız değil, veritabanı belirleyici?
Barkod tarama özelliklerinin pazarlaması genelde bir sayıya odaklanır: “X saniyede tara.” Bu, gerçek deneyimin sadece ilk yarısı. İkinci yarı, taramanın ne bulduğudur. Bir ürünü 1 saniyede tarayıp “bulunamadı” ekranı görmek, aynı ürünü 3 saniyede tarayıp doğru sonucu görmekten çok daha kötü bir deneyimdir — çünkü ilkinde kullanıcı elle arama yapmak, tahmini bir porsiyon girmek ya da kaydı tamamen atlamak zorunda kalır. Loglama alışkanlığını öldüren şey genelde yavaşlık değil, bu “bulunamadı” anlarının sıklığıdır.
Türkiye özelinde bu, iki katmanlı bir problem: birincisi paketli ürünler katmanı (markette raftaki yoğurt, süt, atıştırmalık — bunların çoğunda barkod var ama global bir veritabanı bunları Amerikan/İngiliz ürünleri kadar iyi kapsamayabilir), ikincisi ise barkodu hiç olmayan katman — açık gıdalar. Simit, poğaça, esnaf lokantasından alınan bir kâse mercimek çorbası, ev yemeği bir güveç. Bunların hiçbirinde taranacak bir barkod yok; buradaki kalite testi barkod eşleşmesi değil, tarif/porsiyon tahmininin ne kadar gerçekçi olduğu.
Türkiye’ye özgü asıl test hangi ürünlerde ortaya çıkıyor?
Bir uygulamanın veritabanı kalitesini gerçekten test eden şey, Coca-Cola ya da Nutella gibi küresel markaları tanıyıp tanımadığı değil — bunları hemen hemen her veritabanı tanır. Asıl test, yerel/bölgesel bir markanın yoğurdunu, bir manav zincirinin kendi etiketli ürününü ya da yalnızca belirli bir bölgede satılan bir atıştırmalığı tanıyıp tanımadığıdır. Bu ürünler küresel bir şirketin ABD merkezli veri toplama sürecine hiçbir zaman girmemiş olabilir.
Burada referans noktası olarak Sağlık Bakanlığı’nın yayınladığı Türkiye Beslenme Rehberi (TÜBER) 2022 faydalı bir çerçeve sunuyor: rehber, Türkiye’ye özgü beslenme örüntülerini ve besin gruplarını resmî olarak tanımlıyor. İyi bir gıda veritabanı, bu yerel örüntülerle (ekmek/bulgur ağırlıklı karbonhidrat kaynakları, süzme peynir gibi yerel süt ürünleri, zeytinyağlı sebze yemekleri) uyumlu porsiyon ve besin değeri varsayımları kullanmalı — Amerikan porsiyon standartlarını olduğu gibi kopyalamamalı.
Popüler olmak, doğru olmak anlamına gelir mi?
Hayır — ve bunu gösteren doğrudan bir araştırma var. Griffiths, Harnack ve Pereira’nın 2018 tarihli, Public Health Nutrition dergisinde yayınlanan çalışması, beş popüler beslenme takip uygulamasının hesapladığı besin değerlerini, 24 saatlik hatırlama yöntemiyle toplanan referans verilerle karşılaştırdı. Enerji ve makro besinler için uygulamalar arasındaki korelasyon 0.73 ile 0.96 arasında değişti — yani en yaygın kullanılan uygulamalar arasında bile gözle görülür bir doğruluk farkı var. Kullanıcı sayısının büyüklüğü, veritabanının senin yediğin belirli ürün için doğru olacağının garantisi değil.
Bunun bir nedeni de veritabanının nasıl büyütüldüğü. MyFitnessPal gibi geniş küresel uygulamalar, kendi destek dokümantasyonlarında açıkça belirttiği gibi, veritabanlarını büyük ölçüde kullanıcı gönderimleriyle (member submitted) büyütüyor; bunlar yayınlanmadan önce sistematik olarak doğrulanmıyor, doğrulanmış (“verified”) girişler ayrı bir kategori olarak işaretleniyor. Bu bir eleştiri değil, sistemin kendi tasarımı — ama şu anlama geliyor: aynı ürün için birden fazla, farklı besin değerine sahip kayıt var olabilir, özellikle de o ürün belirli bir bölgede/pazarda satılıyorsa ve merkezi ekip tarafından hiç incelenmemişse.
Tarama hızı ile veritabanı kalitesi neyi ölçer, neyi ölçmez?
| Boyut | Sadece tarama hızı | Veritabanı kapsamı ve kalitesi |
|---|---|---|
| Ölçtüğü şey | Kamera açılıp sonucun gelme süresi | Sonucun doğru üründe, doğru besin değeriyle çıkıp çıkmadığı |
| Küresel markalarda performans | Genelde iyi | Genelde iyi |
| Yerel/bölgesel markalarda performans | Hıza etkisi yok | Belirleyici — kapsam burada test edilir |
| Açık gıda / ev yemeğinde davranışı | Barkod zaten yok, ölçemez | Porsiyon/tarif tahmininin gerçekçiliği önemli |
| Alışkanlığa etkisi | Marjinal (2 sn’lik fark hissedilmez) | Doğrudan — “bulunamadı” ekranı kaydı bıraktırır |
Cookrange bu problemi nasıl ele alıyor?
Cookrange’in barkod akışı, kamerayı ürüne çevirip birkaç saniye içinde bir sonuç göstermek üzerine kurulu — ama tasarımın asıl odağı, sonucun küresel ve kullanıcı katkılarıyla büyüyen bir veritabanı olan Open Food Facts’a karşı eşleştirilmesi ve besin değerinin (protein/karbonhidrat/yağ dahil) doğru porsiyon üzerinden gösterilmesi. Bu veritabanı kapalı bir katalog değil, kullanıcı katkılarıyla büyüdüğü için, belirli bir yerel ya da bölgesel ürünün kapsanıp kapsanmadığı, o ürünü daha önce başka birinin girip girmediğine bağlı — bu yazının konusu olan “bulunamadı” boşluğu da tam olarak bu yüzden oluşuyor. Beslenme ve planlama sayfası bu akışın öğün planına nasıl bağlandığını, nasıl çalışır sayfası ise uçtan uca deneyimi anlatıyor.
Kendi uygulamanı değerlendirirken ne sormalısın?
Bir sonraki kalori takip uygulamasını seçerken sorulacak soru “ne kadar hızlı tarıyor” değil, şunlar olmalı: sık aldığım yerel bir ürünü doğru buluyor mu? Açık gıda/ev yemeği için makul bir tahmin sunuyor mu, yoksa beni tamamen elle girişe mi bırakıyor? Bir eşleşme yanlışsa düzeltmek kolay mı, ve bu düzeltme veritabanına geri besleniyor mu? Bu sorulara verilen cevap, iki saniyelik tarama süresinden çok daha fazla şeyi belirliyor.
“Aynı ürün, iki farklı kalori değeri” sorunu neden oluyor?
Yaygın bir gıda takip şikayeti şudur: aynı barkodu iki kişi taradığında, ya da aynı kişi aynı ürünü iki farklı zamanda taradığında, farklı kalori/besin değeri sonuçları çıkabiliyor. Bunun nedeni genelde kötü niyet değil, veritabanının yapısı: bir ürün paketi zamanla formülünü değiştirebilir (üretici gramaj veya içerik güncelleyebilir), aynı ürünün farklı bölgesel/ambalaj varyantları aynı barkod altında karışabilir, ya da bir kullanıcı girişi baştan yanlış girilmiş olabilir ve kimse fark etmediği için öylece kalabilir. İyi bir veritabanı bu sorunu tamamen ortadan kaldıramaz — hiçbiri kaldıramaz — ama bir hatayı bildirmenin kolay olması ve bildirilen düzeltmenin gerçekten veritabanına yansıması, kötü bir günlük deneyimle iyi bir deneyim arasındaki farkı yaratıyor.
Bu, barkod veritabanı değerlendirirken gözden kaçan bir kriter: “Bu uygulamada bir ürün girişini düzeltebiliyor muyum, ve düzeltmem gerçekten işe yarıyor mu?” sorusu, “kaç milyon ürünü var” sorusundan çoğu zaman daha belirleyici.
Restoran ve esnaf lokantası yemekleri neden ayrı bir zorluk?
Paketli üründen sonra, Türkiye’de gıda takibinin en çok kırıldığı ikinci alan dışarıda yenen yemekler. Bir esnaf lokantasından alınan bir kâse mercimek çorbası ya da ev usulü bir güveç, ne standart bir porsiyon büyüklüğüne ne de tek bir tarife sahip — aynı yemek bir lokantadan diğerine, hatta aynı lokantada bir günden diğerine farklı hazırlanabilir. Burada veritabanı kalitesi, tek bir “doğru” sayı bulmak değil, makul bir aralık içinde kalan bir tahmin sunabilmek anlamına geliyor. İyi bir uygulama bunu açıkça belirtir (“tahmini değer”) ve kullanıcının porsiyonu/malzemeleri ayarlamasına izin verir; kötü bir uygulama ise sahte bir kesinlik hissi vererek tek bir sayı üretir ve kullanıcı bu sayının aslında bir tahmin olduğunu hiç fark etmez.
Sık sorulan sorular
Barkodu olmayan bir ürünü (simit, ev yemeği) nasıl kaydetmeliyim? Barkodsuz ürünlerde asıl kriter, uygulamanın tarif/porsiyon tahmini sunup sunmadığı — örneğin bir kâse mercimek çorbası için makul bir varsayılan porsiyon ve besin değeri önerip önermediği. Bu, barkod eşleşmesinden tamamen farklı bir mekanizma ve veritabanı kalitesinin ikinci, en az barkod kadar önemli bir boyutu.
Küçük bir yerel marka hiç veritabanında yoksa ne olur? Bu durumda iyi bir uygulama, seni tamamen elle girişe bırakmak yerine, en yakın benzer ürünü öneren bir arama deneyimi sunmalı; uzun vadede asıl fark, bu “bulunamadı” anının ne sıklıkta yaşandığı ve ne kadar kolay atlatıldığında ortaya çıkıyor.
Barkod veritabanı zamanla kendiliğinden mi iyileşiyor? Bir veritabanının büyümesi, kullanım hacmine ve düzeltme geri bildirimlerinin nasıl işlendiğine bağlı; bu, tek seferlik bir “tamamlanmış” durum değil, sürekli devam eden bir süreç. Bu yüzden bir uygulamayı değerlendirirken bugünkü kapsamı kadar, hata bildirimlerine nasıl yanıt verdiğine de bakmak makul.
Sonuç
Barkod tarama, loglamayı kolaylaştırmak için var — ama kolaylaştırdığı şey yalnızca “tarama anı” değil, tüm kayıt alışkanlığı. Hız, ilk izlenimi oluşturur; veritabanının senin gerçekte yediğin şeyleri (özellikle yerel ve açık gıdaları) ne kadar iyi tanıdığı ise alışkanlığın üçüncü haftaya kadar sürüp sürmeyeceğini belirler. Cookrange şu anda v0.9.6 dahili alfa aşamasında; erken erişim için bekleme listesine kaydolabilir, sık sorulan sorular için SSS sayfasına bakabilirsin.