Helal & E-Ticaret: Ürün Sayfası, Etiket ve Doğrulama

Ürün Bilgi Mimarisi: Helal İddialarının Doğru Konumlandırılması

E-ticaret kanalında helal uyumluluğu, yalnızca bir logo yerleştirmekten ibaret değildir; bütünsel bir bilgi mimarisi, kanıt zinciri ve kullanıcı yolculuğu tasarımı gerektirir. Kioscert ekosisteminde hedef; helal iddialarının (claims) doğrulanabilir, bağlama duyarlı ve dönüşüm odaklı şekilde ürün sayfası katmanlarına işlenmesi, aynı zamanda regülasyon farklarını gözeterek çoklu pazar uyumunun sürdürülebilir biçimde yönetilmesidir. Bu bölüm, ürün detay sayfası (PDP) için helal claim mimarisini; veri kaynakları, şematik yapı, doğrulama akışı, varyant yönetimi ve operasyonel yönetişim başlıklarında kurumsal seviyede çerçevelendirir.

1) Claim Taksonomisi ve Tanım Standartları

Öncelik, iddiaların taksonomik olarak sınıflandırılmasıdır: birincil sertifikasyon claim’i (ör. “Helal Sertifikalı – Kioscert onaylı”), ikincil süreç claim’leri (ör. “çapraz bulaşma kontrolü yapılmıştır”), kapsam ve istisna claim’leri (ör. “domuz kaynaklı bileşen içermez”), pazar/kurum referansı claim’leri (ör. “GCC tanınırlığı”), ve zaman/versiyon claim’leri (geçerlilik tarihçesi). Her claim, tanım, kanıt türü (sertifika, muayene raporu, proses SOP), geçerlilik aralığı, sertifikanın kapsam kodu ve pazar bağlayıcılığı meta alanları ile yapılandırılmalıdır. Bu ortak şema, PIM/ERP ve sertifika doğrulama servisleri arasında veri tutarlılığını sağlar.

2) PDP Yerleşim Stratejisi: Ana, İkincil ve Derin İçerik Katmanları

Kullanıcı niyetine göre bilgi derinliği değişir. Üst katman (buy box çevresi) satın alma kararı için kritik güven sinyallerine ayrılmalıdır: kısa “Helal Sertifikalı” rozeti, güncel sertifika no’su ve tek tıklama doğrulama linki/QR. Orta katman (ürün özellikleri ve içerik listesi) bileşen kökenleri, alerjen ayrımı ve proses kontrollere yer verir. Alt katman (akordiyon veya “Daha Fazla Bilgi”) sertifika kapsam metinleri, geçerlilik periyotları, denetim sıklığı, belge versiyon geçmişi ve pazar-spesifik istisnaları içerir. Bu katmanlı yaklaşım hem tarayıcıda bilişsel yükü azaltır hem de SEO’ya uygun semantik bölümlenme sağlar.

3) Semantik İşaretleme ve Arama Görünürlüğü

Teknik arama görünürlüğü için yapılandırılmış veri önerilir. Ürün şemasında Product ve Offer temelinde; helal durumu additionalProperty ile “HalalCertificationStatus: Certified”, belge no’su “HalalCertificateID”, geçerlilik bitişi “validThrough” gibi propertyValue çiftleri olarak işaretlenebilir. Marka düzeyinde Organization şemasında hasCredential benzeri niteliğe sertifika sağlayıcı ve tanınmışlık bilgisi iliştirilebilir. Bu yapı, arama motorlarına açıklanabilir, denetlenebilir sinxel üretir ve bilgi paneli zenginleşmesine katkı verir.

4) Doğrulama Akışı: Link ve QR Mimarisi

Doğrulama deneyimi tek tıklama ve low-friction olmalıdır. PDP’deki “Sertifikayı Doğrula” CTA’sı, sertifika GUID ve versiyon hash parametreleri içeren bir derin linke yönlenir. Mobil kullanıcılar için aynı URL’yi kodlayan dinamik bir QR, paket üzerindeki QR ile eşleşik tutulmalıdır. Link parametreleri UTM ile ölçümlenir; 404 ve süresi dolmuş belge durumları için graceful fallback ekranları tasarlanır. Çoklu belge versiyonu senaryosunda, son geçerli versiyona otomatik yönlendirme yapılırken, arşiv versiyonları açık biçimde tarih/versiyon etiketiyle erişilebilir kılınır.

5) Bileşen ve Alerjen Şeffaflığı

Helal iddiası, içerik şeffaflığıyla güçlenir. Bileşen listesinde hayvansal kaynaklı türevler (jelatin, enzim) ve alkol türevleri kaynak, saflık ve tedarikçi onayı alanlarıyla gösterilmelidir. Üretim bandı değişimi ve çapraz bulaşma risk senaryoları için proses kontrolleri, lot-based düzeyde açıklanabilir olmalıdır. Bu şeffaflık düzeyi, iade ve itibar risklerini düşürür.

6) Varyant ve Pazar Spesifik Kurallar

Varyant bazlı farklılıklar (aroma, gramaj, üretim yeri) helal kapsamını değiştirebilir. Mimaride her varyant, bağımsız claim ilişkisine sahip olmalı; kapsam dışı varyantların PDP’de “bu varyant helal kapsamına dahil değildir” uyarısı ile yanlış sipariş riski azaltılmalıdır. Pazar bazlı farklılıklar için ülke kodu ile koşullu içerik gösterimi uygulanır. GCC, Malezya, Endonezya gibi pazarlar için tanınmış kurumlar ve regülasyon referansları ayrı etiketlerle sunulmalıdır.

7) Yaşam Döngüsü, Sürümleme ve İzlenebilirlik

Helal belgesinin yaşam döngüsü; taslak → yayın → izleme → yenileme → arşiv aşamalarından oluşur. Her aşamada otomatik görevler ve bildirimler dizayn edilmelidir: geçerlilik bitişine 60/30/7 gün kala sistemsel uyarılar, PDP meta alanlarının otomatik güncellenmesi, geçersiz belge için sayfada kontrollü degradasyon (claim’in otomatik kaldırılması, doğrulama linkinin bilgilendirme ekranına yönlenmesi). Sürümleme, değişiklik günlüğü ile birlikte tutulmalı; who/when/what alanları denetim izi sağlar.

8) KPI’lar ve Operasyonel Yönetişim

Başarı metrikleri ölçülebilir olmalıdır: helal badge görüntülenme oranı, doğrulama link tıklama oranı, doğrulama sonrası sepet ekleme oranı, pazara göre dönüşüm farkı, süresi dolmuş belgeye maruz kalma oranı, iade oranında azalma. Yönetişim için RACI matrisi uygulanır: Ürün Ekibi (sahiplik), Uyum/Kalite (onay), Operasyon (veri girişi), IT (entegrasyon), Pazarlama (mesaj disiplininin kontrolü). Haftalık compliance review toplantıları ve aylık conversion clinic oturumları ile hem uyum hem performans birlikte optimize edilir.

9) Risk Kontrol Noktaları ve Hata Senaryoları

Tipik hata durumları: belge süresi dolmuş, pazarla uyumsuz claim gösterimi, yanlış varyant eşlemesi, QR-link tutarsızlığı, tedarikçi değişiminde sertifika kapsamının güncellenmemesi. Her biri için pre-publish doğrulama kontrolleri ve runtime korumalar kurgulanmalıdır: yayın öncesi zorunlu alan denetimi, pazar-varyant uyum kuralları, QR ve doğrulama linki eşleşme testi, tedarikçi güncellemesinde otomatik görev açılması. Hata yakalanırsa PDP, “uyarı içeriksiz” bir modda sadece genel ürün bilgisini gösterir, claim’leri gizler ve kullanıcıya doğrulama ekranına yönlendiren kısa bir bilgilendirme bırakır.

10) Erişilebilirlik ve Güven Sinyalleri

WCAG odak göstergeleri, ekran okuyucu etiketleri ve anlaşılır link metinleri kullanılarak erişilebilirlik korunur. Güven sinyalleri; sertifika sağlayıcı logosu yerine metinsel onay cümleleri, net tarih/versiyon bilgisi ve yetkili doğrulama URL’si ile verilmelidir. Görsel yoğunluğu sınırlı tutulmalı, metin hiyerarşisi ve akordiyon yapılarıyla bilgi sindirilebilirliğine öncelik verilmelidir.

