Site İçi Arama Optimizasyonu: E-Ticaret Arama Motorunu Türkçe İçin Doğru Kurmak

Bir e-ticaret sitesinde ziyaretçilerin çoğu kategori sayfalarında dolaşır, filtre uygular, geri döner. Arama kutusuna yazan ziyaretçi ise farklı bir şey yapar: ne istediğini kelimelerle söyler. Bu, sitedeki en açık niyet beyanıdır. Sektörde genel kabul gören gözlem, arama kullanan ziyaretçilerin dönüşüm oranının siteyi yalnızca gezerek kullananlardan belirgin biçimde yüksek olduğu yönündedir. Mekanizma da mantıklıdır: kişi zaten bir ürün ya da ürün tipi düşünerek gelmiştir, tek beklentisi onu görmek.

Buradan çıkan sonuç rahatsız edici: arama kutunuz kötüyse, en değerli trafiği kendi elinizle çöpe atıyorsunuz. Üstelik bunu fark etmezsiniz, çünkü kimse size ürünü bulamadım diye e-posta yazmaz; sadece sekmeyi kapatır.

Bu rehber, Türkçe bir e-ticaret sitesinde site içi aramanın neden bozuk çalıştığını, hangi katmanların eksik olduğunu ve bunların sırayla nasıl kurulacağını anlatıyor. Platform bağımsız yazıldı; Shopify, ikas, Ticimax veya T-Soft fark etmeksizin aynı mantık geçerlidir.

Site içi arama nedir, kategori navigasyonundan farkı ne?

Site içi arama, ziyaretçinin serbest metin yazarak katalogda ürün, kategori veya içerik bulmasını sağlayan sistemdir. Kategori navigasyonu sizin kurguladığınız hiyerarşiyi dayatır; arama ise ziyaretçinin kendi kelime dağarcığını kullanmasına izin verir. İkisi arasındaki temel fark budur ve arama motorunun asıl zorluğu da buradan doğar: müşteri sizin ürün adlarınızı bilmez.

Kataloğunuzda ürün adı Erkek Slim Fit Pamuklu Gömlek Beyaz olabilir. Müşteri ise düz beyaz gömlek, klasik gomlek, ofis gömleği veya doğrudan beyaz gömlek 42 beden yazar. Arama motorunun görevi bu iki dünyayı buluşturmaktır.

Klasik LIKE tabanlı arama neden yetersiz kalıyor?

Çoğu özel geliştirilmiş e-ticaret sitesinde arama şu üç satırdır:

SELECT * FROM products
WHERE name ILIKE '%' || $1 || '%'
   OR description ILIKE '%' || $1 || '%';

Bu yaklaşımın altı ayrı kırılma noktası vardır:

1. Alaka düzeyi yoktur. Sorgu ya eşleşir ya eşleşmez. Kelimenin ürün adında mı yoksa açıklamanın 400. karakterinde mi geçtiği umursanmaz; sonuçlar genelde id sırasına göre gelir.
2. İndeks kullanılamaz. Baştan joker karakterli (%kelime) bir LIKE, klasik B-tree indeksini devre dışı bırakır ve tablo taramasına düşer. Katalog büyüdükçe arama yavaşlar, üstelik en çok istek alan endpoint budur.
3. Çok kelimeli sorgu çöker. Kullanıcı siyah deri ceket yazdığında bu tam ifade ürün adında geçmiyorsa sonuç sıfırdır. Oysa katalogda Deri Ceket - Siyah vardır.
4. Tek harflik hataya tahammül yoktur. parfum yazan kullanıcı, parfüm ürünlerini göremez.
5. Ek çekimleri eşleşmez. ayakkabılar, ayakkabıyı, ayakkabının ile ayakkabı farklı stringlerdir.
6. Türkçe küçük harf dönüşümü hatalıdır. Bir sonraki bölümün konusu.

LIKE aramasının çalışıyor görünmesinin tek sebebi, çalıştığı durumları görüp çalışmadığı durumları görmemenizdir. Sıfır sonuç oranınızı ölçmeye başladığınız gün tablo değişir.

Türkçe aramanın kendine özgü yedi problemi

İngilizce için hazır gelen çözümler Türkçe kataloglarda sessizce bozulur. Sırayla:

1. i / I problemi (dotless i)

