Cihaz uyumluluk filtrelerinin elektronik aksesuar mağazalarında telefon nesillerini modellemeye ve hatalı satın almaları ölçekli olarak engelleyen arama deneyimleri oluşturmanıza nasıl yardımcı olduğunu öğrenin.

"Uyumluluk" tek bir evet veya hayır değildir. Bir aksesuar mağazasında, bir ürünün müşterinin cihazının tam şekline, bağlantılarına ve özelliklerine yeterince uyduğunu ve beklendiği gibi çalışacağını ifade eder.
Fiziksel uyum gerektiren ürünlerde küçük bir fark bile oturmayı bozabilir. Telefon kılıfı veya ekran koruyucu, gövde boyutu, köşe yarıçapı, kamera çıkıntısı düzeni, düğme yerleşimi ve hatta hoparlör veya mikrofon delikleri gibi ayrıntılara bağlıdır. Bir montaj aparatı, cihazın nereden güvenli şekilde sıkıştırılabileceğine ve kameranın boşluğa ihtiyaç duyup duymadığına bağlıdır.
Güç ve bağlantıda "çalışma" düzeyleri vardır. Bir şarj cihazı telefonu besleyebilir ama ilan edilen hızda şarj etmeyebilir. Bir kablo şarj edebilir ama veri taşımaz veya hızlı şarj standartlarını desteklemeyebilir. Kablosuz şarjda ise bobin yerleşimi, kılıf kalınlığı ve mıknatıs hizalanması önemlidir.
Uyumluluk genellikle aksesuar türüne göre şöyle farklanır:
Yanlış satın almalar, cihaz isimlerinin dağınıklığı yüzünden olur. Müşteriler "Plus" ile "Pro"yu karıştırır, aynı isimli farklı nesilleri karıştırır veya bir aksesuarın tüm seriye uyduğunu varsayar. Bölgesel varyantlar ve operatör modelleri bile boyutları veya bantları değiştirebilir; küçük bir kamera çıkıntısı değişikliği bile eski bir kılıfı işe yaramaz hale getirebilir.
Cihaz uyumluluk filtrelerinin hedefi basittir: daha az iade, daha az destek talebi ve çabuk ve kendinden emin alışveriş yapan müşteriler.
Önce telefonlarla başlayın. Onlar en yüksek hacmi ve en çok yakın kaçırmayı sürükler. Yaklaşım stabil olunca aynı mantığı tabletler, dizüstüler ve giyilebilir cihazlara da genişletin; aynı isimlendirme ve nesil sorunları yine ortaya çıkar.
İyi cihaz uyumluluk filtreleri bir kuralla başlar: aksesuarın uyup uymadığını belirleyen gerçekleri yakalayın, insanların kullandığı pazarlama isimlerini değil.
Çoğu aksesuar için "olmazsa olmaz" uyumluluk sinyalleri şunlardır:
Zor vakalar genellikle veri problemi değil isimlendirme problemidir. "Plus/Pro/Max/Ultra" farklı cihazlardır. Bölgesel isimler ve operatör sürümleri farklılık gösterebilir; başlıkta aynı görünseler bile bunları birer takma ad olarak tek bir temiz cihaz kaydına bağlayın, ayrı "neredeyse aynı" girdiler gibi davranmayın.
Ayrıca uyum (fitment) ile özellik uyumluluğu (feature compatibility) ayrımını yapın. "Uyar" fiziksel olarak hizalanması ve hiçbir şeyi engellememesi demektir. "Çalışır" ise hızlı şarj desteği, veri aktarım hızı veya manyetik hizalanma gibi özellikleri kapsar. Bir kablo belirli bir telefonla "çalışabilir" ama hızlı şarj etmez; bir kılıf "uymakla" beraber bir kamera kontrol düğmesini engelleyebilir.
Ürün sayfasında neyi vaat edeceğinize karar verin. Eğer hızlı şarj wattajını doğrulayamıyorsanız "şarj eder" deyin, "hızlı şarj eder" demeyin. Yalnızca bazı modellerde test ettiyseniz "şu modellerde doğrulandı" yazın; diğerlerini "rapor edilen uyumluluk" olarak etiketleyin veya hiç göstermeyin. Bu netlik iadeleri ve kötü yorumları engeller.
Binlerce SKU ve yüzlerce cihaz olduğunda e-tablolar kırılmaya başlar; çünkü "Galaxy S21" gibi tek bir dağınık isim birden çok nesil, bölge ve boyut anlamına gelebilir. Ölçeklenebilir model, "cihazın ne olduğunu" ile "aksesuarın neyi desteklediğini" ayırarak başlar.
Küçük, tek işi yapan tablolar halinde düşünün:
Sonra her aksesuar SKU'sunu desteklenen bir DeviceVariant ile ilişkilendiren CompatibilityRule (veya CompatibilityMap) gibi bir eşleme katmanı ekleyin. Bu, kesin filtreler, hızlı QA ve "bu uyacak mı?" sorusuna güvenilir bir cevap sağlar.
Veriyi tutarlı tutmak için serbest metin yerine yapılandırılmış sürümlemeyi saklayın: generation, release_year ve size_class gibi alanlar "14 serisi"ne göre her zaman daha iyidir. Aynı isim iki cihaz arasında paylaşılıyorsa release_year gizli uyumsuzlukları önler.
Son olarak, her kurala kısa bir "neden" saklayın ki destek ve ticaret ekipleri kararları açıklayabilsin ve hataları görebilsin: örn. konnektör türü (USB-C vs Lightning), boyutlar, kamera kesiti şekli veya düğme düzeni.
Basit bir senaryo: "iPhone 14 Pro"ya uyan ama "iPhone 14"e uymayan bir kılıf. DeviceVariant + CompatibilityRule ile filtre yalnızca Pro varyantını gösterir ve destek ekibi neden olarak "farklı kamera modülü boyutu" görebilir.
Uyumluluğu modellemenin iki yaygın yolu vardır: açık eşleme ve kural tabanlı eşleme. Gerçek ürün hatları asla mükemmel tutarlılık göstermediği için çoğu mağaza her ikisini de kullanır.
Açık eşleme, her SKU'nun desteklediği cihazların bir listesinin olduğu modeldir (ve bazen desteklemediği cihazların da listesi vardır). Bu, anlaşılması kolaydır ve cüzdanlı kılıflar, dayanıklı kılıflar, kamera lens koruyucuları veya garip port düzenine sahip şarj cihazları gibi zor uyum gerektiren ürünler için mükemmeldir. Dezavantajı bakım yüküdür: her yeni telefon çıktığında ek satırlar eklemelisiniz.
Kural tabanlı eşleme ise "iPhone 13 ailesi" veya "USB-C" gibi paylaşılan aileler veya özellikler kullanır ve uyumluluğu aileye bağlar. Fiziksel şekil ve kesitler gerçekten paylaşılıyorsa (ör. yakın varyantlarda ekran koruyucular veya konnektör türüne göre aksesuarlar) bu iyi çalışır.
Pratik karışım şöyle görünür:
Paketler (bundle) ayrı kontroller ister. "Kılıf + ekran koruyucu" paketi yalnızca her iki ürün de seçilen cihazla uyumluysa gösterilmelidir. Eğer biri uymazsa paket uyumsuz sayılmalıdır.
Uyumluluk filtreleri bunun üzerinde kurulduğunda kurallar kataloğu düzenli tutar ve açık geçersiz kılmalar nadir ama maliyetli yanlış satın almaları engeller.
Aynı cihaz kataloğunuzda beş isimle yer aldığında uyumluluk çöker. Her cihazı kararlı bir iç kimlikle, bir kanonik gösterim adıyla ve müşterilerin gerçekten yazdığı takma adlar kümesiyle bir kayıt olarak ele alın. Uyumluluk filtrelerinizin doğruluğu bu katmana bağlıdır.
Pratik bir desen: netlik için kanonik isim (filtrelerde gösterilecek) ve eşleştirme için takma adlar (arama ve aktarımlar için kabul edilen). Örneğin, gösterimde "iPhone 13 Pro Max" kullanın, ama "13 Pro Max", "iPhone13 ProMax", "A2644" veya operatör varyantları gibi takma adları kabul edin.
İsimleri nesiller ve bölgeler arasında tutarlı tutun. Depolama boyutunu, bağlantıyı ve bölge kodlarını nasıl yazacağınızı kararlaştırın ve ona bağlı kalın. Eğer depolama kılıf uyumunu etkilemiyorsa, bunu cihaz adında kodlamayın; ayrı bir öznitelikte tutun ki cihaz listesi çoğalmasın.
Yeni cihazlar küçük, tekrarlanabilir bir süreçle sisteme girmelidir. Bir sahip atayın (genellikle merch ops veya katalog ops), bir takvim belirleyin (çıkış günü artı haftalık gözden geçirme) ve filtrelerde seçilebilir olmadan önce kısa bir kontrol listesi zorunlu kılın.
Yeni bir cihaz yayınlamadan önce şu kontrolleri çalıştırın:
Koder.ai ile kurarsanız, bu doğrulamaları basit yönetim formları ve otomatik kontroller olarak uygulayabilirsiniz; ardından kötü bir aktarım takıldığı takdirde anlık görüntülerle geri alabilirsiniz.
Yanlış satın almaları azaltmanın en hızlı yolu, ürünü göstermeden önce alışveriş yapanın cihazını sormaktır. Kılıflar, ekran koruyucular ve lens koruyucular gibi ürünler için basit bir "Cihazınızı seçin" adımı bağlamı ayarlar ve insanların karanlıkta alışveriş yapmasını engeller.
Cihaz seçildikten sonra filtreler rehberlik eden bir yol gibi davranmalı, uzun bir kontrol listesi gibi değil. İyi bir desen: her seçim bir sonraki seçenek kümesini yalnızca geçerli olanlarla daraltır: marka, sonra aile (serisi), sonra model, sonra nesil veya boyut. Birisi "Galaxy S" seçerse iPhone-özel aileleri görmemeli. "iPhone 15" seçildiyse "iPhone 15 Pro Max" boyutlarını görmemeli.
Uyumluluk filtrelerini güvenli hissettiren pratik kurallar:
Boş sonuç ekranları önemlidir çünkü orası kafa karışıklığının iade ile sonuçlandığı yerdir. Hiçbir ürün uymuyorsa ölü bir "0 sonuç" sayfası göstermeyin. Nedenini açıklayın ve bir sonraki adım önerin: "iPhone 14 Pro (6.1) ile eşleşen kılıf yok. iPhone 14 (6.1) deneyin veya cihaz seçimini temizleyin." Kataloğunuz eksikse bunu açıkça söyleyin ve "beni haberdar et" veya "daha sonra kontrol et" gibi seçenekler sunun.
Örnek: bir müşteri "iPhone 14 kılıfı" arar ama aslında iPhone 14 Pro sahibidir. Seçim yaptıktan sonra sonuçlar anında iPhone 14-özel kılıfları kaldırır ve "sadece uyumlular" açıkken yanlış bir eşleşmeyi sepete eklemelerini engeller. Bu, cihaz uyumluluk filtrelerinin temel işidir: yanlış öğelerin iyi bir fikir gibi görünmesini engellemek.
Alışveriş yapanlar SKU düşünmez. "Pixel 8 için şarj cihazı" veya "iPhone 15 Pro Max kılıfı" yazarlar. İyi arama, cihazı ve aksesuar niyetini anlar ve yalnızca uyan öğeleri döndürür.
Bunu hızlı yapmak için arama motorunuza iki şeyi indeksleyin: ürün öznitelikleri (kategori, konnektör türü, wattaj, renk) ve uyumluluk ilişkileri (hangi cihazlara uyar). Uyumluluğu sonradan hesaplanan bir şey yerine kendi aranabilir alanı gibi ele alın. Bu, cihaz uyumluluk filtrelerinin anlık hissettirmesini sağlar.
Pratik yaklaşım: normalize edilmiş bir uyumluluk haritasını veritabanınızda saklayın, ardından her ürün için arama indeksine genişletilmiş "cihaz tokenleri" alanı yayınlayın. İnsanların yazdığı yaygın isimleri dahil edin (marka, model, nesil, boyut) ki "Pixel 8", "Google Pixel 8" ve "G9BQD" aynı cihaza çıksın.
Çok fazla cihaz varyantı varsa arama zamanında derin join'ler yapmaktan kaçının. Önbelleğe alın:
Bilinmeyen cihazlar için tahminde bulunup yanlış satın alımlara yol açmayın. Bunun yerine yardımcı geri dönüşe geçin: konnektörü (USB-C, Lightning) sor, ana ölçüleri (ekran boyutu, kılıf yüksekliği) isteyin veya destek akışı izin veriyorsa port etiketinin fotoğrafını isteyin. Ardından küçük bir "muhtemel eşleşmeler" seti gösterin, açık uyarılarla ve ödeme öncesi cihazı onaylama istemiyle.
Yanlış satın almaların çoğu müşterinin ürünü "bulduktan" sonra olur. Ürün sayfası ve sepet son savunma hattınızdır; uyumluluğu dipnot değil birincil bir gerçek olarak ele alın.
Fiyat ve "Sepete ekle" düğmesine yakın açık bir durum gösterin: Uyumlu, Uyumsuz veya Bilinmiyor. "Bilinmiyor" tahmin yapmak yerine daha iyidir; ama bununla birlikte bir sonraki adımı sunun: alışveriş yapanın cihazını seçmesini isteyin.
Sadece "uymak" demeyin. Günlük terimlerle neden uyduğunu söyleyin: "USB-C konnektör", "iPhone 14 (6.1 inç) uyar", "MagSafe ile çalışır" veya "3.5 mm kulaklık jakı gerekir" gibi. Bu aynı zamanda uyumluluk filtrelerinin faydasıdır: filtreleri besleyen veri kısa, insan açıklamaları üretir.
Basit bir desen işe yarar:
Ürün sayfasında ve sepette küçük bir "Başka cihaz kontrol et" kontrolü ekleyin. Cihaz değiştirildiğinde sepet öğelerini koruyun, ama uyumluluğu yeniden kontrol edip artık uymayanları işaretleyin.
Sepette sorunları küçük uyarıların arkasına saklamayın. Eğer bir öğe Uyumsuz ise ödeme engellenmelidir; öğe kaldırılana veya cihaz seçimi değişene kadar devam etsin. Eğer Bilinmiyor ise, müşteri onay verirse ödemeye izin verin (basit bir onay kutusu) ve riski açıkça belirtin.
Çapraz satışları dikkatle yönetin. Müşteri "iPhone 14" seçtiyse sadece o seçimle eşleşen ürünleri önerin. "Müşteriler ayrıca şunu aldı" widget'ı cihaz bağlamını göz ardı ederse sessizce iadeler yaratır.
Çoğu yanlış satın alma müşterilerin hatası değildir. Verinin belirsiz olduğu veya mağaza UI'sının "yeterince yakın" seçeneği teşvik ettiği durumlarda olur.
Yaygın hata marketing isimlerine güvenganmaktır. "iPad Air" veya "Galaxy S" benzersiz cihaz değildir. Nesil, çıkış yılı ve ekran boyutu gibi kararlı alanlara ihtiyaç vardır. Bunlar yoksa açılır listede aynı görünen ama farklı uyan ürünleri karıştırırsınız.
Benzer bir tuzak, aynı ismi paylaşan varyantları birleştirmektir. Aynı ailede birden fazla boyut, kamera çıkıntısı veya konnektör değişikliği olabilir. Veri modeliniz varyantları ifade edemezse, müşteriler "cihaza uyar" görünen ama kendi cihazlarına uymayan bir kılıf görür.
Filtreler ayrıca sıfır sonuç veren seçimler sunduğunda yanıltıcı olabilir. Müşteriler boş bir sayfayı "site bozuk" olarak algılar ve filtreleri genişletmeye başlar; yanlış olanı bulsalar bile bu iadeye yol açar. İyi filtreler imkansız kombinasyonları gizler ve insanları geçerli eşleşmelere yönlendirir.
Uyumluluk nadiren basit bir evet/hayırdır. "iPhone ile çalışır" ifadesi, gerçek karar hızlı şarj wattajı, USB-C Power Delivery profilleri, MagSafe hizalanma gücü veya bir kablonun veri ve video taşıyıp taşımadığı gibi ayrıntılara bağlıysa yetersiz kalır. Bunları isteğe bağlı notlar yerine yapılandırılmış öznitelikler olarak ele almak iadeleri azaltır.
Takımlar sessiz değişikliklerden de zarar görür. Birisi bir uyumluluk kuralını düzenleyip denetim kaydı bırakmadıysa iade artışının nedenini açıklayamazsınız.
Hızlı bir kontrol için sorun arayın:
Örnek: müşteri "iPad Air" seçer ve kılıf alır. Seçicide nesil sorulmazsa 10.9 inç için olan kılıfı alabilir ama müşterinin eski 10.5 inç modeli olabilir. Basit bir nesil adımı bu eşleşmeyi sepet aşamasına gelmeden engeller.
Yeni bir telefon çıktığında hedefiniz basit: müşteriler cihazlarını saniyeler içinde seçebilmeli ve uyumsuz aksesuarları görmemelidir. Her seferinde yapılan küçük bir rutin kataloğunuz büyürken uyumluluğu doğru tutar.
Yeni aksesuarlar da aynı disipline ihtiyaç duyar. Hata, uyumluluğu sonradan düzeltmek yerine sonradan ele alınmasıdır.
Hızlı QA için birkaç örnek arama yapın ("iPhone 15 Pro kılıfı", "Galaxy S24 kablo"), her marka için iki filtre yoluna tıklayın ve uyumlu ile uyumsuz bir öğeyi sepete ekleyip uyarıların göründüğünden emin olun. "Bu uyarır mı" veya "uyumlu değil" etiketli iadelerde ani artışlar, genellikle eksik bir takma ad veya bozuk bir kural anlamına gelir.
Destek ekibi müşteriden tam model adını, gerekliyse bölge/model kodunu, donanımı etkiliyorsa depolama bilgisini ve müşterinin kalın bir koruyucu kılıf kullanıp kullanmadığını (kablosuz şarj ve bazı montajları etkileyebilir) sormalıdır. 20 saniyelik bir onay, bir iadeden daha iyidir.
Bir müşteri "iPhone 13 için kılıf" yazar. Mağaza kılıf ızgarasını gösterir; ama ilk güvenlik ağı sonuçlardan önceki küçük cihaz seçicidir: "Tam modelinizi seçin".
Müşteri "iPhone 13 Pro"yu seçer. Sonuçlar anında güncellenir ve artık uymayan öğelerde kısa bir not görünür: "iPhone 13 Pro ile uymaz (kamera çıkıntısı farkı)". Eğer müşteri yine de uyumsuz bir kılıf seçerse, ürün sayfası ana "Sepete ekle" butonunu cihazı onaylayana kadar bloke eder. Bu adım, temel hatayı yani base model ile Pro modelini karıştırmayı engeller.
Başka bir müşteri şarj cihazı alıyor. Şarj cihazı birçok telefonla "çalışır" ama müşteri hızlı şarj istiyor. Ürün sayfasında "Çalışır" ve "Hızlı şarj" açık iki satıra ayrılır. Müşteri "Galaxy S22"yi seçince sayfa "Çalışır: Evet" ve "Hızlı şarj: Hayır (bu cihazda 10W ile sınırlı)" gösterir. Sepet aynı etiketleri tekrarlar, böylece fiş uyarınca sadece prize uymak hızlı şarj sağladığı anlamına gelmez.
Bir hafta sonra yeni nesil çıkınca yüzlerce ürüne tek tek yeni modeli eklemek yerine sisteminiz bir kural kullanır: "USB-C PD şarj cihazları PD 3.0 destekleyen 20W+ cihazları hızlı şarj eder". "iPhone 16" eklendiğinde doğru şarj davranışını miras alır; yalnızca istisnalar manuel inceleme gerektirir. İşte kural tabanlı eşleme ve cihaz uyumluluk filtreleri gerçek zaman kazandırır.
Bu korumaları mümkün kılan veriler:
Hata dört noktada önlendi: aramadaki cihaz seçimi, filtrelenmiş sonuçlar, sepete ekleme doğrulaması ve ödeme öncesi son sepet kontrolü.
Yayılım, uyumluluğu tek seferlik bir veri aktarımı değil bir ürün özelliği olarak ele aldığınızda daha iyi işler. Küçük başlayın, yanlış satın almaların azaldığını kanıtlayın, sonra tekrarlanabilir bir süreçle genişletin.
Pratik aşama planı:
İşin işe yarayıp yaramadığını anlayabilmek için kısa bir metrik setini izleyin. Amaç, önlenebilir iadelerin ve "bu uyar mı?" anlarının azalmasıdır.
Haftalık takip edin:
Bakım çoğu ekibin geride kaldığı kısımdır. Haftalık rutin belirleyin: satıcı güncellemelerini alın, cihaz kataloğunuzla karşılaştırın ve yeni istisnaları gözden geçirin (örn. isimler yakın görünse de iPhone 15 kılıfının iPhone 15 Pro'ya uymadığı durumlar). Belirsiz SKU'lar için küçük bir "karantina" listesi tutun.
Hızlı ilerlemek isterseniz, Koder.ai uyumluluk veri modelini prototiplemenize ve cihaz farkındalıklı filtreler ile arama inşa etmenize yardımcı olabilir; planlama modunda gereksinimleri görüşerek başlayabilirsiniz. Hazır olduğunuzda kaynak kodunu dışa aktarır ve uygulamayı sahiplenirsiniz.