sellers.json Nedir? Yayıncı İçin Tedarik Zinciri Şeffaflığı

sellers.json, reklam sistemlerinin (SSP ve borsaların) yayımladığı, kendi üzerlerinden satış yapan tarafların kimliklerini açıklayan bir dosyadır. Site sahibinin kendi sunucusuna koyduğu dosya ads.txt'tir; sellers.json ise karşı taraftadır ve yayıncı onu düzenleyemez. Reklam geliri olan blog, haber ve içerik sitesi sahipleri için asıl değer, kendi ads.txt satırlarındaki kimliklerin karşı tarafta doğru bir kayda bağlanıp bağlanmadığını kontrol edebilmektir.

IAB Tech Lab'ın sellers.json sayfası (yeni sekmede açılır) bu dosyanın beklentisini açık yazar: SSP'lerin ve borsaların sellers.json dosyalarını alıcıların incelemesi için yayımlaması beklenir. Sayfada yayıncıya yönelik ayrı bir bölüm bulunmaz; yönlendirme SSP'lere ve alıcılara yapılır.

sellers.json kimin dosyasıdır

Bir yanlış anlama,sellers.json'u ads.txt'in ikinci bir kopyası saymaktır. İkisi aynı sorunun farklı yarılarını yanıtlar ve farklı kişilere aittir.

Yayıncının değil, reklam sisteminin dosyası

IAB sayfasına göre sellers.json, alıcıların doğrudan satıcı ya da aracı olan tarafların kimliklerini keşfetmesini sağlayan bir mekanizmadır. Dosyayı yayımlayan SSP ve borsalardır. Sizin sitenizde sellers.json'a bakmak anlamsızdır; dosya reklam sisteminin alan adında durur. Teknik şartnamede de bunun yeri belirtilir: bir ads.txt dosyasında listelenen her reklam sistemi ve bir SupplyChain nesnesinde başvurulan her reklam sistemi, kendi alan adının altında /sellers.json yolunda bir dosya yayımlamalıdır.

Dosyanın içinde ne var

IAB şartnamesinin 1.0 sürümüne (yeni sekmede açılır) göre dosyanın ana nesnesinde satıcıların listesi, sürüm bilgisi, isteğe bağlı olarak iletişim e-postası ve adresi ile TAG-ID ya da DUNS gibi tanımlayıcılar bulunur. Her satıcı kaydı bir satıcı kimliği (seller_id), bir tür (seller_type), isteğe bağlı bir gizlilik işareti, ad ve alan adı bilgilerini taşır. Şartname, her seller_id'nin yalnızca tek bir kuruluşu temsil edeceğini söyler; bir kuruluşun ise aynı reklam sisteminde birden fazla seller_id'si olabilir.

Dosya nerede ve nasıl yayımlanır

Şartnamede reklam sistemlerinin dosyayı kök alan adında ve gerektiğinde alt alan adlarında yayımlaması gerektiği, dosyaya HTTP ya da HTTPS ile "/sellers.json" yolundan ulaşılabilmesi ve yanıtın application/json içerik türüyle verilmesi gerektiği yazar. HTTPS tercih edilir. Tüketen sistemler dosyayı önbelleğe alabilir; önbellek yönergesi yoksa varsayılan geçerlilik süresi 7 gündür. Bu ayrıntılar yayıncının yapacağı bir iş değildir, ama bir kaydın neden hemen güncellenmediğini anlamaya yardım eder.

Not: Şartnamenin 1.0 sürümü Temmuz 2019 tarihlidir. IAB Tech Lab standartları güncelleyebilir; uygulamadan önce güncel sayfaya bakın.

ads.txt ve sellers.json: aynı zincirin iki yarısı

Zincirin görünür olması için iki tarafın kayıtları birbirini doğrulamalıdır. Yayıncı hangi şirketlere satış yetkisi verdiğini söyler, reklam sistemi de o şirketlerin kimlerle ilişkili olduğunu söyler.

Yetki ve kimlik ayrımı