Not: Bu mimari, bileşenleri gereksiz yere çoğaltmadan; hiyerarşik başlık düzeni, semantik bölümlenme ve responsive davranış ilkeleriyle uygulanmalıdır.

Sertifika Doğrulama Link/QR Stratejisi: Güven Sinyallerini Ölçeklenebilir Kılmak

Helal iddialarının güvene dönüşmesi için doğrulama deneyimi tek tıklama, düşük sürtünme ve sahteciliğe dayanıklı bir mimariye dayanmalıdır. Kioscert ekosisteminde önerilen çözüm, ürün sayfasındaki (PDP) “Sertifikayı Doğrula” çağrılarının GUID tabanlı derin link ve dinamik QR ile aynı doğrulama uç noktasına bağlandığı, paket üzerindeki QR ile izomorfik biçimde eşlenen bir tasarımdır. Böylece kullanıcı, hangi temas noktasından giriş yaparsa yapsın, tekil sertifika kaydının güncel versiyonına yönlenir; arşiv versiyonlarına ise zaman damgası ile ayrık erişim verilir.

1) Derin Link Tasarımı ve Parametre Standardı

Doğrulama URL’leri deterministik ve ölçümlenebilir olmalıdır. Önerilen şema:

/verify?cid={CERT_GUID}&ver={SEMVER}&sku={SKU}&lot={LOT}&market={ISO2}&src={PDP|PACK|SOCIAL}&utm_campaign=halal-verification

cid (sertifika GUID) tekil kaydı temsil eder; ver semantik versiyonlama kullanır (ör. 2.3.1); sku ve lot izlenebilirlik için opsiyoneldir; market ülke koşullandırmasını tetikler; src temas noktası sınıflandırması sağlar. PDP’deki CTA ve paket üzerindeki QR aynı cid’yi işaret etmeli, versiyon parametresi sağlansa dahi sistem latest-valid kontrolü yapıp gerekirse 302 ile güncel sürüme yönlendirmelidir. Böylece eski ambalaj stokları dolaşımda olsa bile yanlış pozitifler minimize edilir.

2) Dinamik QR ve Paket Eşlemesi

QR kodlar, URL-shortener yerine doğrudan doğrulama URL’sini kodlamalı, query parametreleri ile ölçüm yapılmalıdır. Üretim lot’u biliniyorsa lot parametresi ambalaj üzerinde yer alır ve doğrulama ekranında lot doğrulaması görsel yerine metinsel güven sinyali ile sunulur. PDP’de gösterilen QR, responsive bir modal içinde, alt açıklama metniyle (“Mobil cihazınızla tarayarak sertifikayı doğrulayın”) erişilebilir kılınır. Paket ve PDP QR’larının checksum’ları yayın öncesi CI/CD adımında otomatik karşılaştırılır; tutarsızlık bulunduğunda yayın blocker olarak kesilir.

3) Güvenlik: Anti-Tamper ve Kötüye Kullanım Önlemleri

Doğrulama uç noktası aşağıdaki kontrolleri içermelidir: (i) Replay koruması için imzalı nonce ve süre kısıtı, (ii) rate limit ve bot filtreleme, (iii) HMAC-tabanlı link imzası ile parametre manipülasyonunun tespiti, (iv) pazar uyum kontrolü ile yanlış bölge talebine uyarı ekranı, (v) content-security-policy ile gömülü sahte doğrulama iframe’lerinin engellenmesi. QR görseline görünmez micro-dot markörleri eklenerek kopyala-yapıştır (counterfeit) tespiti kolaylaştırılır. Loglarda cid, ver, market, kullanıcı agent ve referrer anonimleştirilmiş biçimde saklanır.

4) Fallback Senaryoları: Süresi Dolmuş, Askıda, İptal Edilmiş

Sertifika durumu Expired, Suspended veya Revoked ise doğrulama sayfası yumuşak iniş tasarımıyla açıklayıcı metin, geçerlilik tarihleri, sorumlu kuruluş bilgisi ve müşteri destek bağlantısını gösterir. PDP tarafında claim bileşeni otomatik degrade olur: rozet gizlenir, doğrulama CTA’sı “Bilgilendirme” metnine dönüşür. Bu otomasyon PIM tetikleyicisi ile çalışır; durum değişikliği geldiğinde PDP önbellekleri (CDN) stale-while-revalidate politikası ile dakikalar içinde yenilenir.

5) Ölçümleme: Funnel ve KPI’lar

Doğrulama akışı, üç aşamalı huni ile izlenir: Görüntülenme (badge/CTA görünürlük), Tıklama/Tarama (link/QR etkinliği), Onay (geçerli sertifika ekranı). Temel KPI’lar: doğrulama tıklama oranı (PDP ve paket ayrı), doğrulama sonrası sepet ekleme oranı, pazar bazında dönüşüm farkı, süresi dolmuş belgeye maruz kalma oranı, QR kopya tespit sayısı, mean time to update (sertifika statü değişiminden PDP güncellemesine). Tüm metrikler server-side olaylarıyla toplanmalı, istemci taraflı engellemelere karşı event duplication önleme mantığı çalışmalıdır.

6) Kullanıcı Deneyimi: Hız, Erişilebilirlik, Dil

Doğrulama sayfası TTFB ve LCP hedefleriyle optimize edilmelidir. Sertifika özet kartı metinsel olmalı, ekran okuyucular için aria-label ve odak sırası tanımlanmalıdır. Çok dilli işletim (TR/EN/AR/ID vs.) tarayıcı diline ve market parametresine göre otomatik seçilir; kullanıcıya yalın dil değiştirici sunulur. Link metinleri açık ve eylem odaklıdır: “Sertifikayı Doğrula”, “Arşiv Sürümünü Gör”, “Pazar Uyum Detayı”. QR’ın alt yazısı kısa, kontrastı yüksek tutulur.

7) Operasyon: Versiyonlama ve Yaşam Döngüsü

Sertifikalar immutable sürümler halinde saklanır. “Latest-valid” etiketi tek bir sürüme atanır ve yalnızca yetkili onay sonrası değişir. Arşiv sürümlere derin link verilir ancak PDP sadece latest-valid’i gösterir. Versiyon değişiminde otomatik webhook ile PIM alanları güncellenir; marketplace beslemeleri ve ürün feed’leri yeniden üretilir. Böylece paket değişmeyen ortamlarda bile dijital doğrulama güncel kalır.

8) Entegrasyon: PIM/ERP, Paket Tasarımı, Marketplace

PIM’de sertifika meta alanları (GUID, kapsam, geçerlilik, pazar) zorunlu işaretlenir. ERP’den gelen lot verisi, QR oluşturma sürecinde şablona uygulanır. Ambalaj tasarım DTP kiti, QR minimum boyut, quiet zone, baskı kontrastı ve yerleşim yönergelerini içerir. Pazar yerleri için mağaza profilinde veya ürün niteliklerinde doğrulama linki alanı haritalanır; policy-compliant metinlerle desteklenir. Eksik alan bulunduğunda pre-publish kontrolü yayını engeller.

9) SLA ve Dayanıklılık

Doğrulama hizmeti, CDN önbellekleme, çok bölgeli dağıtım ve health check’ler ile yüksek erişilebilirlik hedeflemelidir. Arıza halinde read-only cache moduna düşülür; son bilinen geçerli sertifika özetleri kullanıcıya sunulur. Olay yönetiminde iletişim şablonları hazır bulunur ve PDP’de geçici bilgilendirme bandı otomatik etkinleşir.

Not: Bu strateji, görsel yoğunluk yerine açıklanabilir metin, güçlü izlenebilirlik ve pazar uyumu ilkeleriyle dönüşüm ve uyumu birlikte optimize eder.

Çok Dilde İçerik ve Hukuki Metinler: Pazar Uyumu ve Dönüşüm İçin Standardizasyon

E-ticarette helal iddiasının ölçeklenebilirliği, dilsel yerelleştirme ile hukuki metinlerin pazar-spesifik bağlamda yönetilmesine bağlıdır. Hedef, tek kaynaklı içerik (single source of truth) mimarisiyle; ürün açıklamaları, bileşen/alerjen metinleri, sertifika özetleri, kullanım talimatları, etiket beyanları ve hukuki-politika setlerinin TR/EN/AR/ID vb. dillerde sürüm kontrollü, pazara koşullu ve erişilebilir biçimde yayınlanmasıdır. Bu bölüm, çok dilli içerik operasyonunu; terminoloji standardı, hukuki çerçeve, yerelleştirme süreci, kalite güvence, erişilebilirlik ve SEO uyumu ekseninde kurumsal ölçeğe taşır.

