amBrain
AdTechOct 26, 20267 dk okuma

Ermenistan ve Kafkasya'da Nearshore Reklam Teknolojisi Ekipleri: RTB Deneyimi, Ortak Saatler, Dil ve Sabit Kapsam Şartları Nasıl Kontrol Edilir

Gerçek Zamanlı Teklif VermeYurt Dışındaki EkiplerOrta Asya ve KafkasyaOrtağı Kontrol Etmek
Görsel yüklenemedi
İçindekiler

Ermenistan, Gürcistan veya Azerbaycan'daki bir nearshore ekibin gerçekten gerçek zamanlı teklif verme (RTB) sistemleri çalıştırıp çalıştırmadığını nasıl kontrol edeceğiniz, UTC+4'ün çalışma saatleriniz için ne anlama geldiği ve hangi reklam teknolojisi işlerinin sabit kapsama uyduğu.

Ermenistan'dan ya da Kafkasya'nın başka bir ülkesinden bir ekip, mühendisleri bir bidder, arz tarafı platformu (SSP), ad exchange ya da olay pipeline'ı kurup üretimde çalıştırmışsa ve kendi loglarınızdaki gerçek bir bid request'i size adım adım anlatabiliyorsa, reklam teknolojisi işi için görüşmeye değer.

Kısa yanıt: Orta Avrupa ile altı ya da yedi, Londra ile beş ya da altı, New York ile en fazla bir saatlik ortak mesai bekleyin; bu yüzden trafik zirvenizde kimin nöbette olacağını kararlaştırın. İmzadan önce mühendislerin konuşmasını dinleyin. Sabit kapsamı yalnızca şartnamesi ve kabul testi olan işlere verin; kazanılan açık artırma oranı ya da bulut maliyeti gibi hedefleri bunun dışında tutun.

Ermenistan veya Kafkasya'daki hangi reklam teknolojisi ekipleri incelemeye değer?

Burada hiçbir firma sıralanmıyor. Bir ekibi ancak ihtiyacınız olan türde bir sistemi kurup üretimde çalıştırmışsa kısa listeye alın: bir bidder ya da reklamları gerçek zamanlı teklif verme (RTB) ile satın alan bir talep tarafı platformu (DSP), bir SSP, bir ad exchange, bir reklam sunucusu ya da gösterimleri ve tıklamaları sayan pipeline. Her firmadan canlı sistemin adını ve mühendislerinin kurduğu kısmı söylemesini, yalnızca satış ekibiyle değil o mühendislerle de görüşmenize izin vermesini isteyin.

Bunun bir kısmı herkese açık olarak kontrol edilebilir. Prebid, yayıncıların birçok SSP'den ve exchange'den aynı anda teklif istemek için kullandığı açık kaynaklı bir yazılımdır ve bu bağlantıların her biri, Prebid'in herkese açık kodunda kimin değiştirdiğine dair geçmişi de açık olan bir bidder adapter'dır. Prebid'in dokümantasyonu, her Prebid.js adapter'ının “adapter bakımcısının iletişim e-postasını” belirtmesini istiyor. Bu e-postanın hangi alan adında olduğunu kontrol edin; bir firma bir platformun adapter'ını kendisinin yazdığını söylüyorsa, pull request'lerinin bağlantılarını isteyin.

Bir gizlilik sözleşmesi bir müşterinin adını vermeyi engelliyorsa, firmadan bunun yerine o müşteriyle bir görüşme ayarlamasını isteyin.

Bir ekibin gerçek RTB deneyimi olduğunu nasıl kontrol ederiz?

Mühendislere loglarınızdan, kişisel verileri çıkarılmış gerçek bir bid request verin ve bunu size adım adım anlatmalarını isteyin. Söze süre sınırıyla başlayıp başlamadıklarına dikkat edin. IAB Tech Lab'in bid request standardı OpenRTB 2.6, tmax alanını “zaman aşımını önlemek için, internet gecikmesi dahil, exchange'in tekliflerin alınması için tanıdığı milisaniye cinsinden azami süre” olarak tanımlıyor.