IAB şartnamesi bu ayrımı şöyle çerçeveler: ads.txt, içerik dağıtıcılarının ve uygulama yayıncılarının belirli bir gösterim grubunu kimin satmaya yetkili olduğunu tanımlamasına izin vermiştir; ancak ads.txt, reklam platformundaki yayıncı hesap kimliklerinin kimlere ait olduğunu açığa çıkarmaya çalışmaz. sellers.json yayımlandığında, bir teklif isteğinin son satıcısının kimliği (ads.txt tarafından yetkilendirildiği varsayımıyla) keşfedilebilir. Bu cümle iki dosyanın birbirinin yerine geçmediğini, birbirini tamamladığını gösterir.

SupplyChain nesnesi ve düğümler

IAB sayfası SupplyChain nesnesini bir OpenRTB uzantısı olarak tanımlar. Nesne, bir teklif isteğini satan ya da yeniden satan tüm tarafların görülmesini sağlar ve ağırlıklı olarak her satış katılımcısı için bir düğümden oluşur. Alıcılar, SupplyChain nesnesindeki tanımlayıcıları sellers.json dosyalarıyla doğrulayabilir. Şartnamedeki seller_id açıklaması iki dosyayı bağlar: bu kimlik ads.txt dosyasında görünen kimlikle ve SupplyChain düğümlerinin sid alanıyla aynıdır.

ads.txt 1.1 ile gelen alan adı bildirimleri

IAB'ın ads.txt sayfası (yeni sekmede açılır) 1.1 sürümünün iki yeni değer eklediğini söyler: OWNERDOMAIN ve MANAGERDOMAIN. Bu değerler yayıncı tarafından bildirilir ve sellers.json üzerinden gösterilen satıcı ilişkilerindeki şeffaflığı artırır. Sayfa ayrıca ads.txt, app-ads.txt ve sellers.json dosyalarının GitHub'a taşındığını belirtir. Ayrıntılı kullanım için sayfa uygulama rehberine yönlendirir. ads.txt'nin yayıncı tarafındaki kurulumu için ads.txt nedir rehberine bakın. Orada anlatılan dosyanın karşı yarısı burada konu edilen sellers.json dosyasıdır.

Kayıt türleri: PUBLISHER, INTERMEDIARY ve BOTH

Her satıcı kaydının zorunlu bir türü vardır. Bu tür, sizin kaydınızın reklam sisteminde nasıl sınıflandığını gösterdiği için yayıncı açısından da anlamlıdır.

Üç tür ne anlama gelir

Şartnamedeki tanıma göre PUBLISHER, bu hesap üzerinden satılan envanterin adı geçen kuruluşa ait bir site, uygulama ya da başka bir ortamda olduğunu ve reklam sisteminin kuruluşa doğrudan ödeme yaptığını gösterir. INTERMEDIARY, envanterin adı geçen kuruluşa ait olmadığını ya da reklam sisteminin ona doğrudan ödeme yapmadığını belirtir. BOTH, ikisinin de aynı hesapta işlendiğini anlatır. Alan büyük küçük harf duyarsız okunmalıdır.

Gizlilik işareti ve geçiş satıcısı

is_confidential alanı varsayılan olarak 0'dır; 1 olduğunda satıcının kimliği gizlidir ve ad ile alan adı alanları bırakılabilir. Gizli de olsa tüm satıcıların listeye eklenmesi gerekir. is_passthrough alanı ise bir geçiş satıcısını, yani üst akıştaki tedarikçi ile envanteri tüketen taraf arasında kolaylaştırıcı olan bir tarafı işaretler. Şartname, geçiş satıcısı için tedarikçinin tüketici platformda hesap kontrolüne sahip olması gerektiğini anlatır. Bu iki alan yayıncının düzenlediği bir şey değildir; hesabınızın nasıl sınıflandığını anlamaya yardım eden ayrıntılardır.

DIRECT ve RESELLER kayıtları hakkında kaynak ne söylüyor

ads.txt satırlarındaki DIRECT ve RESELLER ilişki türleri sellers.json konuşulurken akla gelir, ama IAB sayfaları ve AdSense yardım sayfası bu terimleri tanımlamaz. AdSense'in ads.txt yardım sayfası (yeni sekmede açılır) yalnızca AdSense hesabından kopyalanacak örnek bir satırda DIRECT sözcüğünü gösterir; anlamını açıklamaz, RESELLER'dan hiç söz etmez. Dolayısıyla DIRECT ya da RESELLER ile sellers.json'daki PUBLISHER ve INTERMEDIARY türleri arasında birebir bir eşleme kurmak bu belgelerle desteklenmez. Eşleştirme ihtiyacınız varsa reklam ortağınızın kendi belgelerine bakın.