1) Terminoloji ve Sözlük Yönetimi

Helal alanında terimler hassastır. “Halal-certified”, “Sharia-compliant”, “pork-derived”, “alcohol-free”, “enzim kaynağı”, “çapraz bulaşma” gibi ifadeler kurumsal terminoloji sözlüğü ile yönetilmeli, dil çiftleri için canon karşılıklar sistemde kilitlenmelidir. Terim kartı; tanım, onaylı çeviri, yasaklı varyant, pazar notu ve örnek cümle alanlarını içerir. PIM ve çeviri yönetim sistemi (TMS) bu sözlükle entegre çalışır; editör, sözlük dışı kullanımda uyarı alır.

2) Hukuki Metinlerin Pazar-Spesifik Kapsamı

Hukuki katman; iddia beyanı (claim disclaimer), sertifika kapsam notu, pazar uygunluk bildirimi, iade/şikâyet prosedürü özeti ve destek sorumluluk redlerinden oluşur. Bölgeye göre farklılaşma zorunludur: GCC’de tanınırlık metinleri, Malezya/Endonezya’da yerel otorite referansları, AB’de tüketici koruma bağlamı ve dilsel şeffaflık vurgusu gibi. Hukuki metinler componentized tutulur ve PDP/landing/email/SMS’de aynı kaynaktan çekilir; versiyonlama ile değişiklik izi saklanır.

3) Yerelleştirme Süreci ve RACI

Yerelleştirme source → translate → review → legal check → publish akışına bağlanır. RACI matrisi: Ürün (Sorumlu), Uyum/Hukuk (Onay), İçerik Operasyon (Uygulayıcı), Kalite (Danışılan). TMS’de bellek (TM) ve makine çevirisi augment olarak kullanılır ancak helal ve alerjen cümleleri için mutlaka human-in-the-loop onayı gerekir. Kritik claim cümleleri için iki aşamalı peer review tetiklenir.

4) Yapılandırılmış İçerik ve Koşullu Gösterim

İçerik atomik nesnelere bölünür: ingredient_item, allergen_note, halal_claim_summary, market_disclaimer, return_policy_snippet. Her nesne lang, market, version, validThrough meta alanları taşır. PDP şablonu bu nesneleri koşullu olarak birleştirir: Tarayıcı dili EN ancak market=SA ise metin EN kalır, market_disclaimer SA varyantı çekilir. SEO için hreflang linkleri ve og:locale etiketleri sayfa bazında üretilir.

5) Hukuki Ton ve Claim Disiplini

Metinler kanıta dayalı ve ölçülü olmalıdır. “%100 helal” gibi mutlak iddialar yerine sertifika kapsamına referans verilmelidir: “Kioscert doğrulamalı helal sertifikası kapsamında”. Comparative veya superiority iddiaları kullanılmaz. İstisnalar ve kapsam dışı varyantlar açıkça belirtilir. Çeviride kültürel hassasiyet gözetilir; dini referanslar ticari iddiaya dönüştürülmez.

6) Kalite Güvence: LQA ve Regresyon

Çok dilli yayınlarda LQA (Linguistic Quality Assurance) zorunludur. Ölçütler: terminoloji uyumu, sayı/tarih formatı, yönlülük (AR için RTL), kesinti ve satır sonu kontrolü, emoji/simge uyumu olmamalı. Regression testlerinde PDP’nin dil değiştiricisi, akordiyon başlıkları, doğrulama CTA metinleri ve mikro-kopyalar otomatik testlerle doğrulanır. Lokalizasyon hatası kritikse yayın blocker ile durdurulur.

7) Erişilebilirlik ve RTL Diller

Arapça gibi RTL dillerde dir="rtl" ve uygun lang etiketleri zorunludur. Görsel yerine metin tercih edilir. Link metinleri eylem odaklıdır: “Sertifikayı Doğrula / تحقق من الشهادة”. Ekran okuyucu etiketleri dil-spesifik sağlanır. Tipografi ve satır uzunluğu okunabilirlik için ayarlanır.

8) SEO ve Meta Yapı

Her dil varyantı için benzersiz <title>, meta açıklama ve hreflang kuralları uygulanır. Helal claim anahtar kelimeleri, pazar-adı ve ürün-jenerik isimleriyle birlikte hedeflenir. Yapılandırılmış veride dil bazlı inLanguage alanı atanır. Kanıt metinleri arama motoru tarafından anlaşılır kılınır ancak özensiz anahtar kelime doldurma yapılmaz.

9) E-posta, Bildirim ve Destek Şablonları

Onay, yenileme ve durum değişikliği bildirimleri çok dilli şablon setinden üretilir. Destek makaleleri ve iade prosedürü özetleri aynı kaynak nesneleri kullanır. Müşteri temsilcisi için talk track ve macro şablonları sağlanır; hukuki ifadeler şablon dışına çıkmadan iletilir.

10) Ölçümleme ve Gelişim Döngüsü

Dil yayını sonrası dönüşüm, çıkış oranı, doğrulama tıklaması, destek talebi türleri ve yanlış anlama kaynaklı iade oranı izlenir. Hedef, yerelleştirme sonrası dönüşümde artış, destek talebinde azalma ve doğrulama sonrası sepet eklemede yükseliştir. Bulgular aylık localization review oturumlarında ele alınır.

Not: Bu çerçeve, dil farklılıklarını risk değil büyüme vektörü olarak konumlandırır; uyum ve dönüşümü birlikte optimize eder.

PIM/ERP ile Belge Senkronizasyonu: Tek-Kaynaklı Veri, Otomatik Yayın ve Denetim İzi

Helal sertifika yönetiminin e-ticaret kanallarına tutarlı yansıması, PIM (Product Information Management) ve ERP (Enterprise Resource Planning) arasında kurulan event-driven entegrasyon mimarisi ile sağlanır. Amaç; sertifika meta verilerinin (GUID, kapsam, geçerlilik aralığı, versiyon, pazar kodları), ürün-variant hiyerarşisine parametrik biçimde bağlanması, paket üzerindeki QR ile PDP doğrulama linkinin deterministik eşleştirilmesi ve tüm bu akışın değişiklik günlüğüyle izlenebilir kılınmasıdır. Bu bölüm, veri modeli, akış diyagramı, hataya dayanıklılık, SLA ve operasyonel yönetişimi içeren kurumsal düzeyde bir senkronizasyon standardı sunar.

1) Veri Modeli: Atomik Nesneler ve İlişkilendirme

PIM tarafında halal_certificate atomu şu zorunlu alanları içerir: certificate_guid, scope_code (ürün/proses/kategori), valid_from, valid_to, issuer_code, market_allowlist (ISO2 listesi), version (semver), status (Active/Expired/Suspended/Revoked). Ürün ağacında product → variant → pack düzeyleri için many-to-one ilişki tanımlanır. ERP’den gelen lot_id ve plant_code alanları, paket QR üretimi ve izlenebilirlik gösterimleri için opsiyonel bağdır. İlişkilendirme kuralları, kapsama göre şu şekilde zorlanır: product-scope için tüm variantlar devreye alınırken, variant-scope durumunda yalnızca eşleşen variantlar PDP’de claim gösterir.

2) Olay Tabanlı Akış: Upsert, Yayın ve Dağıtım

Kaynak sistem PIM’dir. Sertifikaya ilişkin her değişiklik upsert olayı olarak mesaj kuyruğuna (ör. certificate.updated) düşer. Tüketici servisler sırasıyla şunları yapar: (i) resolver sertifika–ürün ilişkilerini hesaplar, (ii) feed-generator PDP şablon alanlarını ve marketplace niteliklerini üretir, (iii) verifier doğrulama linki ve QR checksum eşleşmesini CI/CD adımında kontrol eder, (iv) cdn-purger etki alanındaki sayfaların önbelleğini stale-while-revalidate politikasıyla yeniler. Upsert’in 60 dakika içinde global consistency seviyesine ulaşması hedeflenir.

3) Doğrulama Linki ve QR Eşleşmesi

