Kampanya ve Widget

Panelde tanımladığınız kampanya ve widget'lar uygulamada da çalışır. SDK size hangi yüzeylerin bu ekranda gösterilmeye hakkı olduğunu verir; Akinon App Maker eklentisi bunları native olarak çizer.

Hangi kapılardan geçer

getSurfaces() bir yüzeyi döndürmeden önce web widget'ının sorduğu soruların aynısını sorar — ve aynı sırada. Sıra önemlidir: her adım "gereğinden fazla gösterme" yönünde koruma sağlar.

1. Test modu. Test modundaki bir kampanya gerçek ziyaretçiye görünmez; test edene ise yalnızca o görünür. Filtre değil, kapıdır.
2. Sayfa hedefleme. app://home, app://product gibi sentetik ekran adlarına göre. Bkz. Event Takibi.
3. Ülke hedefleme. Ülke, isteğin IP adresinden sunucu tarafında çözülür ve yapılandırmayla birlikte uygulamaya gelir — uygulamanın bunu bilmesi gerekmez. getSurfaces() çağrısında country geçerseniz sizin değeriniz kullanılır.
4. Deney dışlaması. Bir A/B testi kontrol yüzeyini varyantıyla değiştirdiyse kontrol çizilmez. İkisini birlikte göstermek ziyaretçiye her iki kolu aynı anda göstermek olur.
5. Segment hedeflemesi. include modunda ziyaretçi listedeki segmentlerden en az birinde olmalı; exclude modunda hiçbirinde olmamalıdır. Segment üyeliği sunucuya sorulur ve beş dakika önbelleklenir.
6. Boş içerik. İçeriği olmayan bir kayıt atlanır. Tek istisna custom tipidir: orada kod içeriğin kendisidir.
7. Deney içeriği. config_override modunda varyantın içeriği kontrolün üzerine birleştirilir. Dizi değerleri değiştirilir, birleştirilmez — üç slaytlı bir varyant altı slayt olmaz.
8. Çatışma çözümü. Aynı yuvayı isteyen iki yüzeyden biri gösterilir.
9. Sıklık sınırı. Harcanmış bir kota yüzeyi düşürür.

Segment kapısı ağ hatasında ne yapar

Sunucuya ulaşılamazsa cevap "hiçbir segmentte değil" olur. Bu, include modunda göstermemek, exclude modunda göstermek demektir — web ile birebir aynı davranış. Tersi olsaydı bir kampanya ya tüm kitlesinden saklanırdı ya da bastırılmış olduğu kitleye gösterilirdi.

Çatışma çözümü: uygulamada neden daha kritik

Web'de iki widget aynı CSS seçicisini hedeflediğinde çakışır. Uygulamada çekişilen kaynak yuva konumudur: top, bottom, center. Aynı yuvaya iki duyuru çubuğu üst üste biner, iki popup aynı anda açılır.

Kurallar web ile aynıdır:

Davranış	Sonuç
highest_priority (varsayılan)	En yüksek öncelik kazanır; eşitlikte kayıt kimliğine göre kararlı seçim
all	Gruptaki herkes gösterilir
random	Grubun tamamı random ise biri seçilir

Pratik sonuç: aynı ekranda aynı yuvaya iki yüzey koyarsanız biri hiç görünmez. Panelde bunu görürseniz ya ekranları ayırın ya da öncelik verin. Seçiciyle yerleştirilmiş yüzeyler uygulamada bir yuva işgal etmez, dolayısıyla hiçbir şeyle çekişmez.

Sıklık sınırı

Panelde tanımladığınız perSession, perDay, perWeek, total ve minInterval kuralları uygulamada da geçerlidir.

Uygulamada bu web'den daha önemlidir: bir web sayfası her gezinmede yeniden yüklenirken uygulama süreci ekranların ötesinde yaşar. Kota kalıcı olarak diske yazılır, yani uygulama kapanıp açıldığında da korunur.

Kota yüzey gerçekten çizildiğinde harcanır, listeye girdiğinde değil. Tetikleyicisi hiç ateşlenmemiş bir popup ya da eşiğinin altında kalan bir sayaç kotasını kaybetmez.

Marka teması

Panelde tanımladığınız marka teması uygulamaya da gelir. Bu kozmetik bir ayrıntı değil: widget stil varsayılanları var(--selwise-brand, …) biçimindedir, yani hiçbir rengi elle değiştirmemiş bir merchant bile bu referansları gönderir. Eklenti bunları çözer; tema tanımlı değilse referansın içindeki yedek değer kullanılır — web'de olduğu gibi.

Kendi bileşenlerinizi boyamak isterseniz tokenlara doğrudan erişebilirsiniz:

const tokens = selwise.getTheme();
// { '--selwise-brand': '#d3145a', '--selwise-brand-text': '#ffffff', ... }

Panelden gelen takip ayarları

Panelin Takip Ayarları ekranındaki değerler uygulamada da uygulanır: yığın boyutu, gönderim aralığı, çevrimdışı kalıcılık, yeniden deneme sayısı ve kuyruk sınırı.