Alıcı tarafından bakış: dosya neden var

Yayıncı olarak dosyayı okumak, dosyanın aslında kimin için yazıldığını bilince daha anlamlı hale gelir. IAB sayfası ve şartname, hedef kitleyi reklam sistemleri ve alıcılar olarak tanımlar: tüm tarafların anlaşıldığı şeffaf bir pazaryerinden hem satıcılar hem alıcılar yarar sağlar.

Teklif isteğinde tutulan bilgi ve önbellek

Şartnamenin girişi, ads.txt'nin yetkili satıcıyı tanımlamada başarılı olduğunu, ama reklam platformundaki hesap kimliklerinin arkasındaki kimliği göstermediğini söyler. Teklif isteği nesnelerinde yayıncı adı ve alan adı özellikleri aracılığıyla son satıcıyı belirlemek mümkündür, fakat şartname bu özelliklerin farklı satış sistemlerinde tutarsız doldurulduğunu belirtir. Dosya, bu bilginin her istekle gönderilmesi yerine çevrimdışı olarak aranıp önbelleğe alınmasına izin verdiği için isteklerin boyutunu küçültür. IAB sayfası da aynı noktayı vurgular: aramalar çevrimdışı önbelleğe alınabilir, bu yüzden teklif isteklerinin bu bilgiyi taşımasına gerek kalmaz.

Her kimlik tek bir kuruluşa bağlıdır

Şartnamenin seller_id tanımı tekilliğe dayanır: bir seller_id birden fazla kuruluşu temsil edemez; her seller_id, o kimlikle işlem gören envanter için ödeme alan tek bir kuruluşa eşlenir. Bir kuruluşun aynı reklam sisteminde birden fazla seller_id'si olabilir. Bu kural yayıncı açısından şu anlama gelir: kimliğinizin karşısında iki farklı kuruluş görmeniz şartnameye aykırı bir durumdur ve reklam ortağınıza sorulması gereken bir konudur.

Zincirdeki her düğümün çözülmesi

Şartname, yayımlanmış ve erişilebilir bir sellers.json dosyasının SupplyChain nesnesindeki tüm düğümlerin, yani teklif isteğine katılan tüm kuruluşların kimliklerinin keşfedilmesine izin verdiğini söyler. Böylece bir teklif isteğinde yalnızca son satıcı değil, araya giren her aracı da görülebilir. Yayıncı bu zincirin içinde doğrudan çalışmaz, ama kendi kimliğinin zincirin başında yer aldığını bilmek, kayıtları okurken neye baktığını anlamasını sağlar.

Hangi soruya hangi dosya cevap verir

Yayıncıların karıştırdığı konuları ayırmak için soru bazlı bir tablo işe yarar. Her satır tek bir soruyu ve onu yanıtlayan dosyayı gösterir.

Tablonun gösterdiği gibi yayıncının doğrudan sahip olduğu iki şey ads.txt dosyası ve onun 1.1 sürümündeki alan adı bildirimleridir. Diğerleri karşı tarafın verisidir ve yayıncı bunları yalnızca okuyabilir.

Kayıt tutma şablonu

Uygulama önerisi: her reklam ortağı için bir satırlık kayıt tutun. Sütunlar şunlar olabilir: ortağın alan adı, ads.txt satırı, sellers.json adresi, kontrol tarihi, bulunan seller_type ve ad, uyumlu mu, uyumsuzsa kime yazıldığı ve cevabın tarihi. Bu kayıt bir sonraki kontrolde karşılaştırma zemini olur ve ortak değiştirdiğinizde eski satırları temizlemenizi hatırlatır.

Site sahibi olarak neyi kontrol edebilirsiniz

Yayıncı sellers.json'u düzenleyemez, ama okuyabilir. Bu adımlar şartnamedeki yapıya dayanır ve yetkili kontrolü yerine geçmez.

Adım adım kontrol