PDP’deki “Sertifikayı Doğrula” linki ile paket üzerindeki QR aynı certificate_guid ve version meta verisine bağlıdır. QR üretim servisi, ERP’den lot_id geldiğinde parametreyi URL’e ekler; gelmediğinde null-safe davranır. Build zamanında checksum üretilir ve PIM’de saklanır. Yayın pipeline’ında verifier modülü PDP’de gözüken QR görselinin checksum’ını PIM’deki referans ile karşılaştırır; tutarsızlık blocker olarak işaretlenir.

4) Pazar Koşullandırma ve Koşullu Yayın

market_allowlist alanı; sertifikanın hangi ülkelerde iddia olarak gösterileceğini belirler. renderer, kullanıcının market sinyaline (coğrafi IP, mağaza seçimi, profil tercihi) göre PDP bileşenlerini koşullu render eder. Allowlist dışında kalan pazarlarda helal rozetleri gizlenir, doğrulama CTA’sı uyum metnine yönlenir. Marketplace akışlarında pazar başına farklı attribute mapping uygulanır ve eksik haritalama tespitinde pre-publish kontrolü yayını durdurur.

5) Hata Yönetimi: Triyaj, Retry, Degrade

Tipik hata sınıfları ve tepkiler: veri bütünlüğü (zorunlu alan eksik) → olay dead-letter queue’ya düşer ve JIRA triyajı açılır; yönlendirme hatası (latest-valid hesaplanamadı) → doğrulama servisi read-only önbellekten son geçerli özeti sunar; market uyuşmazlığı → PDP tarafında claim bileşeni nizami olarak degrade olur, sadece açıklayıcı metin kalır. Tüm hatalar observability katmanında alarm ve grafana panelleri ile izlenir.

6) SLA ve Ölçümleme

Hedef SLA: PIM’de kaydedilen sertifika statü değişikliğinin PDP’de yansıması için T90 ≤ 15 dk (kritik durumlar), normal akışta T95 ≤ 60 dk. KPI seti: time-to-publish, cache-hit ratio, mismatch incidence (QR–link), expired exposure (süresi dolmuş belgeye maruziyet), rollback frequency, market compliance pass rate. Aylık compliance & performance oturumlarında kök neden analizi yapılır.

7) Güvenlik ve Denetim İzi

PIM alanları saha düzeyinde RBAC ile korunur. Sertifika statüsü ve valid_to değişiklikleri iki aşamalı onay ister. Tüm upsert’lar immutable audit log’a yazılır: actor, timestamp, diff, source. Marketplace’e giden feed’ler imzalanır ve checksum’ları 30 gün saklanır. Üçüncü taraf entegrasyonlarında mTLS ve IP allowlist zorunludur.

8) Operasyonel Yönetişim ve RACI

Roller: Ürün Bilgisi Ekibi (PIM sahipliği), Uyum/Kalite (onaylayıcı), IT/Platform (entegrasyon ve gözlemlenebilirlik), Operasyon (veri girişi/regresyon), Pazarlama (metin disiplininin kontrolü). Haftalık change advisory oturumlarında sertifika statü değişiklikleri, pazar allowlist revizyonları ve büyük yayınlar planlanır.

Not: Bu senkronizasyon standardı, tek-kaynak yaklaşımıyla veri tutarlılığını artırır, hataya dayanıklı bir doğrulama deneyimi sağlar ve marketplace uyum risklerini minimize eder.

Kampanya/Landing Page Uyumluluğu: Helal İddialarını 360° Temasta Tutarlamak

Kampanya ve landing sayfaları, helal iddiasının ölçekli trafik kaynaklarıyla temas ettiği ilk yüzeydir. Stratejik öncelik; reklam yaratıcıları, hedef URL’ler, pre-landing modüller, landing bileşenleri ve PDP arasında tam tutarlılık kurmak, iddia/metin/kanıt zincirini tek-kaynaklı veri modeliyle beslemek ve policy-compliant bir yayın kontrol katmanıyla riski minimize etmektir. Bu bölüm, kampanya–landing–PDP üçlüsünde uçtan uca uyumu; içerik standardı, veri bağlama, kontrol listeleri, ölçümleme ve denetim izi başlıklarıyla kurumsal ölçekte çerçevelendirir.

1) Mesaj Mimari Haritalama: Ad → Pre-Landing → Landing → PDP

Her kampanya varlığı bir mesaj düğümü olarak ele alınmalıdır: reklam başlığı, kopya, görsel altyazı, ad extension, hedef URL ve UTM parametreleri. Bu düğümler PIM’deki halal_claim_summary ve certificate_guid alanlarına referansla bağlanır. Yaratıcıda kullanılan helal iddiası, landing’de aynı kapsam ve aynı versiyon bilgisiyle tekrarlanır; PDP’deki “Sertifikayı Doğrula” CTA’sına derin link verilir. Böylece kullanıcı, ad tıklamasından doğrulama ekranına kadar one-truth akışta ilerler.

2) Pre-Landing Politikası: Risk Azaltıcı Ön Katman

Yüksek bütçeli kampanyalarda pre-landing bileşeni önerilir. Bu modül, trafik kaynağına göre minimal bir özet içerik ve tek tıklama doğrulama CTA’sı sunar. Amaç, reklam politikalarına aykırı olabilecek ayrıntıları ayıklamak değil; kanıt sunumunu erkene çekmek ve yanlış anlama riskini düşürmektir. Kaynak referrer, cihaz, pazar sinyali ve dil algısına göre metinler koşullu render edilir. Pre-landing, bounce olmadan 300–500 ms içinde landing’e degrade-free geçiş sağlar.

3) Landing İçerik Standardı ve Bileşen Seti

Landing şablonu atomik bileşenlerle yapılandırılır: hero (kısa helal özet metni + doğrulama CTA), evidence (sertifika no, geçerlilik, pazar kapsama etiketi), ingredient/allerjen özet, market disclaimer, FAQ (sertifika kapsamı, yenileme periyotları, istisnalar), CTA bar (Sepete Ekle / PDP’ye Git / Sertifikayı Doğrula). Tüm bu bileşenler PIM’den gelen aynı veri nesnelerini tüketir. Tasarımda görsel ağırlık değil, metinsel açıklanabilirlik ve erişilebilir hiyerarşi esastır.

4) Uyum Kontrolleri: Policy, Pazar, Versiyon

Yayın öncesi policy gate üç katmanda çalışır: (i) platform policy (reklam ağı kuralları) — mutlak iddia, yanıltıcı üstünlük, hassas hedefleme uyumsuzluğu tespiti; (ii) pazar uyumu — market_allowlist dışı ülkede helal rozetinin gizlenmesi ve market disclaimer’a yönlendirme; (iii) versiyon tutarlılığı — ad/landing/PDP üzerinde latest-valid eşleştirmesi. Her kontrol başarısızlığında yayın pipeline’ı block olur ve triayj görevi açılır.

5) URL ve UTM Standardizasyonu

Helal iddiası içeren kampanyalar için UTM parametreleri standarttır: utm_campaign=halal-claim, utm_content={claim_variant}, utm_term={market}. Hedef URL; landing’de ?cid={CERT_GUID}&ver={SEMVER}&market={ISO2} parametrelerini taşır. PDP’ye geçişte parametreler korunur. Böylece funnel analizi ve pazar bazlı dönüşüm ayrıştırması güvenilir hale gelir.

6) A/B Testi ve Deney Tasarımı

Test hipotezleri iddianın yerleşim, ifadeyiş ve kanıt yakınlığına odaklanmalıdır. Örnek: “Hero’da kısa helal özeti + doğrulama CTA, scroll derinliğini ve sepet eklemeyi artırır.” Deney tasarımında sample ratio mismatch korunur, power hesapları yapılır, stopping rule önceden belirlenir. Hedef metrikler: doğrulama tıklama oranı, PDP geçiş oranı, sepet ekleme ve tamamlanan sipariş. Anlamlılık eşiği α=0,05, minimum detectable effect kampanya bütçesine göre belirlenir.

7) İçerik Tonu ve İddia Disiplini

Ton, kanıta dayalı ve ölçülü olmalıdır. “%100 helal” benzeri mutlak ifadeler yerine “geçerli sertifika kapsamı dahilinde” çerçevesi kullanılır. Karşılaştırmalı üstünlük cümleleri (daha temiz, en güvenli vb.) kullanılmaz. Landing’de yer alan market disclaimer kullanıcıya açık ve kısa cümlelerle sunulur; kültürel hassasiyetler gözetilir.