Ardından bir bidder'a teklifine ne olduğunu bildiren bildirimleri sorun. OpenRTB 2.6 üç bildirim tanımlar. Bir exchange, kazanma bildirimini “teklif kazanırsa (bu, reklamın teslim edildiğini, görüntülendiğini veya faturalanabilir olduğunu her zaman göstermez)” gönderir. Faturalama bildirimini “kazanan bir teklif exchange'e özgü iş politikasına göre faturalanabilir hale geldiğinde”, kaybetme bildirimini ise “bir teklifin kaybettiği bilindiğinde” gönderir. Harcamalarını bir exchange'in faturalarıyla karşılaştırmış bir ekip, sisteminin hangi bildirimi saydığını ve rakamlar tutmadığında ne yaptığını size anlatabilir.

Sorulacak dört soru daha:

  • tmax'tan sonra hazır olan bir teklife ne oluyor ve kaç teklifin geç geldiğini nasıl görüyorsunuz?
  • Bidder'ınız bir request'teki taban fiyatı, yani OpenRTB'nin “bu gösterim için CPM cinsinden ifade edilen asgari teklif” olarak tanımladığı bidfloor alanını nasıl ele alıyor?
  • Bize trafik zirvesinde yaşanmış bir olayı anlatın: ne bozuldu, neyi ölçtünüz ve neyi değiştirdiniz?
  • Sistemimiz için kim, hangi saatlerde nöbet tutar?

En çok zamanı olaya ayırın, çünkü alanlarla ilgili sorular yalnızca şartnameden yanıtlanabilir.

Ermenistan, Gürcistan ve Azerbaycan'daki ekipler hangi saat diliminde çalışır?

Yıl boyunca UTC+4. IANA saat dilimi veritabanına göre bu üç ülkenin hiçbiri saatlerini değiştirmez, Avrupa ve ABD ise değiştirir. İki tarafta da mesai 9.00 ile 18.00 arasındaysa, Erivan, Tiflis veya Bakü'deki bir ekibin ortak mesaisi şöyledir:

  • Berlin, Paris veya Amsterdam ile kışın altı, yazın yedi saat
  • Londra ile kışın beş, yazın altı saat
  • New York ile ABD yaz saatindeyken bir saat, kışın hiç
  • Kaliforniya ile hiç ortak mesai yok

Açık artırmalar akşam altıda durmaz. Trafiğinizin zirvesi ABD Doğu Yakası'nda akşam 20.00 ile 23.00 arasındaysa, bu Erivan'da sabah yaklaşık 04.00 ile 08.00 arasına denk gelir. Zirve saatlerinizde kimin nöbette olacağını, ne kadar hızlı yanıt vereceğini ve sizin tarafınızdan birine nasıl ulaşacağını yazılı olarak kararlaştırın.

Ekip hangi dillerde çalışacak?

OpenRTB ve Prebid'in dokümantasyonu İngilizce yayımlanır, dolayısıyla bir reklam teknolojisi mühendisinin İngilizceyi iyi okuması gerekir. Baskı altında İngilizce yazmak ve konuşmak ise ayrı bir beceridir ve bir firmanın web sitesi bu beceriye kimin sahip olduğunu size söylemez.

Projenizdeki mühendislerin ve ekip liderlerinin ticket'larda, kod incelemelerinde, olay raporlarında ve görüşmelerde hangi dili kullanacağını öğrenin ve imzadan önce bir görüntülü görüşmede bu dili kullanırken onları dinleyin. Ardından ekibin yazdığı, müşteri bilgileri çıkarılmış bir olay raporu isteyin ve onu kendi çalışanlarınızın raporunu okur gibi okuyun.

Hangi reklam teknolojisi işleri sabit kapsama uyar?

Sabit kapsam şu üç koşul sağlandığında işe yarar: işin yazılı bir şartnamesi vardır, iki tarafın da çalıştırabileceği bir kabul testi vardır ve sonuç bir ortağın takvimine bağlı değildir.