1. ads.txt dosyanızı açın ve her satırdaki reklam sistemi alan adını ve yayıncı kimliğini not edin.
2. Her alan adı için tarayıcıda adres çubuğuna bu alan adının ardından /sellers.json yazarak dosyaya ulaşıp ulaşamadığınızı deneyin.
3. Dosyayı açabildiyseniz kendi kimliğinizi seller_id alanında arayın.
4. Eşleşen kaydı bulduysanız seller_type, name ve domain alanlarının sizin kuruluşunuzla uyumlu olup olmadığına bakın.
5. Kayıt gizli işaretliyse ad ve alan adı görünmeyebilir; bu hata değildir, şartnamenin izin verdiği bir durumdur.
6. Kayıt bulunamazsa bunu bir hata olarak varsaymadan önce kimliği ads.txt satırından yeniden kopyalayıp tekrar deneyin.

Bu adımlardan sonra elinizde şu sorunun cevabı olur: ads.txt'te yazdığım her kimlik, karşı tarafta beklediğim kuruluşa bağlı mı? Cevap evetse zincirin sizin görebildiğiniz yarısı tutarlıdır. Hayırsa sonraki bölüme geçin.

Kontrol listesi

• ads.txt dosyası sitenin kökünden erişilebilir ve her satırın sözdizimi doğru.
• Her satırdaki reklam sisteminin /sellers.json adresi denendi.
• Her kimlik için seller_id eşleşmesi arandı.
• seller_type alanı hesabın niteliğine uygun görünüyor.
• name ve domain alanları yetkili kuruluşla uyumlu ya da kayıt gizli işaretli.
• Eşleşmeyen ya da beklenmeyen kayıtlar tarih ve ekran görüntüsüyle kaydedildi.
• Reklam ortağıyla yapılan yazışmaların kaydı tutuluyor.

Dosyanın boyutu, güncelleme sıklığı ve erişim sınırları reklam sistemlerine göre değişebilir ve şartname bunları kapsamaz. Dosya açılmazsa bu durum yayıncının hatası olmayabilir; şartname, tüketen sistemlerin son başarıyla alınan veri kümesini kullanabileceğini söyler, ama bir tarayıcı denemesinin sonucu üzerine kesin bir yorum yapılmamalıdır.

Yanlış ya da beklenmeyen satıcı kaydında ne yapılır

Kayıt sizin kimliğinize bağlı ama tüzel kişi adı yanlışsa, tür beklediğinizden farklıysa ya da tanımadığınız bir kuruluşa işaret ediyorsa üç yol vardır. Bu yolların hiçbiri sellers.json dosyasını sizin düzenlemenizi gerektirmez, çünkü dosyayı düzenleme yetkisi reklam sistemindedir.

Karar kuralı

Önce ads.txt satırınızın doğru kimliği taşıdığını doğrulayın; yanlış kopyalanmış bir kimlik başka bir kuruluşun kaydına gider. Kimlik doğruysa ve kayıt yine de tutarsızsa reklam ortağınızın destek kanalına yazın ve dosyadaki kaydın hangi kuruluşa ait olduğunu sorun. Şartnamedeki contact_email alanı, dosyanın sahibi olan reklam sistemine dosya hakkındaki sorular için ulaşılacak adresi içerebilir; böyle bir alan doluysa ilk başvuru noktası olabilir, boşsa ortağın normal destek kanalını kullanın. Kayıt sizin tanımadığınız bir kuruluşa bağlıysa, satış yetkisi verdiğiniz kişilerin listesini ve sözleşmelerinizi gözden geçirin; tanımadığınız bir ads.txt satırınız varsa kaynağını netleştirmeden dosyada tutmayın.

Başvuru mesajında neler bulunmalı

Uygulama önerisi: mesajda site alan adı, ads.txt satırı (kimlik dahil), sellers.json adresi, gördüğünüz kayıt ve beklediğiniz kayıt yer alsın. Ekran görüntüsü ve tarih ekleyin. Mesajda suçlama yerine soru kullanın: "Bu kimlik hangi kuruluşa bağlı?" ve "Kayıt türü neden bu şekilde?" gibi.

Düzeltme gecikmesi