8) Performans ve Erişilebilirlik

Sayfa ağırlığı sınırlıdır. Critical CSS yerinde, TTFB/LCP hedefleri içeren perf budget tanımlanır. Erişilebilirlik için buton etiketleri eylem odaklıdır: “Sertifikayı Doğrula”, “PDP’ye Git”. Ekran okuyucu metinleri dil-spesifik sağlanır. RTL dillerde dir="rtl" uygulanır. Renk kontrastı WCAG’e uygundur.

9) Ölçümleme ve Uçtan Uca Raporlama

Olay şeması server-side izlemeye dayanır: ad_impression, ad_click, landing_view, verify_click, pdp_view, add_to_cart, purchase. Raporlama katmanında pazar, dil, cihaz ve kaynak kırılımlarıyla claim-attributed dönüşüm raporu üretilir. Attribution window kampanyaya göre 7–30 gün arası konfigüre edilir. Üst yönetim için aylık compliance & conversion panosu yayınlanır.

10) Operasyon ve RACI

Roller net tanımlanır: Pazarlama (kampanya stratejisi ve yaratıcı), Uyum/Hukuk (policy ve pazar metin onayı), Ürün Bilgisi (PIM veri doğruluğu), IT/Platform (yayın pipeline’ı ve izleme), Destek (SLA ve makrolar). Yayın öncesi go/no-go kontrol listesi doldurulmadan trafik açılmaz.

Not: Bu çerçeve, marka vaadinin kanıtıyla aynı sayfada buluşmasını garanti eder; reklam politikası riskini azaltırken dönüşümü maksimize eder.

Influencer/Reklam Metinlerinde İddia Yönetimi: Politika-Uyumlu, Kanıta Dayalı İletişim

Helal iddialarının ücretli ve kazanılmış medya kanallarında ölçeklenmesi, mesaj disiplini, kanıt erişimi ve operasyonel kontrol üçgenine dayanır. Amaç; influencer içerikleri, display/video reklamları, sosyal kopyalar ve PR metinlerinde kullanılan tüm helal söylemlerini tek-kaynaklı veri modeliyle (PIM/TMS) beslemek, platform politikaları ve yerel regülasyon koşulları ile tutarlı kılmak ve doğrulama deneyimini tek tıkta erişilebilir hale getirmektir. Bu bölüm, brifing standartları, sözleşme maddeleri, metin şablonları, doğrulama link/QR entegrasyonu, izleme ve kriz protokolleri ile kurumsal bir claim governance çerçevesi tanımlar.

1) Brifing Standardı: Tek-Kaynak Metin ve Kısıtlar

Influencer ve ajans brifingleri, PIM’deki halal_claim_summary, certificate_guid, scope_code, valid_to ve market_allowlist alanlarına referans içerir. Mutlak ifadeler (%100, en temiz, rakipsiz) yasaktır; kapsam referanslı cümleler kullanılır: “Kioscert doğrulamalı helal sertifikası kapsamında”. Yasaklı kelime listesi ve do-not-claim örnekleri brifinge eklenir. Görsel altyazıları, Reels/TikTok metinleri ve pin açıklamaları dahil tüm varlıklarda aynı mesaj matrisi uygulanır.

2) Sözleşme ve Onay Mekanizması

Sözleşmeye claim compliance maddeleri eklenir: (i) metin ve sesli ifadeler pre-approval gerektirir, (ii) helal iddiası yalnızca latest-valid sertifika versiyonu ile kullanılabilir, (iii) market allowlist dışında iddia gösterimi yasaktır, (iv) ihlalde 24 saat içinde düzeltme/kaldırma yükümlülüğü, (v) disclosure zorunluluğu (#işbirliği, Paid Partnership) ve platform politikalarına uyum. Onay akışı source → legal → compliance → publish sırasını izler, sürümler TMS’de arşivlenir.

3) Metin Şablonları ve Mikro-Kopyalar

Standart kopya blokları oluşturulur: Kısa Özet (“Helal sertifikası doğrulandı. Sertifikayı gör: {verify_link}”), Uzun Özet (kapsam, pazar ve geçerlilik dahil), CTA (“Sertifikayı Doğrula”, “PDP’ye Git”), Disclosure (#işbirliği). Dil varyantları TMS üzerinden temin edilir; RTL diller için ayrı satır uzunluğu ve yön kontrolü yapılır. Video içeriklerinde sesli metin ile ekrandaki altyazı anlam eşdeğerliği testinden geçer.

4) Doğrulama Link/QR Entegrasyonu

Sosyal biyografi linki, kampanya link hub’ı veya vanity alan adı üzerinden /verify?cid={CERT_GUID}&ver={SEMVER}&market={ISO2}&src=SOCIAL kullanılır. Stories/Reels için ekran üzerinde okunabilir kısa URL ve sabitlenmiş sticker önerilir. Fiziksel etkinlik veya PR kitlerinde yer alan basılı QR, dijital varlıklarla checksum eşleşmesi üzerinden doğrulanır. Tüm temaslarda parametreler korunur; yönlendirme latest-valid kontrolüne tabidir.

5) Platform Politikaları ve Regülasyon Uyumu

Meta, TikTok, YouTube ve Google Ads politikaları gereği kanıtlanamayan üstünlük ve yanıltıcı sağlık/temizlik iddiaları yasaktır. Helal söylemi sertifika kapsamına referans verir. Reklam metinlerinde dinî hassasiyetin ticari iddiaya indirgenmesi kaçınılır. Ülke bazlı reklam etiketleri (ör. KSA’de Arapça disclosure), hukuki dipnot ve pazar disclaimer’ı otomatik eklenir. İhlal öncesi policy pre-check araçları zorunlu geçiştir.

6) İzleme, Moderasyon ve Arşiv

Yayın sonrası 48 saatlik yakın izleme penceresi tanımlanır. Sosyal dinleme aracı, anahtar kelimeler ve hashtag’lerle etiketlenmiş içerikleri tarar; claim dışı kullanımda otomatik bilet açılır. Tüm onaylı varlıklar content registry’de hash’lenerek saklanır; takedown ve edit kararları denetim izi ile kayda geçer. Sertifika statü değişiminde sistem, ilgili içerik sahiplerine otomatik revizyon bildirimi gönderir.

7) Kriz Senaryoları ve İletişim Şablonları

Yanlış/abartılı iddia, süresi dolmuş sertifika veya pazar dışı gösterim tespitinde T0 içinde içerik dondurulur, T+2 saatte düzeltme metni yayınlanır, T+24 saatte kök neden analizi tamamlanır. Hazır şablonlar: “Düzeltme ve Açıklama”, “Sertifika Durum Güncellemesi”, “Pazar Uyum Bilgilendirmesi”. Kamu yanıtlarında mutlak ifadelerden kaçınılır; doğrulama linki ve geçerlilik tarihleri metin içinde verilir.

8) Eğitim ve Yetkinlik

Influencer ve ajanslara yılda iki kez claim compliance eğitimi verilir. Modüller: helal sertifikasının kapsamı, yasaklı söylemler, doğrulama akışı, disclosure, pazar farklılıkları, kriz yönetimi. Katılım zorunludur, yüzdelik başarı eşiği ≥80. Başarısız olanlar için ek koçluk planı uygulanır.

9) KPI ve Optimizasyon Döngüsü

Ölçütler: verify_click_rate, pdp_transition_rate, add_to_cart, policy_violation_rate, time-to-correct, market_compliance_pass. Aylık governance review ile metin şablonları ve brifing dokümanları revize edilir. Hedef, ihlal oranını ≤%0,5, düzeltme süresini ≤24 saat seviyesinde tutmaktır.

Not: Bu yönetişim, etki–risk optimizasyonu sağlar; kanıta dayalı söylem dönüşümü artırırken platform yaptırımı riskini düşürür.

İade Prosedürü ve Müşteri Destek Şablonları: Uyum, İzlenebilirlik ve Maliyet Optimizasyonu

