Aynı görünen reklamın arkasında farklı kurulumlar olabilir

Yan yana ürün kartları gördüğünde “katalog reklamı” demek doğal geliyor. Fakat ekrandaki görünüm, ürün bilgisinin nerede tutulduğunu veya fiyat değişince ne olacağını tek başına anlatmaz. Bu ayrım, reklamı hazırlarken de bir ürünü bulamadığında da önem kazanır.

Carousel, kaydırılabilen kartların oluşturduğu yaratıcı biçimi anlatır. Katalog ise reklamda veya alışveriş deneyiminde kullanılacak ürün kayıtlarının yönetildiği veri katmanıdır. İkisi aynı işin farklı parçaları olarak birlikte kullanılabilir; birinin varlığı diğerinin kurulduğunu kendiliğinden göstermez.

Bu rehberde “kaç kart yapalım?” sorusunun yanına üç soru ekliyoruz: Ürünler hangi kaynaktan geliyor? Değişiklikleri kim taşıyor? Yayında hangi ürünlerin kullanılabildiğini nasıl kontrol ediyoruz? Çalışma dosyası, reklam biçimi seçimini bu sorularla somutlaştırır.

Biçim, veri ve güncelleme sorularını ayır

Meta’nın resmî Business SDK’sında carousel seçenekleri ve alt kartlar kreatif bağlantı verisi içinde yer alır. Ayrı bir ProductCatalog nesnesi veri kaynağı ve tanılama işlemlerini taşır. Bu teknik ayrımın işletme karşılığı şudur: kartları hazırlamak ile ürün veri düzenini yönetmek aynı teslimat değildir.

KatmanKararİsteyeceğin kanıt
BiçimMüşteri hangi kart, metin ve görselleri görecek?Hedef yerleşime uygun önizleme.
Ürün verisiHangi ürün ve varyant kayıtları kullanılacak?Kimliği ve fiyatı belli örnek ürün kaydı.
GüncellemeFiyat veya bulunabilirlik değişince ne olacak?Kaynak zamanı ve değişiklik davranışı.
YayınHangi hesapta, hangi hedefle ve hangi koşulla çalışacak?Gerçek hesabın uygunluk ve sonuç kontrolü.

Bir hizmet teklifindeki “katalog tasarımı” yalnız görsel kartları kapsayabilir. “Katalog entegrasyonu” ise farklı bir veri bağlantısı anlamına gelebilir. Adı tartışmak yerine bu dört satırın hangilerinin karşılandığını yazılı olarak belirle.

Elle seçilen kartlar ne zaman yeterli olabilir?

Yeni koleksiyondan belirli birkaç ürünü göstermek, tek ürünün ayrıntılarını anlatmak veya hizmetin adımlarını sıralamak istiyorsan, seçilmiş kartlardan oluşan bir anlatım işini görebilir. Buradaki amaç bir ürünü otomatik seçmek değil, hangi bilgiyi hangi kartta anlatacağını kontrol etmektir.

Önce kartların ortak vaadini yaz. Örneğin bir çantanın boyutu, iç hacmi ve kullanım ayrıntısı üç ayrı kart olabilir. Üç farklı ürün gösteriyorsan her kartın görseli ve tıklama hedefi ilgili ürüne gitmeli. Sadece kart sayısını artırmak için birbirini tekrar eden görüntüler eklemek zorunda değilsin.

Fiyat veya stok gibi değişen bilgileri elle hazırlanmış kartlara koyduğunda bakım işini de üstlenirsin. Aynı veri farklı görsellere gömülmüşse değişiklik olduğunda hepsini bulup düzeltmek gerekir. Bunu kabul edilebilir bir iş yükü olarak görüyorsan basit bir kurulum tercih edebilirsin.

Tercih, evrensel bir ürün adedi eşiğine bağlı değildir. Az sayıda ama sürekli fiyatı değişen ürünün bakım ihtiyacı, daha geniş ve sabit bir seçkiden fazla olabilir. Kendi değişim hızını hesaba kat.

Katalog kullandığında ayrı bir ürün yönetimi işi oluşur

Meta Blueprint’in katalog rehberi, ürün ekleme, güncelleme ve sorun giderme işlerini katalog yönetiminin parçaları olarak ele alır. Katalog reklamı rehberi de bu ürün kayıtlarıyla kişiselleştirilmiş ürün reklamlarını anlatır. Kayıtların bakımı, görsel üretiminden ayrı değerlendirilmelidir.

Çalışma yöntemi olarak en azından ürün kimliği, varyant, ilgili sayfa, fiyat, para birimi, bulunabilirlik ve görsel kaynağını birbirine bağla. Reklamda seçmek istediğin ürün grubunun ne olduğunu açık yaz: bütün koleksiyon mu, belirli bir kategori mi, yalnız uygun durumdaki ürünler mi?

Bir ürünün web sitesinde yayımlanması ile reklam sistemindeki ilgili gruba dahil olması aynı kontrol değildir. Kendi kurulumunda kaynak, aktarım, ürün durumu ve seçim aşamalarını sırayla incele. Bu aşamalar için kullanılan menü ve uygunluk koşulları hesaba veya bağlantıya göre değişebilir; ekrandaki durumu esas al.