Şartnameye göre tüketen sistemler dosyayı önbelleğe alabilir ve herhangi bir yönerge yoksa varsayılan geçerlilik süresi 7 gündür. Reklam sistemi kaydı düzeltse bile bir alıcının güncel kopyayı görmesi biraz zaman alabilir. Düzeltmeyi kontrol etmeden önce makul bir süre bekleyin ve sonucu tarihle birlikte kaydedin.

Örnek senaryo ve yayıncı dili

Örnek senaryo: Bir teknoloji inceleme blogu reklam gelirini bir yönetim şirketine devretmiştir. Şirket, blogun ads.txt dosyasına kendi alan adıyla bir satır eklemiştir. Blog sahibi satırdaki alan adı için /sellers.json adresini açar ve kendi kimliğini aradığında kaydın tüzel kişi adının yönetim şirketini değil, blog sahibinin eski bir ticari unvanını gösterdiğini görür. Blog sahibi kaydı değiştirmeye çalışmaz. Yönetim şirketine ads.txt satırını ve gördüğü kaydı gönderip tür ve ad alanlarının neden bu şekilde olduğunu sorar. Cevaba göre ya kayıt güncellenir ya da ilişkinin neden öyle kurulduğu açıklanır.

Bu senaryodaki asıl ders sıradır: önce kendi satırı doğrula, sonra karşı tarafı oku, en sonda soruyu doğru kanala yönelt.

Sellers.json ve gelir

IAB ve AdSense sayfalarında sellers.json kaydının gelire, doluluk oranına ya da alıcı tercihine etkisine dair bir ifade yer almaz. Alıcıların ads.txt ve app-ads.txt kanallarıyla satılan envanteri hedeflemeye devam etmesi ve SupplyChain nesnesini inceleyip sellers.json ile doğrulayabilmesi sayfada yazar; ancak bu davranışın bir yayıncının gelirini ne kadar etkilediği anlatılmaz. Bu yüzden bir sellers.json düzeltmesinin geliri artıracağı yönünde bir vaat kurulmamalıdır. Gelir metriklerini yorumlamak için RPM, eCPM ve doluluk oranı yazısındaki tanımlara bakın.

Neden önemsemeye değer

IAB, ads.txt'nin amacını programatik reklam ekosisteminde şeffaflığı artırmak ve kötü niyetli tarafların sahte envanter satmasını zorlaştırmak olarak anlatır. sellers.json bu amaca karşı yarıyı tamamlar. Yayıncı için bu, kendi gelirini korumanın yanı sıra, adına satış yapılan bir kimliğin karşı tarafta doğru görünmesini doğrulamak demektir.

Reklam ortağı değiştirirken zincirin iki yarısını birlikte yönetmek

Ortak değişikliği, iki dosyanın tutarsız kalabileceği anlardan biridir. Yeni bir ortakla çalışmaya başlayan yayıncı ads.txt dosyasına yeni satırlar ekler; eski ortağın satırları dosyada kalabilir. Karşı tarafın dosyasında ise eski ve yeni hesap kayıtları kendi takvimlerinde güncellenir. Uygulama önerisi: şu sıra geçişte tutarlılığı korumaya yardım eder.

Geçiş öncesi

1. Mevcut ads.txt dosyasının bir kopyasını tarihle birlikte saklayın.
2. Yeni ortaktan ads.txt satırını yazılı olarak isteyin; kimliği kendiniz tahmin etmeyin.
3. Yeni ortağın alan adı için /sellers.json adresinin açıldığını ve kimliğinizin orada göründüğünü kontrol edin.
4. Kaydın seller_type değerini ve tüzel kişi adını sözleşmenizle karşılaştırın.

Geçiş sırasında

Yeni satırı eklemek ile eski satırı kaldırmak arasındaki süre bir karar meselesidir. Eski satırı hemen kaldırmak o ortak üzerinden satışı yetkisiz hale getirir; geç kaldırmak ise artık çalışmadığınız bir kuruluşa satış yetkisi vermeye devam eder. Uygulama önerisi: iki ortakla yazılı bir geçiş tarihi belirleyin ve kaldırma tarihini kayıt tablosuna yazın.

Geçiş sonrası