Helal iddiası içeren ürünlerde iade yönetimi, yalnızca lojistik bir süreç değil; uyum, kanıt yönetimi ve müşteri güveni bileşenlerinden oluşan bir yönetişim konusudur. Amaç; iade nedenlerinin doğru sınıflandırılması, kanıta dayalı değerlendirme, sertifika kapsamı ile tutarlı iletişim, çok dilli şablon standardı ve minimum temasla çözüm stratejisi ile maliyeti düşürüp memnuniyeti artırmaktır. Bu bölüm, politika mimarisi, süreç akışı, neden kodları, kanıt listesi, SLA’lar, otomasyon ve şablon kütüphanesi boyutlarıyla operasyonel bir çerçeve sunar.

1) Politika Mimarisi ve Kapsam

İade politikası üç katmandan oluşur: genel tüketici hakları (ülke bazlı yasal çerçeve), hijyen ve güvenlik istisnaları (açılmış gıda, kişisel bakım vb.) ve helal iddia ilişkili senaryolar (sertifika geçerliliği, yanlış varyant, pazar uyumsuzluğu). Metinler componentized tutulur: return_window, eligibility_rules, evidence_requirements, market_disclaimer. PDP, sipariş özeti ve destek makaleleri aynı kaynak metinlerden türetilir; dil varyantları TMS üzerinden sürümlenir.

2) Süreç Akışı ve Sorumluluk

Standart akış: Talep Açılışı → Otomatik Ön Değerlendirme → Kanıt Toplama → Uyum Kontrolü → Çözüm Kararı → Lojistik → Geri Bildirim. RACI: Destek (Sorumlu), Uyum/Kalite (Onay), Operasyon (Uygulayıcı), Ürün (Danışılan). Otomatik ön değerlendirme; sipariş no, ürün SKU/variant, piyasa (market), iade nedeni, foto/video ve doğrulama linki (cid) bilgilerini zorunlu kılar. Sertifika durumundaki Expired/Suspended/Revoked işaretleri triyafta önceliklendirme tetikler.

3) Neden Kodları ve Karar Matrisleri

Neden kodları veriye dayalı optimizasyon için normalize edilmelidir. Önerilen kod seti: QC-01 (Ambalaj hasarı), QC-02 (Sızıntı/bozulma), CL-01 (Helal claim anlaşılmadı), CL-02 (Pazar uyumsuz claim gösterimi), CL-03 (Sertifika doğrulanamadı), VX-01 (Yanlış varyant), INF-01 (Eksik içerik/alerjen bilgisi), DL-01 (Geç teslim). Her kod için çözüm tipi (iade, değişim, kısmi geri ödeme), kanıt eşiği (foto/video, doğrulama ekranı), maliyet merkezi ve SLA tanımlanır.

4) Kanıt Gereksinimleri ve Doğrulama

Helal iddiası kaynaklı şikâyetlerde kanıt listesi net olmalıdır: doğrulama ekran görüntüsü (/verify?cid=…), sertifika geçerlilik tarihleri, varyant SKU’su, paket üzerindeki QR’nın fotoğrafı, fatura ve lot bilgisi. Sistem; yüklenen görsellere EXIF kontrolü, QR–link checksum eşlemesi ve duplicate tespiti uygular. Eksik kanıt durumunda otomatik macro ile yönlendirme yapılır.

5) SLA’lar ve Eskalasyon

Önerilen SLA: T+4 saat ilk yanıt, T+24 saat nihai karar (kanıt tam ise), T+72 saat iade etiketinin üretilmesi ve müşteriye iletilmesi, T+7 gün bedel iadesi. Riskli senaryolar (sertifika statü değişimi, toplu yanlış varyant) için major incident protokolü devreye alınır; hukuk ve uyum ekipleri bridge çağrısına dahil edilir.

6) Lojistik ve Hijyen Protokolleri

Gıda ve kişisel bakım ürünlerinde iade kabul kriterleri stok sağlığına göre sınırlanabilir. Açılmış/bozulabilir ürünlerde resampling yapılmayacaksa no-return refund alternatifi değerlendirilir. Depoda helal uyumluluk açısından contamination-free alan ve quarantine prosedürü tanımlanır. İade gelen ürünlerin ayrıştırma kararları (imha, ikinci kalite, bağış) denetim iziyle kayda alınır.

7) Otomasyon, Makrolar ve Scripting

Destek araçlarında makrolar; dil, pazar ve neden koduna koşulludur. Makro mantığı: input (sipariş, sku, cid, market) → policy (eligibility) → output (metin, link, etiket). Otomatik verify-link ekleme, hreflang seçimi, RTL yön belirleme ve ticket tags standardize edilir. Riskli kelime ve mutlak iddia lint kontrolleri, gönderim öncesi metni tarar.

8) Çok Dilli İletişim Şablonları

Şablonlar sade ve kanıta referanslıdır. Tüm varyantlar TMS üzerinden yönetilir. Aşağıdaki örnekler, ton ve yapı için referanstır:

TR — Ön Yanıt (Talep Alındı)

“Talebinizi aldık. Sertifika doğrulaması için lütfen Sipariş No, Ürün SKU ve paket üzerindeki QR fotoğrafını paylaşın. Sertifika ekranını buradan açabilirsiniz: {verify_link}. İade koşulları ve kanıt listesi için: {policy_link}.”

TR — Nihai Karar (Onay)

“İade talebiniz {reason_code} kapsamında onaylandı. İade etiketi: {label_link}. Ürün bize ulaştığında yasal süreler içinde bedel iadesi yapılır. Sertifika ve pazar bilgisi için: {verify_link}.”

EN — First Response

“We received your request. To validate the halal claim, please share Order ID, SKU, and a photo of the package QR. You can open the certificate here: {verify_link}. Policy details: {policy_link}.”

AR — رد أولي

“لقد استلمنا طلبك. للتحقق من الشهادة، يرجى تزويدنا برقم الطلب، ورمز المنتج، وصورة QR على العبوة. يمكنك فتح الشهادة من هنا: {verify_link}. تفاصيل السياسة: {policy_link}.”

9) Bilgi Tabanı ve Self-Service

SSS makaleleri; how-to verify, eligible vs. ineligible returns, market-specific disclaimers, lot & QR guidance başlıklarını içerir. Makaleler PDP ve sipariş özetine bağlanır. Self-service akışında müşteri, neden kodu seçimi ve kanıt yükleme adımlarını tamamladığında otomatik karar alabilen senaryolarda anında onay alır.

10) Ölçümleme ve Sürekli İyileştirme

Çekirdek KPI seti: first-response time, resolution time, refund time, recontact rate, self-service çözüm oranı, claim-related return rate, yanlış anlama kaynaklı iade oranı. CL-01/02/03 trendi içerik ve doğrulama UX’ine geri beslenir. Aylık kök neden analizi ile politika metinleri ve şablonlar revize edilir.

Not: İade süreçlerinin şeffaf ve kanıta dayalı yürütülmesi, helal iddiasının güvenilirliğini korur ve gereksiz maliyetleri azaltır.

Pazar Yeri (Marketplace) Gereklilikleri: Politika Eşlemesi, Nitelik Haritalama ve Denetim İzi

Helal iddialarının pazar yerlerinde doğru, ölçülebilir ve policy-compliant biçimde yayınlanması; nitelik haritalama, kanıt bağlantısı, pazar-spesifik metin ve operasyonel denetim bileşenlerinin orkestrasyonunu gerektirir. Amaç; mağaza profilinde ve ürün seviyesinde helal verilerinin standart alanlara bağlanması, doğrulama link/QR entegrasyonunun kırılmadan sürdürülmesi, ülke/platform politikalarına uyumun otomatik kontrol edilmesi ve değişikliklerin denetim iziyle izlenebilir kılınmasıdır.

1) Mağaza Profili ve Yetkinlik Beyanı

Mağaza profilinde sertifika yetkinlik beyanı ve doğrulama URL alanı bulunmalıdır. Profil açıklamasında mutlak ifadelerden kaçınılır; “Kioscert doğrulamalı helal sertifikası kapsamında” çerçevesi kullanılır. Politika gereği platformun dinî hassasiyetlere ilişkin kuralları özetlenir ve help center makalesine yönlendirilir. Profildeki link, /verify?cid=…&market=… parametrelerini taşıyarak ölçümlenebilir hale getirilir.

2) Ürün Nitelik Haritalaması