Ürünlerin görünmemesini otomatik olarak “algoritma beğenmedi” diye yorumlama. Önce kayıt gerçekten aktarılmış mı, doğru ürüne bakılıyor mu, durum ve filtreler ne söylüyor, bunları bul. Kanıt yokken belirli bir neden seçmek düzeltme işini uzatır.

Otomatik güncellemenin gerçekten ne yaptığını sor

Bir veri bağlantısı varsa değişikliğin kaynaktan hedefe nasıl ilerlediğini öğren. Düzenli alınan dosya, bağlantılı mağaza uygulaması ve bir defalık yükleme farklı süreçlerdir. Son başarılı alma zamanı ile son deneme zamanı da aynı şey değildir.

Somut bir sağlayıcı örneği olarak Wix’in kendi Meta katalog bağlantısı belgesi, veri akışı kurulduktan sonra mağaza ürünlerindeki değişikliklerin katalogda güncellendiğini açıklar. Bu, belirtilen Wix akışının dokümantasyonudur; her araç veya Madset için aynı davranışın bulunduğunu göstermez.

Kullandığın hizmetten bir değişiklik örneği iste. Bir ürünün fiyatı test kaydında değiştiğinde hedef kayıtta ne görülüyor? Veri alınamazsa son fiyat kullanılmaya devam mı ediyor, uyarı mı oluşuyor, yoksa yayın mı duruyor? Hangi davranışın gerçekleştiğini işlem kaydıyla gör.

Gerçek ürüne yanlış fiyat veya stok girerek canlı reklamda deneme yapma. Uygun test kaydı veya yayın dışı bir doğrulama kullan. Testin amacı müşteriye hatalı teklif göstermek değil, güncelleme zincirini anlamaktır.

İki varsayımsal mağazanın kararı neden farklı olabilir?

Varsayımsal örnek — müşteri vakası değildir. İlk mağaza sezon başında altı üründen oluşan sabit bir seçkiyi tanıtıyor. Ürünlerin fiyatı kampanya boyunca aynı; işletme sahibi haftalık kontrol yapabiliyor. Kartları elle seçmek ve ilgili ürün sayfalarına bağlamak, bu belirli iş için anlaşılır bir başlangıç olabilir.

İkinci mağaza aynı altı ürünü farklı boy ve renklerle satıyor; bazı varyantların bulunabilirliği gün içinde değişiyor. Buradaki ürün sayısı aynı olsa da veri bakım ihtiyacı farklı. İşletme sahibi, seçilen reklam biçiminden önce varyant kimliklerini ve güncelleme davranışını çözmek isteyebilir.

İlk mağazanın seçimini “daha profesyonel”, ikincininkini “kesin daha yüksek ROAS” diye derecelendiremeyiz. Her biri farklı bakım işini ve belirsizliği yönetiyor. Kararın dayanağı, ihtiyaç duyulan işlevin gerçekten karşılanması ve sonucun izlenebilmesi olmalı.

Madset veya başka bir aracı aynı sorularla değerlendir

Bir üründe katalog sözcüğünü gördüğünde şu soruları sor: Bu, uygulamanın içindeki ürün listesi mi? Seçilmiş kartlardan oluşan bir reklam mı? Platformda yönetilen katalog bağlantısı mı? Fiyat ve stok değişiklikleriyle ilgili hangi işlem gerçekten destekleniyor?

Madset’i de bu düzeyde değerlendir. Bir carousel akışının bulunması, canlı ürün akışı yönetimi veya sürekli stok senkronizasyonu anlamına gelmez. Güncel ürün açıklamasını ve kendi hesabında gösterilen kapsamı kontrol et; burada anlattığımız gereksinim matrisi bir özellik duyurusu değildir.

Ürün gösteriminde kendi kullanımını temsil eden bir örnek iste. Bir kartın hangi ürüne bağlandığını, bağlantıyı kimin değiştirebildiğini ve yayın öncesinde neyin onaylandığını gör. Hesap bağlantısı, reklam hedefi ve ölçüm koşulu da seçtiğin ürün biçiminden ayrı doğrulanmalı.

Bu sorular satın alma görüşmesini de kolaylaştırır. “Katalog yapabiliyor musunuz?” yerine “Belirli varyantları seçip her kartı doğru sayfaya bağlayabilir miyim; fiyat değişince hangi kayıt güncellenir?” diye sorabilirsin.

Çalışma dosyasını doldur ve ilk kapsamı daralt

Dosyada ihtiyaç, seçilen yöntem, ürün kaynağı, güncelleme sorumlusu, doğrulama kanıtı ve açık konu alanları bulunur. Her satırda bir gereksinim tanımla. Örnek satırlar bir hesabın çalıştığına dair sonuç değil, dolduracağın soruların örneğidir.

Başlangıç için temsil gücü olan küçük bir ürün seçkisi kullan: tek varyantlı bir ürün, farklı fiyatlı bir varyant ve geçici olarak kullanılamayan bir kayıt. Durumları sadece okuma veya yayın dışı önizlemeyle inceleyerek veri ve bağlantıların tutarlılığını kontrol et.

Son kararında biçimi, ürün kaynağını ve bakım sorumluluğunu birlikte yaz. Böylece tasarımcıya neyi çizeceğini, geliştiriciye hangi bilgiyi taşıyacağını ve işletme sahibine neyi kontrol edeceğini açıkça anlatabilirsin.