Geçiş tamamlandıktan sonra ads.txt dosyasındaki her satırı bir kez daha kayıt şablonuyla gözden geçirin. Her satır için sorulacak soru şudur: bu kuruluşla hâlâ çalışıyor muyum? Cevap hayırsa satır kaldırılmalıdır. Karşı tarafın dosyasında eski hesabınıza ait kayıt bir süre daha görünebilir; bu durum önbellek gecikmesiyle açıklanabileceği gibi reklam sistemindeki ayrı bir sürece de bağlı olabilir. Sorunuz varsa eski ortağa yazın.

Yayıncı sorumluluğunun sınırı

sellers.json üzerinde yayıncının bir yetkisi olmadığı için sorumluluk sınırı da ayrı düşünülmelidir. Yayıncı, kendi sitesine koyduğu ads.txt dosyasının doğruluğundan, hangi şirketlere satış yetkisi verdiğinden ve bu şirketlerle yaptığı sözleşmelerden sorumludur. Karşı tarafın dosyasındaki kayıtların biçimi, güncelliği ve eksiksizliği ise reklam sistemine aittir. Şartname her satıcının listeye dahil edilmesi gerektiğini, gizli satıcıların bile listede bulunması gerektiğini söyler; bu yükümlülük reklam sistemine yöneliktir.

Yayıncı açısından bu ayrım pratikte iki sonuç doğurur. Birincisi, karşı tarafta görünen bir tutarsızlık sizin hatanız olmayabilir, ama bunu fark edip bildiren de sizsinizdir. İkincisi, kendi ads.txt dosyanızda tanımadığınız satırlar varsa sellers.json hiçbir zaman bunun bahanesi olmaz: o satırın var olması sizin kararınızdır. Bu nedenle ads.txt dosyasındaki her kimliği bir sözleşme, bir hesap ya da bir yazışma ile ilişkilendirebilmelisiniz.

Yetkisiz değişiklik şüphesi

ads.txt dosyanıza sizin eklemediğiniz bir satır ekleniyorsa bu bir erişim güvenliği sorunudur ve dosya değişikliklerini yapabilen hesapların gözden geçirilmesini gerektirir. sellers.json bu soruna doğrudan çözüm sunmaz; yalnızca şüpheli satırdaki kimliğin hangi kuruluşa bağlı olduğunu görmeye yardım eder. Kimliğin bağlı olduğu kuruluşu tanımıyorsanız satırı kaldırmadan önce sitenizi yöneten kişilerle kaydın nereden geldiğini netleştirin ve gerekirse satırı kaldırıp sebebini kaydedin.

Reklam ortağına sorulacak sorular

• Hesap kimliğim sizin sellers.json dosyanızda hangi kuruluşa bağlı?
• Hesabım PUBLISHER, INTERMEDIARY ya da BOTH olarak mı sınıflandırılıyor ve neden?
• Kaydım gizli olarak mı işaretli ve bu bilinçli mi?
• Bir kayıt düzeltildiğinde yayımlanan dosyada ne zaman görünür?
• Dosya hakkındaki sorular için doğru iletişim adresi nedir?

Cevapları kayıt tablosundaki ilgili ortak satırıyla birlikte saklayın. Cevaplar şartnamenin tarif ettiğinden farklıysa, örneğin tek kimlik birden fazla kuruluşa bağlıysa, bunu nazikçe belirtip açıklama isteyin.

Dosyayı okurken dikkat edilecek hatalar

Okuma sürecinde birkaç hata birbirine benzer biçimde tekrar edebilir. Liste kontrol sırasında bir yan çizelge olarak kullanılabilir.

• Alan adını yanlış yazmak: kök alan adı ile alt alan adı farklı dosyalar barındırabilir; şartname kök alan adını ve gerektiğinde alt alan adlarını anar.
• Kimliği yanlış kopyalamak: boşluk ya da fazla karakter eşleşmeyi bozar.
• Gizli kaydı hata sanmak: is_confidential 1 ise ad ve alan adı bırakılabilir.
• Aracı kaydı yayıncı kaydıyla karıştırmak: seller_type PUBLISHER ile INTERMEDIARY aynı şey değildir.
• Eski bir önbelleğe bakmak: tüketen sistemler dosyayı varsayılan olarak 7 gün saklayabilir.
• Karşı tarafın dosyasını düzenleyebileceğini sanmak: yayıncının sellers.json üzerinde yetkisi yoktur.