Pazar yerlerinin ürün şemalarında helal iddiası için ya özel nitelik ya da genel sertifika alanı bulunur. PIM alanları aşağıdaki gibi haritalanır: certificate_guid → Certification ID, issuer_code → Certification Authority, valid_to → Validity, market_allowlist → Availability by Country, scope_code → Coverage. Nitelik bulunmuyorsa product description içinde kanıt bağlantısı metinsel ve erişilebilir formatta verilir. Haritalama tablosu sürüm kontrollü tutulur; platform nitelikleri değiştiğinde otomatik diff ile güncellenir.

3) Doğrulama Linki ve Görsel Metin Politikası

Birçok pazar yeri ürün görsellerinde metin kısıtı uygular. Helal rozetini görsele gömmek yerine PDP ve profil yönlendirmeli metin temelli kanıt tercih edilmelidir. Ürün açıklamasında tek tık doğrulama linki ve sertifika no’su yer alır. Paket fotoğrafı gerektiren platformlarda QR görünse dahi link ayrıca metin olarak sağlanır. alt-text alanlarında iddia tekrar edilmez, yalnızca ürün içeriği betimlenir.

4) Pazar Uyumu ve Koşullu Yayın

market_allowlist ve coğrafi sinyallerle koşullu yayın yapılır. Allowlist dışındaki ülkelerde helal claim’i gizlenir, açıklamada general food compliance metni kalır. Platformun yerel dil zorunluluğu varsa çeviri TMS üzerinden çekilir. GCC, Malezya ve Endonezya varyantları için tanınan otorite referansları kısa ve kanıta dayalı biçimde verilir.

5) Politika Kapısı ve Otomatik Kontroller

Yayın pipeline’ında üç aşamalı kontrol uygulanır: (i) içerik linter — mutlak iddia, üstünlük, yanıltıcı sağlık söylemi taraması; (ii) nitelik doğrulama — zorunlu alanların doluluğu, cid/ver tutarlılığı, valid_to tarihi; (iii) pazar kuralı — ülke bazlı kısıtlar ve dil zorunluluğu. Hata durumunda yayın block olur, triayj kaydı açılır ve pre-publish raporunda alan bazında geri bildirim üretilir.

6) İçerik Şablonları ve Microcopy

Platform açıklama alanları için standart bloklar tanımlanır: Helal Sertifika Özeti (sertifika no, geçerlilik, doğrulama linki), Bileşen/Alerjen Özeti, Pazar Uyum Notu, Doğrulama CTA (metinsel). Sıkı karakter limitlerinde kısa varyant kullanılır. Bağlantı metinleri açık ve eylem odaklıdır: “Sertifikayı Doğrula”. Keyword stuffing yapılmaz; kapsam cümleleri kanıt referanslıdır.

7) Feed Yönetimi ve Diferansiyasyon

Tüm pazar yerleri tek bir master feed’den değil, pazar başına farklılaştırılmış feed’lerden beslenmelidir. Farklılaştırma; nitelik adları, alan limitleri, dil, metin tonları ve görsel kurallarına göre yapılır. Feed generator PIM olaylarından tetiklenir; değişiklikler delta olarak gönderilir. Hata geri dönüşleri error registry’de kategorize edilir ve otomatik düzeltme önerileri üretir.

8) Ölçümleme ve Denetim İzi

Temel metrikler: listing approval rate, policy violation rate, verify_click_rate (platform referanslı), CTR, add-to-cart, return rate by claim code. Tüm feed gönderimleri ve içerik değişiklikleri immutable audit log’a yazılır. Sertifika statü değişimlerinde otomatik bulk update yürütülür ve maruziyet penceresi (expired exposure) raporlanır.

9) Müşteri Mesajları ve SSS

Platform içi mesajlaşmada hazır makrolar kullanılır: “Sertifikayı nasıl doğrularım?”, “Hangi ülkelerde helal claim’i gösteriliyor?”, “Varyantım kapsamda mı?”. Cevaplar doğrulama linki ve pazar notlarına referans verir. İade durumlarında “kanıt listesi” istenir ve self-service akışına yönlendirilir.

10) Operasyon ve RACI

Roller: Marketplace Ops (feed ve yayın), Uyum/Hukuk (metin ve pazar onayı), Ürün Bilgisi (PIM doğruluğu), IT/Platform (entegrasyon ve izlenebilirlik), Destek (makrolar ve SLA). Haftalık listing review oturumları ve aylık compliance & performance panosu zorunludur.

Not: Bu yönetim modeli, platform cezalarını önler, helal iddiasının kanıt erişimini standardize eder ve dönüşüm kaybı olmadan uyumu garanti eder.

Rakip Sayfa Benchmark’ı: Helal İddialarında Kıyaslama, Ölçüm ve Farklaştırma

Helal odaklı ürün sayfalarının rekabetçi analizi, yalnızca görsel yerleşimlerin karşılaştırılması değildir; claim mimarisi, kanıt erişimi, pazar uyumu ve dönüşüm etkisi gibi çok boyutlu bir çerçeve gerektirir. Bu bölüm, Kioscert standardı ile rakip PDP/landing akışlarını sistematik biçimde kıyaslamak; boşlukları, kopyalanabilir iyi uygulamaları ve non-negotiable uyum maddelerini görünür kılmak için operasyonel bir benchmark metodolojisi sunar.

1) Kapsam ve Örneklem Seçimi

Benchmark çalışması, üç katmanda yürütülmelidir: doğrudan rakipler (aynı kategori ve pazar), komşu sektör örnekleri (gıda-dışı ancak sertifikasyon iddiası olan markalar) ve pazar yeri vitrinleri (aynı ürünün marketplace varyantları). Her katman için en az 10 sayfa örneği belirlenir; masaüstü/mobil ayrı oturumlarla taranır. Analiz penceresi 30 gün olarak sabitlenir; önemli versiyon değişiklikleri changelog ile kayda alınır.

2) Değerlendirme Matrisi ve Puanlama

Aşağıdaki boyutlar 0–2 bandında puanlanır ve ağırlıklandırılır:

A) Claim Görünürlüğü (A1: buy box yakınında kısa özet, A2: sertifika no/issuer, A3: tek tık doğrulama CTA)

B) Kanıt Erişimi (B1: link/QR tutarlılığı, B2: latest-valid yönlendirmesi, B3: arşiv sürüm şeffaflığı)

C) İçerik Şeffaflığı (C1: bileşen/alerjen kaynağı, C2: varyant kapsam uyarıları, C3: lot/izlenebilirlik)

D) Çok Dillilik ve Pazar Uyumu (D1: dil anahtarı, D2: market disclaimer, D3: hreflang/meta)

E) Erişilebilirlik (E1: buton metinleri, E2: aria/odak sırası, E3: RTL desteği)

F) Performans (F1: LCP hedefi, F2: kritik CSS, F3: görsel ağırlığı)

G) Dönüşüm Mimarisi (G1: CTA hiyerarşisi, G2: güven sinyali yakınlığı, G3: itiraz kırıcı SSS)

Ağırlık önerisi: A=0,2; B=0,2; C=0,15; D=0,15; E=0,1; F=0,1; G=0,1. Toplam skor 100 üzerinden normalize edilir. Eşik altı alanlar “kritik uyum boşluğu”, orta segment “fırsat”, üst segment “güçlü uygulama” olarak etiketlenir.

3) Veri Toplama ve Enstrümantasyon

Her sayfa, ekran kaydı ve DOM snapshot ile arşivlenir. Doğrulama linkleri headless tarayıcıyla açılarak HTTP 20x/30x durumları, canonical ve meta etiketleri, hreflang, schema.org alanları çekilir. QR görselleri base64’e çevrilir ve PDP’deki link ile checksum kıyasına tabi tutulur. Mobil deneyimde tap-target boyutu ve okuma sırası kaydı tutulur. Ziyaretçi verisi toplanmaz; yalnızca herkese açık içerik ölçülür.

4) Rakip Desenleri ve Anti-Desenler

Analizde tipik desenler: “rozet + kısa metin + doğrulama” yakın yerleşimi, market bazlı disclaimer akordiyonu, bileşen listesinde kaynak/istisna etiketleri. Anti-desenler: görsele gömülü iddia, çalışmayan doğrulama linki, expired belgeye sessiz maruziyet, keyword stuffing ve mutlak iddialar. Anti-desenler policy risk olarak işaretlenir ve örnek ekran görüntüleriyle birlikte vaka defterine eklenir.