Bu koşulları sıklıkla karşılayan reklam teknolojisi işleri:

  • OpenRTB şartnamesini ve bir test uç noktasını yayımlayan bir talep veya arz ortağıyla yeni bir entegrasyon
  • Prebid Server için bir bidder adapter. Prebid'in her test vakası için bir JSON dosyası ve elle uçtan uca testler isteyen test kuralları, iki tarafa da hazır bir kabul testi verir
  • Olay raporlamasını yeni bir veritabanına taşımak; kabul, yeni sayımlar aynı trafik günlerinde eskileriyle tuttuğunda
  • Bidder'ı kararlaştırılan yanıt süresi içinde kararlaştırılan saniye başına istek sayısına ulaştırmak; kabul, kendi loglarınızdan yeniden oynatılan trafikle yapılan bir yük testiyle

O durumda bile sabit kapsama kodu ve testleri koyun, bir ortağın bunları kabul edeceği tarihi değil. Örneğin Prebid'in bakımcıları yeni adapter'ları kendi temposunda inceler. Prebid.js için dokümantasyon, yeni bir adapter'ın kodunun “birkaç gün içinde” incelenmek üzere bir geliştiriciye atandığını ve birleştirildikten sonra “bir sonraki sürüme dahil edildiğini” söylüyor.

Bazı işler ise sabit kapsama uymaz: kazanılan açık artırma oranını yükseltmek, bulut faturasını belirli bir oranda düşürmek ya da bir bidder'ı yeterince hızlı olana kadar ayarlamak. Sonuç piyasaya, ortaklarınıza ve kendi trafiğinize bağlıdır; bu yüzden bir firma işe söz verebilir ama rakama veremez. Böyle işler, işe başlamadan önce iki tarafın üzerinde anlaştığı bir ölçümle birlikte, özel bir ekibe ya da zaman ve malzeme esaslı çalışmaya daha uygundur.

Kapsam ne olursa olsun, sözleşme bir değişikliğin nasıl fiyatlandırılacağını belirtmelidir.

Nearshore bir reklam teknolojisi ekibiyle yapılan sözleşmede neler yazmalı?

Olağan şartların yanı sıra şunları yazıya geçirin:

  • Ekibin sizinkiyle paylaştığı saatler ve bu saatlerin dışında kimin nöbette olduğu
  • Her mühendisin çalıştığı ülkeler
  • Kodun sizin depolarınızda durduğu ve şirketiniz adına açılmış bulut hesaplarında çalıştığı
  • Bir SSP ya da exchange için alıcılarla ve satıcılarla yapılan sözleşmelerin ve ads.txt ile sellers.json'da yer alan alan adının şirketinize ait olduğu; bunlar, alıcıların reklam alanını kimin satabileceğini görmek için baktığı herkese açık dosyalardır

Doğu Avrupa veya Kafkasya'da şirket seçmeyi anlatan yazı sicil, yaptırım ve ödeme kontrollerini ele alıyor.

amBrain nerede devreye girer?

Bu blogu yayımlayan amBrain, Erivan (Ermenistan) merkezli bir yazılım mühendisliği şirketidir. Sitesi, reklam teknolojisi hizmetlerini şöyle sıralıyor: “DSP geliştirme, gerçek zamanlı teklif platformları ve ad exchange mühendisliği.” RTBBidder, amBrain'in bir müşteri için Rust ve Go ile geliştirdiği bir talep tarafı platformudur.

Bu yazının ele aldığı diğer sistemleri de geliştiriyor; kendi ifadesiyle: “amBrain, yayıncılar için arz tarafı platformları (SSP) geliştirir.” ve “amBrain, reklam teknolojisi için olay analitiği pipeline'ları geliştirir: gösterim ve tıklama olaylarının toplanması, işlenmesi ve raporlanması.” 2019'dan bu yana yazılım geliştiriyor ve üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler.

Mülkiyet konusundaki satırı ise şöyle: “Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.” amBrain'e de diğer her ekibe sorduğunuz soruları sorun: işlerinizden herhangi birini sabit kapsamla alıp almayacağını, alacaksa hangi kabul testiyle alacağını ve hangi yeniden kullanılabilir bileşenleri kastettiğini.

Bu yazı hukuki danışmanlık değildir: sözleşmeyi imzalamadan önce bir avukata okutun.

Masada buna benzer bir tasarım mı var?

Mevcut mimarinizi ve sizi endişelendiren hata senaryosunu getirin; yarım saatte birlikte üzerinden geçelim.

Görüşme Ayarla