Bu liste bir yeterlilik testi değildir; reklam sistemleri ve ortakları farklı uygulamalar izleyebilir. Şüpheli bir durumda ortağın destek ekibine yazmak, tahminle ads.txt dosyasını değiştirmekten daha güvenlidir.

Sık Sorulan Sorular

sellers.json dosyasını sitem için oluşturmam gerekir mi?

Hayır. IAB sayfasına göre sellers.json dosyalarını SSP'lerin ve borsaların yayımlaması beklenir. Site sahibinin kendi sitesinde oluşturduğu dosya ads.txt'tir. Yayıncı için sellers.json bir okuma ve doğrulama aracıdır.

ads.txt ile sellers.json arasındaki fark nedir?

ads.txt, yayıncının hangi şirketlere satış yetkisi verdiğini bildirir. sellers.json ise reklam sisteminin kendi hesap kimliklerinin hangi kuruluşlara ait olduğunu açıklar. IAB şartnamesine göre ads.txt yayıncı hesap kimliklerinin kimliğini açığa çıkarmaya çalışmaz, sellers.json bu boşluğu doldurur.

Kayıtta INTERMEDIARY yazması kötü bir şey mi?

Şartnameye göre INTERMEDIARY, envanterin adı geçen kuruluşa ait olmadığını ya da reklam sisteminin ona doğrudan ödeme yapmadığını belirtir. Şartname bu alanı iyi ya da kötü diye nitelemez; hesabınızın niteliğiyle uyumlu olup olmadığına bakın.

DIRECT ve RESELLER ile PUBLISHER ve INTERMEDIARY aynı şey mi?

IAB ve AdSense sayfaları bu eşleşmeyi tanımlamaz. AdSense yardım sayfası DIRECT sözcüğünü yalnızca örnek bir satırda gösterir, RESELLER'dan söz etmez. Reklam ortağınızın belgelerine bakın.

Yanlış bir satıcı kaydını kendim düzeltebilir miyim?

Hayır. Dosya reklam sisteminin alan adında durur ve onu o sistem düzenler. Yapılabilecek olan, ads.txt satırınızdaki kimliği doğrulamak ve reklam ortağınıza kaydı sormaktır. Şartnamede dosyada bir iletişim e-postası alanı bulunabileceği yazar.

sellers.json gelirimi artırır mı?

Sayfalar şeffaflık ve doğrulama amacını anlatır; gelire etkisi konusunda bir vaat yer almaz, bu yüzden gelir sözü verilmemelidir.

Sonuç

sellers.json, reklam sisteminin dosyasıdır ve ads.txt'in tamamlayıcısıdır: biri yetkiyi, diğeri kimliği açıklar. Yayıncının yapabileceği, ads.txt satırındaki her kimliği karşı tarafın dosyasında aramak, türün ve kuruluş adının beklentiyle uyumlu olduğundan emin olmak, uyumsuzluk varsa reklam ortağına kayıtlı bir soruyla başvurmaktır. DIRECT ve RESELLER terimlerinin sellers.json türleriyle eşleşmesi belgelerde tanımlı değildir; bu eşlemeyi kendiniz kurmayın.

Ortak değiştirirken eski satırların dosyada kalmadığından emin olun, tanımadığınız her satırın kaynağını netleştirin ve karşı tarafta beklenmeyen bir kayıt gördüğünüzde bunu bir sorun olarak değil, yanıtlanması gereken bir soru olarak ele alın. Reklam ortağınızın yanıtlarını tarihle saklamak, hem sonraki kontrolü kolaylaştırır hem de sözleşme ilişkinizde neyin söylendiğini gösterir. Önce kendi ads.txt dosyanızı doğrulayın, sonra karşı tarafı okuyun, sonra soruyu doğru kanala götürün ve sonuçları tarihle kaydedin. Reklam alanı seçenekleri için Akua Adforce'taki reklam alanları sayfasına bakabilirsiniz; kapsam ve koşullar ilgili sayfada yazılıdır.