5) Farklaştırma Olanakları

Kioscert yaklaşımını ayrıştıracak kaldıraçlar:

i)Latest-valid otomatik yönlendirme ve arşiv sürüme şeffaf erişim,

ii) Varyant kapsam göstergesiyle siparişte yanlış seçim riskini azaltan uyarı,

iii) Pazar allowlist’e göre koşullu render ve uygun meta yapı,

iv) Server-side ölçümlenen verify → add-to-cart hunisi,

v) Erişilebilir, metin-merkezli güven sinyalleri ve aria etiketli CTA’lar.

6) Çıktı Formatı ve Karar Çerçevesi

Benchmark raporu üç eser üretir: Skor Tablosu (sayfa başına alt kırılımlar), Vaka Galerisi (iyi uygulama/anti-desen ekran görüntüleri) ve Eylem Listesi (hemen uygulanabilir iyileştirmeler). Her eylem maddesi; etki (dönüşüm/uyum), efor (gün/kişi), bağımlılık (PIM/IT/Legal) ve hedef metrik alanlarını içerir. RICE veya ICE metoduyla önceliklendirme yapılır.

7) Örnek Eylem Öğeleri

E1: Buy box çevresinde “Sertifikayı Doğrula” CTA’sını birincil buton hiyerarşisine yükseltmek. Hedef: verify_click_rate +%20.

E2: Sertifika no/issuer bilgilerini kısa özet içinde, linke yakın konumlandırmak. Hedef: yanlış anlama kaynaklı destek taleplerinde -%15.

E3: Varyant kapsam uyarısını SKU seçiciyle bağlamak. Hedef: yanlış varyant iadelerinde -%25.

E4: Market allowlist dışındakilere rozet gizleme + disclaimer gösterimi. Hedef: policy violation rate ≤%0,5.

E5: Arşiv sürüm bağlantısını doğrulama ekranına eklemek. Hedef: güven algısı ve şeffaflık anket skorlarında artış.

8) Yönetişim, Sıklık ve Sahiplik

Benchmark, iki ayda bir tekrarlanır. Sahiplik: Ürün (metodoloji), Uyum (policy/market kontrolü), İçerik (metin ve microcopy), IT/Platform (ölçümleme ve arşiv). Özet bulgular compliance & conversion kurulunda sunulur; onaylanan eylemler quarterly roadmap’e alınır.

Not: Bu benchmark, estetik karşılaştırmadan çok, kanıt erişimi ve uyum temelli dönüşüm farkını ölçer; kopyalanabilir değil, ölçeklenebilir pratikleri önceler.

Dönüşüm Odaklı Yerleşim: CTA Mimarisi, Güven Sinyalleri ve Kanıt Yakınlığı

Dönüşüm mimarisi; niyet-aligned CTA, kanıt yakınlığı ve bilişsel yük yönetimi ekseninde kurgulanmalıdır. Hedef, helal iddiasını satın alma karar noktalarına en kısa yoldan bağlamak, doğrulama eylemini sürtünmesiz kılmak ve şüphe anlarını just-in-time mikro içeriklerle çözmektir. Bu bölüm, buy box çevresi, bilgi akordiyonları, mobil “sticky” alanlar ve checkout hattında uygulanacak minimal ama yüksek etkili yerleşim prensiplerini tanımlar.

1) Buy Box Çevresi: Birincil CTA ve Kanıt Yakınlığı

Birincil CTA “Sepete Ekle” kalır. Helal odaklı ikincil CTA “Sertifikayı Doğrula” aynı görsel hiyerarşide, yakın alan mesafesi ≤120px olacak şekilde konumlanır. CTA metni eylem odaklıdır, ikincil buton stiliyle ayrıştırılır. Yanında kısa kanıt özeti bulunur: sertifika no, geçerlilik bitişi, issuer kodu. Link, cid/ver/market parametreleriyle deep-link çalışır. Bu yakınlık, şüpheyi azaltır ve sepet eklemesine net katkı sağlar.

2) Ürün Özellikleri ve Akordiyon Yapısı

“Helal Sertifika Özeti”, “Bileşen ve Alerjen”, “Pazar Uyum Notu” akordiyon başlıkları altında gruplanır. Başlık kopyaları kısa ve taranabilir: “Helal Sertifika: {CID} · {valid_to}”. İçerikte mutlak iddia yoktur; kapsam referansı ve istisnalar net yazılır. Akordiyon açıldığında üst çubukta minyatür doğrulama CTA’sı görünür. Akordiyon sırası, kullanıcı niyetine göre yapılandırılır: bileşen listesi yüksek etkileşim alıyorsa ilk sıraya alınır.

3) Mobil Yerleşim ve Sticky Katman

Mobilde alt “sticky bar” iki eylem taşır: Sepete Ekle ve Sertifikayı Doğrula. Sticky bar yükseklik sınırlı, odak halkaları erişilebilir, etiketler iki kelimeyi geçmez. Scroll derinliği belirli eşiği aştığında kısa güven mesajı görünür: “Kioscert doğrulamalı helal sertifikası kapsamında”. RTL dillerde bar yönü ve odak sırası uyarlanır.

4) İtiraz Kırıcı Mikro İçerik

Tipik itirazlar: “Gerçekten helal mi?”, “Varyantım kapsamda mı?”, “Hangi ülkelerde geçerli?”. Her itiraz için 140–180 karakterlik mikro kopya ve tek tık link tanımlanır. Örnek: “Varyant kapsamı SKU seçicide yazıyor. Detay”. Bu bloklar SEO amaçlı değil, karar desteği amaçlıdır.

5) Güven Sinyali Tasarımı

Görsel rozet yerine metin-merkezli sinyal tercih edilir. Metin formatı: “Helal sertifikası geçerli · {valid_to} · Doğrula”. Sertifika sağlayıcı logosu, erişilebilirlik ve marka tutarlılığı nedeniyle opsiyoneldir; kullanılırsa alt metni bilgilendirici olmalıdır. Sayfada çoklu güven sinyali çoğaltılmaz; tek kaynak kuralı uygulanır.

6) Checkout ve Sepet

Sepet özetinde kısa helal özeti tekrar edilir ve doğrulama linki erişilebilir durumda kalır. Checkout’ta dikkat dağıtacak ek modül yoktur. İade politikası mikro kopyası görünür: “Helal iddiası ile ilgili sorular için doğrulama ekranını kullanın.” Linkler yeni sekmeye değil aynı sekmeye açılır; dönüş akışı bozulmaz.

7) Performans ve Erişilebilirlik İlkeleri

CTA’lar tap-target ≥44px, kontrast WCAG AA, odak sırası mantıklı. LCP hedefi ≤2,5 s. CTA metinleri temiz Türkçe/EN/AR varyantları ile sağlanır. Ekran okuyucu etiketleri eylemi ve sonucu açıklar: “Sertifikayı Doğrula, yeni sayfada sertifika durumu”. Script yükü minimal tutulur.

8) Deney Tasarımı ve Ölçüm

Test eksenleri: CTA yakınlığı, mikro kopya var/yok, akordiyon sırası, sticky bar görünürlük eşiği. Başlıca metrikler: verify_click_rate, pdp_to_cart, checkout_start, conversion, claim-related support rate. Analiz server-side olaylara dayanır. Anlamlılık öncesi durdurma yapılmaz; SRM kontrolü zorunludur.

9) Negatif Senaryo Yönetimi

Sertifika statüsü Expired/Suspended/Revoked ise helal sinyali otomatik gizlenir, CTA “Bilgilendirme” metnine döner. Buy box yakınında kısa açıklama görünür ve kullanıcı doğrulama ekranına yönlendirilir. Bu mod, yanlış güven hissini engeller ve marka riskini azaltır.

10) Bileşen Kütüphanesi ve Tutarlılık

CTA ve güven sinyali bileşenleri tasarım sisteminde tekil olarak tanımlanır. Varyantlar (boyut, dil, pazar) tokens üzerinden yönetilir. PDP, landing ve e-posta şablonları aynı bileşeni tüketir; metinler TMS’den çekilir. Böylece mesaj tutarlılığı ve bakım maliyeti kontrol altında kalır.

Not: Bu yerleşim standardı, ikna anını kanıtla aynı hizada tutar; gereksiz görsel karmaşadan kaçınır ve karar yolunu kısaltır.