init() çağrısında açıkça geçtiğiniz bir seçenek panelden gelene göre önceliklidir — uygulama, panelin bilemeyeceği şeyleri bilir. Panelden gelen hata ayıklama modu yalnızca açabilir: kendi isteğiyle log açmış bir uygulamayı susturmaz.

Custom widget: kendi HTML/CSS/JS'iniz

custom tipindeki bir widget uygulamada izole bir WebView içinde çalışır. İçeriği panelin HTML alanından, stilini ve kodunu ise hem içerik bloğundan hem de panelin Özel CSS / Özel JS alanlarından okur.

WebView içindeki kodunuza bir köprü açılır:

selwise.track('kupon_kullanildi', { code: 'KIKOAPP20' });
selwise.addToCart('4711', 1);
selwise.navigate('/baskets/basket/');
selwise.close();

addToCart uygulamanın kendi sepet aksiyonunu tetikler, doğrudan istek atmaz: WebView'in mağaza oturumu yoktur, oradan eklenen ürün ziyaretçinin görmediği bir sepete düşerdi. Sepet ikonundaki sayı da bu sayede güncellenir.

selwise.track ile gönderdiğiniz isim custom_event olarak kaydedilir ve verdiğiniz ad üstverisinde saklanır.

Yüksekliği ölçmeniz gerekmez; belge kendi boyunu bildirir ve WebView ona göre büyür.

Arama yönlendirmeleri

Panelde tanımlı bir arama yönlendirmesi (kargo → kargo sayfası) uygulamada da çalışır: eklenti sonuç listesi yerine hedefe götürür. Bu bir cevaptır, başarısız arama değildir — bu yüzden sıfır sonuç raporunuza yazılmaz.

Ürün zenginleştirme

Panelde yazdığınız kendi HTML/CSS içeriğiniz uygulamada da çalışır. Tek fark yerleştirmenin nasıl söylendiği: webde bir CSS seçicisi verirsiniz, uygulamada bir yuva adı.

<SelwiseEnrichment plugin={Selwise} code={product.sku} slot="pdp-specs" />

Panelde kurala pdp-specs adını verdiğinizde içerik bu ekranda görünür. Kuralı sonradan değiştirmeniz, silmeniz veya yenisini eklemeniz için uygulamada hiçbir şey yapılması gerekmez — yeni sürüm de, yapılandırma da, dağıtım da. Bu, zenginleştirmenin tamamen dinamik kalmasını sağlayan şey.

Hangi yuva adlarının tanımlı olduğunu SDK söyler:

selwise.getEnrichmentSlots();
// ['basket-shipping', 'pdp-specs']

Markup uygulamaya nasıl geliyor

Webde widget ham blokları ve bir token haritası alır, yorumlamayı ve CSS kapsamlamasını kendisi yapar — çünkü içeriği merchant'ın kendi sayfasına yerleştirir ve oradaki stillerden korunması gerekir.

Uygulamada bu gerekmez: içerik izole bir WebView'de çizilir. Bu yüzden yorumlama, temizleme (sanitize) ve CSS kapsamlaması sunucuda yapılır ve uygulamaya bitmiş markup gelir. Alternatif, bir CSS temizleyicisinin kopyasını React Native paketinin içinde taşımak olurdu — ayrışması en pahalı kod türü.

Sonuç olarak panelde onayladığınız şey ekranda görünen şeydir; iki yol aynı prepareEnrichmentBlock ve aynı DOMPurify geçişini kullanır.

Token'lar ve kendi feed alanlarınız

Webdekiyle birebir aynı: ${title}, ${brand}, ${formattedPrice}, ${imageUrl} ve besleme dosyanızın kendi alanları için ${attr.gtin}, ${attr.garanti_suresi} gibi. Kanalınız kataloğu başka bir kanaldan ödünç alıyorsa (uygulama kanallarında olağan durum) token'lar o katalogdan çözülür.

Bir yuvada birden fazla kural

Bir yuvaya birkaç kural yığılabilir — künye tablosu, altında SSS, altında kargo notu. Hepsi tek WebView içinde çizilir, ama her kural kendi kökünü korur: gösterim kural başına bir kez raporlanır, kaç blok yığdığından bağımsız olarak. Bir bağlantıya dokunulduğunda tıklama, o bağlantıyı içeren kurala atfedilir.

Segment ve test modu

Kampanya ve widget'larla aynı: segment hedeflemesi ve test modu istemcide uygulanır. Bu, bir ürün için verilen cevabın tüm ziyaretçiler için önbelleklenebilmesini sağlayan şey.

Uygulamada geçerli olmayan tek ayar

Sunucu tarafı render (SSR). Webde bir kuralı merchant'ın kendi sunucusunun çizmesini seçebilirsiniz; amacı JavaScript çalıştırmayan istemcilerdir — GPTBot, ClaudeBot, bağlantı önizleme botları. Bir uygulamayı hiçbir tarayıcı tarama yapmaz, dolayısıyla bu seçeneğin uygulamada bir karşılığı yoktur. Uygulama kanalında panel bu seçeneği hiç göstermez ve renderMode değeri uygulamadaki görünürlüğü etkilemez: SEO için server işaretlediğiniz bir kural uygulamada da görünür.

Sırada ne var

• Öneri ve Arama
• WebView Köprüsü