Türkçe, i harfinin büyük halinin İ, I harfinin küçük halinin ı olduğu az sayıdaki dilden biridir. Programlama dillerinin varsayılan küçültme fonksiyonları bunu bilmez:

// JavaScript
'IPHONE'.toLowerCase()               // iphone  (yanlış bağlamda doğru)
'IPHONE'.toLocaleLowerCase('tr')     // ıphone  (Türkçe kurala göre doğru)
'ILGINÇ'.toLowerCase()               // ilginç  (yanlış)
'ILGINÇ'.toLocaleLowerCase('tr')     // ılginç  (doğru)

Bu, ürün adı ile arama sorgusunun farklı kurallarla küçültülmesi durumunda sessiz eşleşmezlik üretir. Veritabanı tarafında da aynı tuzak vardır: PostgreSQL tarafında ICU tabanlı bir tr-TR collation, MySQL tarafında utf8mb4_turkish_ci kullanmıyorsanız LOWER() beklediğiniz sonucu vermez.

Pratik çözüm: Türkçe kurala göre küçültmeye çalışmak yerine, hem indeksleme hem sorgu tarafında aynı deterministik normalizasyonu uygulayın. Aşağıda anlatılan ASCII katlaması bu problemi kökten çözer.

2. Şapkalı ve aksanlı harfler

â, î, û karakterleri Türkçe kataloglarda düzensiz kullanılır: kâğıt ve kağıt, rüzgâr ve rüzgar aynı üründe bile farklı yerlerde geçebilir. Kullanıcı ise neredeyse her zaman şapkasız yazar.

3. Sondan eklemeli yapı

Türkçe eklemeli bir dildir; bir kökten onlarca yüzey formu türer. çanta kökü için kullanıcıdan gelebilecek formlar: çantalar, çantası, çantasını, çantalık, çantalarda. Kelime tabanlı basit eşleştirme bunların hiçbirini yakalamaz.

PostgreSQL, snowball tabanlı bir turkish_stem sözlüğü ve turkish tam metin arama yapılandırması ile gelir. Elasticsearch tarafında ise turkish analyzer içinde turkish_stemmer ve turkish_stop filtreleri bulunur. Bunlar işe yarar ama mükemmel değildir; snowball stemmer bazı kelimeleri fazla agresif budayarak alakasız eşleşmeler üretebilir. Kritik kategorilerde stemmer çıktısını gözle kontrol etmek, gerektiğinde keyword_marker benzeri bir mekanizmayla belirli marka ve model kelimelerini budamadan korumak gerekir.

4. Kesme işareti (apostrof)

Türkçe özel isimlerde ek kesme işaretiyle ayrılır: Trendyol'un, iPhone'u, Nike'ın. Kullanıcı bazen apostrofu yazar, bazen yazmaz, bazen düz tırnak yerine tipografik tırnak kullanır. Elasticsearch'ün apostrophe token filtresi apostroftan sonrasını atarak bu sorunu doğrudan çözer; kendi motorunuzu yazıyorsanız normalizasyon adımında hem düz hem tipografik apostrofu tek forma indirip sonrasını eke saymanız gerekir.

5. Yazım hataları ve ASCII yazım alışkanlığı

Türk kullanıcılar mobilde sıklıkla Türkçe karakter kullanmadan yazar: kirmizi elbise, sut makinesi, gunes gozlugu. Buna bir de gerçek yazım hataları (ayakabı, bilgisyar) ve klavye kayması eklenir. Sistem her ikisini de tolere etmelidir.

6. Eş anlamlılar ve halk dili

Katalogda dizüstü bilgisayar yazar, kullanıcı laptop arar. Katalogda telefon kılıfı yazar, kullanıcı kapak arar. Katalogda bebek arabası yazar, kullanıcı puset arar. Bu, algoritmayla çözülmez; sözlükle çözülür.

7. Marka yazım varyantları

Yabancı markaların Türkçe kulakla yazılışı gerçek bir sorundur: Xiaomi yerine şaomi, Huawei yerine huavey, Levi's yerine levis, Schwarzkopf yerine şvarskof. Fuzzy eşleştirme bunların bir kısmını yakalar; gerisi için marka bazlı bir alias listesi tutmak gerekir. Arama loglarınız bu listeyi size ücretsiz yazar.

Katmanlı çözüm mimarisi

İyi bir e-ticaret arama motoru tek bir teknoloji değil, sıralı katmanlardan oluşan bir hattır. Her katman bir problem sınıfını çözer:

Normalizasyon nasıl yapılır?

Amaç, hem ürün metinlerini hem kullanıcı sorgusunu aynı sadeleştirilmiş uzaya taşımaktır. Türkçe için pratikte en dayanıklı yöntem ASCII katlamasıdır:

const MAP = { 'ı':'i','İ':'i','I':'i','i':'i',
              'ş':'s','Ş':'s','ğ':'g','Ğ':'g',
              'ü':'u','Ü':'u','ö':'o','Ö':'o',
              'ç':'c','Ç':'c','â':'a','î':'i','û':'u' };

function normalize(text) {
  return text
    .replace(/[ıİIişŞğĞüÜöÖçÇâîû]/g, ch => MAP[ch] || ch)
    .toLowerCase()
    .replace(/[\u2018\u2019']/g, ' ')   // apostrofları boşluğa çevir
    .replace(/[^a-z0-9 ]+/g, ' ')       // kalan noktalama
    .replace(/\s+/g, ' ')
    .trim();
}

// normalize('Kâğıt Havlu 12'li') -> 'kagit havlu 12 li'
// normalize('KIRMIZI Elbise')      -> 'kirmizi elbise'

Bu tek fonksiyon, yukarıdaki problemlerden dördünü aynı anda çözer. Kritik nokta: indeksi de bu fonksiyondan geçmiş metin üzerine kurun. Sadece sorguyu normalize edip indeksi ham bırakmak en sık görülen uygulama hatasıdır.

Bir uyarı: ASCII katlaması kar ile kâr, şık ile sık gibi çiftleri birleştirir. E-ticaret kataloglarında bu tolere edilebilir bir kayıptır, çünkü ürün adları bağlamı zaten daraltır.

Bulanık eşleştirme (fuzzy matching)

Yazım hatası toleransı, iki kelime arasındaki düzenleme mesafesi (Levenshtein) ile ölçülür. Uygulamada üç yol vardır:

• Trigram benzerliği: PostgreSQL'de pg_trgm eklentisi ile similarity() ve % operatörü. GIN indeksiyle birlikte kullanıldığında orta ölçekli kataloglarda ek altyapı gerektirmeden iş görür.
• Arama motorunun yerleşik toleransı: Meilisearch varsayılan olarak 5 karakterden uzun kelimelerde 1, 9 karakterden uzun kelimelerde 2 hataya izin verir. Typesense benzer bir eşik mantığı kullanır. Bu eşikler ayarlanabilir.
• Sözlük tabanlı düzeltme: Sorguyu, katalogdan türetilmiş kelime sözlüğüne göre düzeltip bunu mu demek istediniz önerisi sunmak.

Fuzzy eşleştirmenin en büyük tuzağı marka ve model kodlarıdır. Ürün kodu A52 ile A72 arasındaki mesafe 1'dir; tolerans açıkken kullanıcıya yanlış modeli göstermek satış kaybından daha kötüdür, iade üretir. Bu yüzden model kodu, SKU ve barkod alanlarında fuzzy toleransını kapatın, yalnızca tam eşleşme kabul edin.

Eş anlamlı sözlüğü nasıl kurulur?

Eş anlamlı listesini masa başında yazmayın; arama loglarından türetin. İzlenecek yol:

1. Son 90 günün tüm sorgularını normalize edilmiş halleriyle toplayın.
2. Sıfır sonuç veren sorguları hacme göre sıralayın. Listenin başı, doğrudan eş anlamlı adaylarınızdır.
3. Her aday için kataloğunuzda hangi ürünün kastedildiğini elle belirleyin. Karşılığı yoksa bu bir ürün talebi sinyalidir, eş anlamlı değil.
4. Eşleşmeleri tek yönlü mü çift yönlü mü tanımlayacağınıza karar verin. puset yazınca bebek arabası gelmeli, ancak bebek arabası yazınca tüm pusetlerin gelmesi istenmeyebilir; bu ayrım kataloğunuza özgüdür.
5. Sözlüğü sürüm kontrolüne alın ve her ay gözden geçirin. Sezonluk terimler değişir.

Vektör ve anlamsal arama ne zaman gerekir?

Anlamsal (semantik) arama, ürün metinlerini ve sorguyu sayısal vektörlere çevirip aralarındaki benzerliği ölçer. Böylece kışın üşümeyen mont gibi hiçbir ürün adında geçmeyen bir ifade, teknik özelliği kalın astarlı olan montlarla eşleşebilir.

Ancak anlamsal arama her derde deva değildir ve kendi tuzakları vardır:

• Tam eşleşmede zayıftır. Kullanıcı SKU veya model kodu yazdığında vektör araması yanlış ürün getirebilir. Bu yüzden pratikte hibrit arama kullanılır: klasik kelime tabanlı skor (BM25) ile vektör skoru birlikte hesaplanır.
• Türkçe destek modelden modele değişir. Çok dilli embedding modelleri Türkçe'de İngilizce'deki kadar isabetli olmayabilir; seçim yapmadan önce kendi kataloğunuzdan 50 gerçek sorguyla test edin.
• Maliyeti ve gecikmesi vardır. Her sorgu için embedding üretmek milisaniyeler ve para demektir. Sık sorguları önbelleğe almak şarttır.
• Katalog değiştikçe yeniden indeksleme gerekir. Ürün açıklaması güncellenince vektör de güncellenmelidir.

Pratik kural: önce normalizasyon, kök bulma, eş anlamlı ve fuzzy katmanlarını kurun. Bunlar tipik bir e-ticaret kataloğunda problemin büyük kısmını çözer. Anlamsal aramayı, bu katmanlar kurulduktan sonra hâlâ kaçırdığınız uzun kuyruk sorgular için ekleyin. STools'un yapay zeka destekli site içi arama modülü de bu sırayı izler: kural tabanlı katman altta, anlamsal katman üstte çalışır.

Sıfır sonuç sayfası: en çok ihmal edilen ekran

Aradığınız kriterlere uygun ürün bulunamadı. Bu cümle bir çıkmaz sokaktır ve çoğu sitede sayfanın tek içeriğidir. Oysa sıfır sonuç ekranı, kurtarılabilir bir oturumun son şansıdır. Yapılması gerekenler, uygulama sırasıyla:

1. Sorguyu gevşetin. Kullanıcı üç kelime yazdıysa ve hiçbir ürün üçünü birden içermiyorsa, AND mantığından OR mantığına düşün ve en çok kelimeyi eşleyen ürünleri gösterin. Ekranın başına şu terim için sonuç bulunamadı, benzer ürünler notunu koyun.
2. Yazım düzeltmesi önerin. Katalog sözlüğüne en yakın kelimeyi bulup bunu mu demek istediniz bağlantısı sunun ve düzeltilmiş sonuçları doğrudan altında listeleyin.
3. Filtreleri tek tek kaldırın. Sonuç sıfırsa bunun sebebi genelde sorgu değil, üstüne binen filtrelerdir. Hangi filtrenin kaldırılmasının kaç sonuç üreteceğini hesaplayıp kullanıcıya gösterin.
4. Stokta olmayan ürünleri gösterme kararını bilinçli verin. Ürün var ama tükenmişse gizlemek yerine göstermek, üstüne stok bildirimi kutusu koymak çoğu zaman daha iyidir; hem kullanıcı aradığını bulduğunu bilir hem siz talebi ölçersiniz.
5. Çıkış yolu bırakın. Popüler kategoriler, çok satanlar ve arama ipuçları. Boş ekran yerine her zaman tıklanacak bir şey olsun.
6. Kaydedin. Her sıfır sonuç sorgusu, zaman damgası ve uygulanan filtrelerle birlikte loglanmalıdır. Bu kayıt, sonraki bölümün hammaddesidir.

Sonuç sıralaması: alaka tek başına yetmez

Arama motoru size en alakalı ürünleri verir; e-ticaret ise satılabilir ürünleri ister. İkisi aynı şey değildir. Sıralamada alaka skorunun üzerine iş sinyalleri bindirilir:

Uygulama önerisi: alaka skorunu taban olarak alın, iş sinyallerini çarpan olarak uygulayın ve hiçbir çarpanın alaka sıralamasını tamamen ters çevirmesine izin vermeyin. Marj ağırlığını yükseltmek kısa vadede sepet tutarını artırabilir; ancak kullanıcı aradığı ürünü ilk ekranda göremediğinde bir daha arama kutusunu kullanmaz.

Arama verisinden ürün ve içerik kararı çıkarmak

Arama logları, sahip olduğunuz en dürüst müşteri araştırmasıdır. Anketin aksine kimse burada nazik davranmaz. Bu veriden çıkarılabilecek kararlar:

• Katalog boşluğu: Yüksek hacimli ve sürekli sıfır sonuç veren sorgular, satmadığınız ama talep edilen ürünlerdir. Tedarik kararınızın girdisi olmalıdır.
• İsimlendirme hatası: Ürün elinizde ama kullanıcı bulamıyorsa sorun üründe değil, ürün adındadır. Kullanıcının kullandığı terimi ürün başlığına veya arama etiketlerine ekleyin. Bu değişiklik aynı zamanda Google görünürlüğünüzü de etkiler.
• Yeni filtre ihtiyacı: Sorgularda tekrar eden nitelikler (beden, hacim, uyumluluk, malzeme) filtre olarak yoksa kullanıcı bunu arama kutusuna yazıyor demektir. Bu, filtre eklemek için doğrudan talimattır.
• İçerik fikri: hangi, nasıl, uyumlu mu kalıbındaki sorgular ürün araması değil bilgi aramasıdır. Bunlar blog ve rehber içeriklerinin konu listesidir.
• Kategori yapısı: Belirli bir terim yüksek hacimliyse ve kategori olarak yoksa, koleksiyon veya landing sayfası açmayı düşünün.

Ayda bir kez, en çok aranan 100 sorgu ve en çok sıfır sonuç veren 50 sorguyu okumak, çoğu e-ticaret ekibinin yapabileceği en yüksek getirili yarım saattir.

Ölçümleme: neye bakmalı?

Site içi aramayı iyileştirdiğinizi iddia edebilmek için önce ölçmeniz gerekir. İzlenmesi gereken metrikler:

Teknik kurulum tarafında: GA4 kullanıyorsanız view_search_results olayını ve search_term parametresini gönderin, sıfır sonuç durumunu ayrı bir parametreyle işaretleyin. Kendi loglama altyapınız varsa sorguyu, sonuç sayısını, uygulanan filtreleri, tıklanan ürünü ve pozisyonunu tek kayıtta tutun; sonradan birleştirmek zordur.

KVKK notu: Arama sorguları çoğunlukla kişisel veri içermez, ancak kullanıcı kimliğiyle eşleştirildiğinde kişisel veri işleme kapsamına girer. Sorguları kullanıcı hesabına bağlayarak saklıyorsanız bunu aydınlatma metninizde belirtin, saklama süresi tanımlayın ve anonim analiz için kimlik alanını ayırın. Sağlık, cinsel yaşam gibi özel nitelikli veri çağrıştırabilecek kategorilerde sorgu loglarını kişiye bağlamamak en güvenli yaklaşımdır.

Performans tarafı: hızlı olmayan arama iyi arama değildir

Anlık öneri (autocomplete) kutusu, kullanıcı her tuşa bastığında istek atıyorsa sunucunuzu ve kullanıcının bataryasını birlikte yakar. Uygulanması gereken temel önlemler:

• Debounce: Tuş vuruşları arasında 150-250 ms bekleyip tek istek atın; kullanıcı yazmaya devam ederse önceki isteği iptal edin.
• Minimum karakter: Genelde 2 veya 3 karakterden önce sorgu atmayın.
• Önbellek: Popüler sorguların sonuçları uzun süre değişmez. Kısa TTL'li bir önbellek istek hacminin büyük kısmını karşılar.
• Yanıt boyutu: Öneri kutusunda tüm ürün nesnesini değil; başlık, görsel, fiyat ve bağlantıyı döndürün.
• Düzen kayması: Öneri kutusu açılırken sayfa içeriğini itiyorsa Core Web Vitals metriklerinizi bozarsınız. Kutuyu overlay olarak konumlandırın.

Platform notları

Hazır altyapı kullanıyorsanız oyun alanınız sınırlıdır; sınırın nerede olduğunu bilmek zaman kazandırır.

• Shopify: Tema tarafında Predictive Search API (/search/suggest.json) ile anlık öneri kutusu kurulabilir. Bilinmesi gereken kritik ayrıntı, öngörülü aramanın normal mağaza aramasından farklı bir motor kullanması ve kısmi kelime eşleşmesini aynı şekilde ele almamasıdır; mağaza aramasında kısmi eşleşme için prefix seçeneğinin last olarak ayarlanması gerekir. Eş anlamlı yönetimi ve gelişmiş sıralama için tema seviyesinde ek geliştirme ya da harici bir arama katmanı gerekir.
• ikas: Storefront API üzerinden ürün verisi çekilebildiği için özel bir arama arayüzü kurmak mümkündür; tema tarafında JavaScript ile kendi öneri kutunuzu bağlayabilirsiniz.
• Ticimax ve T-Soft: Panel üzerinden arama ile ilgili bazı ayarlar sunulur, ancak Türkçe normalizasyon ve eş anlamlı yönetimi genellikle sınırlıdır. Bu altyapılarda pratik yol, ürün verisini dışarı alıp ayrı bir arama servisi üzerinden çalışan bir katman kurmaktır.

Hangi altyapıda olursanız olun değişmeyen kural şudur: arama katmanı, tema ile aynı hızda güncellenmelidir. Katalog değişip arama indeksi değişmiyorsa kullanıcı olmayan ürünü görür, olan ürünü göremez. İndeksleme tetikleyicilerini ürün ekleme, güncelleme, stok değişimi ve fiyat değişimi olaylarına bağlayın. Bu tür entegrasyonları kendi altyapınıza göre kurgulamak için kişiye özel yazılım tarafında değerlendirme yapmak gerekebilir.

30 günlük uygulama planı

1. 1-3. gün — Ölçüm kurun. Arama sorgularını, sonuç sayısını ve tıklamaları loglamaya başlayın. Ölçmeden hiçbir şeye dokunmayın.
2. 4-7. gün — Normalizasyonu tek noktaya alın. Tek bir normalize fonksiyonu yazın, hem indekste hem sorguda kullanın, indeksi yeniden oluşturun.
3. 8-12. gün — Çok kelimeli sorguyu düzeltin. Tam ifade eşleşmesinden kelime bazlı eşleşmeye geçin, ürün adında geçen kelimeye açıklamada geçenden daha yüksek ağırlık verin.
4. 13-16. gün — Sıfır sonuç ekranını yeniden yazın. Sorgu gevşetme, yazım önerisi, filtre kaldırma ve popüler ürün blokları ekleyin.
5. 17-21. gün — İlk eş anlamlı sözlüğünü çıkarın. İlk iki haftanın sıfır sonuç loglarından başlayın; 30-50 kayıtlık bir liste bile büyük fark yaratır.
6. 22-25. gün — Fuzzy toleransı ekleyin. Model kodu ve SKU alanlarında kapalı, ürün adı ve kategori alanlarında açık olacak şekilde ayarlayın.
7. 26-30. gün — Sıralamayı iş kurallarıyla düzenleyin. Stok ve popülerlik sinyallerini ekleyin, ölçüm panosunda öncesi ve sonrasını karşılaştırın.

Bu sıralamanın mantığı önemlidir: ölçüm önce gelir, çünkü hangi düzeltmenin işe yaradığını başka türlü bilemezsiniz. Anlamsal arama listede yoktur, çünkü ilk 30 günün işi değildir; temel katmanlar oturmadan üstüne yapay zeka koymak, kırık temelin üzerine kat çıkmaktır.

Özet

Site içi arama, e-ticarette en yüksek niyetli kullanıcıyla en kısa temas noktasıdır ve Türkçe'de İngilizce'ye göre belirgin biçimde daha zordur. Ek çekimleri, i/I dönüşümü, şapkalı harfler, apostrof ve marka yazım varyantları, hazır çözümlerin çoğunun sessizce yanlış sonuç üretmesine yol açar.

Doğru yaklaşım katmanlıdır: önce herkesin aynı kuralla çalıştığı bir normalizasyon, sonra kök bulma ve eş anlamlı sözlüğü, ardından kontrollü yazım hatası toleransı, en sonda iş kurallarıyla düzenlenmiş sıralama. Sıfır sonuç ekranı bir hata sayfası değil, bir kurtarma ekranıdır. Ve tüm bunların üzerinde, arama logları size hangi ürünü almanız, hangi başlığı değiştirmeniz ve hangi içeriği yazmanız gerektiğini söyleyen ücretsiz bir müşteri araştırmasıdır.

Kendi kataloğunuz için nereden başlayacağınızdan emin değilseniz ilk adım her zaman aynıdır: bir hafta boyunca sorguları loglayın ve sıfır sonuç listesini okuyun. Yol haritanız o listede yazılı olacak. Konuyu birlikte değerlendirmek isterseniz destek@stools.digital adresinden ulaşabilirsiniz.