---
title: "5 Kebijakan Operasional yang Harus Ditetapkan Sebelum Mengembangkan Pencarian Toko Online AI"
locale: id
category: how_to
category_name: "Panduan"
translation_status: machine
license: cc_by
author: "Injoys Admin"
source_url: https://injoys.com/en/articles/five-policies-before-ai-ecommerce-search-development
published_at: 2026-07-21T10:05:48+09:00
---

# 5 Kebijakan Operasional yang Harus Ditetapkan Sebelum Mengembangkan Pencarian Toko Online AI

> AI dapat membuat kode pencarian toko online dengan cepat, tetapi standar penayangan produk dan penanganan pengecualian harus lebih dulu ditentukan oleh operator. Panduan ini merangkum pengurutan, status produk, metode daftar, cakupan pencarian, dan kebijakan log hingga tingkat implementasi dan pengujian nyata.

## Key Points

- Pengurutan dasar harus menggabungkan relevansi pencarian serta sinyal penjualan dan kualitas dengan formula yang terdokumentasi, dan penayangan iklan harus dipisahkan dari peringkat organik.
- Produk habis, penghentian penjualan sementara, penjualan berakhir, dan recall harus dimodelkan sebagai status yang berbeda serta ditangani secara konsisten di pencarian, detail, keranjang, dan pembayaran.
- Daftar produk berskala besar harus memilih paginasi, muat lebih banyak, atau scroll tanpa batas sesuai tujuan, serta menjamin status URL dan pemulihan saat kembali.
- Selain nama produk, cakupan pencarian harus mencakup merek, kategori, atribut, sinonim, dan nama model, serta layar tanpa hasil harus dirancang sebagai etalase terpisah.
- Log pencarian harus dimanfaatkan sebagai data permintaan, tetapi pengenal pribadi dan kata pencarian sensitif harus diminimalkan, serta penyimpanan teks asli dan penyimpanan agregat harus dipisahkan.

AI dapat dengan cepat membuat API daftar produk, kotak pencarian, dan tombol pengurutan. Namun, **produk mana yang ditampilkan, produk mana yang disembunyikan, dan apa yang disebut sebagai ‘rekomendasi’** bukanlah kode, melainkan kebijakan operasional. Pencarian di toko online bukan sekadar fungsi kueri, melainkan sistem pengambilan keputusan yang menggabungkan penataan etalase, ruang iklan, penanganan stok, pengalaman pelanggan, dan pengumpulan data di satu tempat.

Jika hanya memberi instruksi “buatkan fitur pencarian produk” tanpa memberikan kebijakan, AI dapat secara acak mengisi contoh yang familier seperti urutan terbaru berdasarkan pendaftaran, kecocokan sebagian nama produk, dan paginasi sederhana. Kodenya mungkin berjalan, tetapi bisa tidak sesuai dengan operasional toko. Masalah yang umum terjadi adalah produk terbaru tetap tampil di baris pertama meski stoknya habis, produk yang penjualannya telah berakhir tetap bisa dimasukkan ke keranjang, dan pelanggan yang mencari “apel” tidak menemukan “청송 부사”.

## Peringkat pencarian bukan fungsi teknis, melainkan kebijakan operasional

Urutan penataan produk dapat dirancang oleh pelaku usaha. Namun, jika makna yang disampaikan layar kepada konsumen tidak selaras dengan cara perhitungan peringkat sebenarnya, atau jika paparan yang memiliki kepentingan ekonomi dibuat tampak seperti rekomendasi umum, risiko hukum dan kepercayaan akan meningkat.

Komisi Perdagangan yang Adil pada Juni 2024 mempermasalahkan pengoperasian peringkat pencarian oleh Coupang dan CPLB serta penulisan ulasan pembelian oleh karyawan, lalu mengumumkan denda sementara sebesar 1,400억 won. Pada Agustus tahun yang sama, berdasarkan surat keputusan, dendanya ditetapkan sebesar 1,628억 won. Pihak pelaku usaha menolak keputusan tersebut, dan berdasarkan pemberitaan April 2026, gugatan pembatalan terkait masih berlangsung. Pelajaran praktis dari kasus ini bukanlah proposisi sederhana bahwa “mengutamakan produk sendiri selalu ilegal”. Yang perlu ditinjau sejak tahap desain adalah **apa arti label rekomendasi, apakah iklan dan kepentingan internal perusahaan telah ditampilkan dengan jelas, dan apakah perubahan peringkat dapat dijelaskan dengan data dan dokumen**.

Karena penerapan hukum dapat berbeda tergantung struktur layanan dan cara penandaan, sebelum peluncuran aktual akan lebih aman untuk memeriksa secara terpisah peraturan terkait dan kasus penegakan terbaru.

## Titik kegagalan ‘versi instan’ yang dibuat oleh prompt satu baris

| Kebijakan yang belum ditentukan | Implementasi yang dapat diisi AI secara acak | Risiko operasional nyata |
|---|---|---|
| Pengurutan default | `created_at DESC` | Produk yang baru didaftarkan tetapi stok habis atau belum diperiksa tampil di bagian atas |
| Status penjualan | Hanya memeriksa apakah dihapus | Produk yang dihentikan penjualannya atau ditarik kembali muncul di pencarian atau dapat dipesan |
| Pemuatan daftar | Kueri seluruh data atau infinite scroll sederhana | Respons lambat, posisi hilang saat kembali, sulit membandingkan |
| Cakupan pencarian | Hanya kecocokan sebagian nama produk | Pencarian merek, varietas, nama model, sinonim gagal |
| Tidak ada hasil | Hanya mengembalikan array kosong | Pelanggan dengan niat beli tinggi langsung pergi |
| Log | Menyimpan kata pencarian bersama anggota dan IP apa adanya | Risiko pengumpulan di luar tujuan, penyimpanan berlebihan, paparan kata pencarian sensitif |

AI dapat mengisi kekosongan persyaratan, tetapi tidak dapat menilai apakah pilihan tersebut sesuai dengan strategi toko dan tanggung jawab hukum. Karena itu, sebelum implementasi, setidaknya lima kebijakan berikut harus ditetapkan dalam dokumen.

## 1. Nilai default pengurutan: apa yang akan disebut ‘urutan rekomendasi’

Pengurutan default adalah etalase pertama yang dilihat pelanggan. Karena banyak pengguna tidak mengubah opsi pengurutan, nilai default secara langsung memengaruhi penjualan, penghabisan stok, pengembangan produk baru, dan kepuasan pelanggan.

### Pisahkan terlebih dahulu tahap perhitungan peringkat

Lebih aman membagi hasil pencarian ke dalam urutan berikut daripada mencampur dan menghitung semuanya sekaligus.

1. **Penentuan kelayakan tampil:** Hanya produk yang dapat dijual, dapat dipublikasikan, dan bukan target pemblokiran hukum maupun operasional yang dimasukkan sebagai kandidat.
2. **Perhitungan relevansi pencarian:** Menghitung seberapa cocok nama produk, merek, kategori, atribut, dan sinonim dengan kata pencarian.
3. **Perhitungan peringkat organik:** Menggabungkan sinyal seperti kecepatan penjualan, tingkat konversi, reliabilitas rating, dan kualitas pengiriman.
4. **Penerapan aturan bisnis:** Menerapkan penalti stok habis, kesempatan eksplorasi produk baru, pembatasan keragaman, dan sebagainya.
5. **Penggabungan slot iklan:** Produk iklan disisipkan terpisah dari peringkat organik dan ditandai dengan jelas.
6. **Penanganan seri yang stabil:** Jika skornya sama, urutan ditentukan dengan kunci tetap seperti `product_id`.

### Skor rekomendasi harus berupa rumus yang terdokumentasi

Berikut hanyalah contoh untuk menjelaskan struktur, bukan jawaban yang cocok untuk semua toko online.

```text
organic_score =
  0.45 × query_relevance
+ 0.20 × conversion_rate_28d
+ 0.15 × sales_velocity_14d
+ 0.10 × rating_confidence
+ 0.10 × fulfillment_quality
```

Setiap sinyal harus dinormalisasi ke rentang yang sama, serta periode dan objek agregasinya harus dinyatakan. Rata-rata rating sederhana dapat membuat produk dengan 1 ulasan bernilai 5 lebih tinggi daripada produk dengan 1,000 ulasan bernilai 4.8, sehingga lebih baik menggunakan skor koreksi yang juga mencerminkan jumlah ulasan. Jika hanya menggunakan volume penjualan, produk yang telah lama terjual dapat memperoleh keuntungan permanen, sehingga kecepatan penjualan dan tingkat konversi dalam periode terbaru perlu dilihat bersama.

### Rincian yang wajib ditentukan

- Apakah tujuan urutan rekomendasi adalah kecocokan pencarian, kemungkinan pembelian, kepuasan pelanggan, atau efisiensi stok
- Periode agregasi dan siklus pembaruan setiap sinyal
- Sinyal penalti seperti tingkat pembatalan, tingkat retur, keterlambatan pengiriman, dan kemungkinan stok habis
- Kesempatan eksplorasi dan poin tambahan maksimum yang akan diberikan kepada produk baru dengan sedikit ulasan
- Aturan keragaman agar merek yang sama atau penjual yang sama tidak terlalu mendominasi bagian atas
- Kunci pengurutan tetap yang akan digunakan saat skor seri
- Catatan audit yang menyimpan versi rumus peringkat, alasan perubahan, waktu penerapan, dan pemberi persetujuan
- Indikator keberhasilan dan kondisi penghentian A/B test

### Jangan mencampur iklan dan rekomendasi organik

Kepentingan ekonomi seperti biaya iklan, apakah produk milik sendiri, dan margin tinggi dapat saja dipertimbangkan, tetapi berisiko jika hal itu membuat konsumen salah mengira sebagai “urutan populer” atau “urutan rekomendasi” umum. Komisi Perdagangan yang Adil pada 2025 juga mempermasalahkan struktur dan penandaan terkait dalam kasus platform penjualan produk mahal, di mana produk penjual yang membeli opsi berbayar tampil lebih dulu dalam pengurutan default. Produk iklan pada dasarnya harus dikelola sebagai kumpulan kandidat dan slot terpisah, serta diberi label “iklan” atau “sponsor” yang dapat diidentifikasi pada tingkat kartu. Layar administrator harus menampilkan aturan penayangan iklan dan rumus peringkat organik secara terpisah.

## 2. Produk berstatus tidak normal: stok habis dan penghentian penjualan adalah status yang berbeda

Jika semua pengecualian ditangani hanya dengan `is_sold_out`, pencarian, detail, keranjang, dan validasi pesanan akan saling tidak selaras. Minimal, **status penjualan, status stok, status publikasi, dan status regulasi** harus dipisahkan.

### Model status yang direkomendasikan

| Status | Pencarian·daftar | Detail URL langsung | Keranjang·pesanan | Penanganan yang direkomendasikan |
|---|---|---|---|---|
| Sedang dijual·stok tersedia | Tampil normal | Ditampilkan normal | Bisa | Kandidat dasar |
| Sedang dijual·stok habis sementara | Dapat ditampilkan tetapi diberi penalti atau diturunkan | Menampilkan stok habis·notifikasi restock | Tidak bisa | Menjaga kemungkinan restock |
| Penjualan dihentikan sementara | Pada dasarnya disembunyikan | Informasi penghentian sementara | Tidak bisa | Dipulihkan saat dibuka kembali |
| Penjualan berakhir | Disembunyikan dari pencarian·kategori | Informasi berakhir dan produk pengganti | Tidak bisa | Menjaga tautan lama dan konteks CS |
| Draf·dalam pemeriksaan | Disembunyikan sepenuhnya | Hanya admin berwenang | Tidak bisa | Pemeriksaan sebelum publikasi |
| Recall·pemblokiran hukum | Disembunyikan sepenuhnya | Pengumuman keselamatan jika perlu | Tidak bisa | Informasi keselamatan didahulukan daripada rekomendasi pengganti |

Produk stok habis memiliki nilai untuk notifikasi restock dan pemahaman permintaan pencarian, sehingga tidak selalu perlu dihapus. Sebaliknya, produk yang penjualannya telah berakhir sebaiknya dikecualikan dari daftar umum, tetapi pelanggan yang masuk melalui bookmark lama atau tautan eksternal dapat diberi penjelasan “penjualan telah berakhir” dan produk serupa. Apakah URL detail dipertahankan atau diakhiri dengan `410 Gone` ditentukan berdasarkan trafik pencarian, kebutuhan pemberitahuan hukum, dan nilai konten pengganti.

### Indeks pencarian bukan otoritas final untuk ketersediaan pemesanan

Indeks pencarian dapat mengalami keterlambatan sinkronisasi. Karena itu, meskipun hasil pencarian menunjukkan stok tersedia, tahap berikutnya harus memvalidasi ulang.

- Validasi ulang status penjualan dan stok saat memasukkan ke keranjang
- Validasi ulang harga, diskon, dan stok saat masuk ke formulir pesanan
- Reservasi stok atau pengurangan atomik tepat sebelum pembayaran
- Penghapusan darurat dari indeks pencarian saat terjadi event penghentian penjualan
- Pemantauan waktu keterlambatan pengindeksan dan jumlah kegagalan

Tanpa aturan ini, insiden CS akan berulang: layar pencarian tampak normal, tetapi gagal hanya pada tahap pembayaran.

## 3. Cara menampilkan daftar: apakah memakai paginasi, lihat lainnya, atau infinite scroll

Jika produk berjumlah ribuan atau puluhan ribu, semuanya tidak boleh dikirim sekaligus. Namun, menyatakan bahwa “toko online selalu harus memakai halaman bernomor” juga tidak tepat. Dalam pencarian yang berfokus pada perbandingan, pemulihan posisi dan status penting, sedangkan dalam eksplorasi kategori, “lihat lainnya” bisa lebih nyaman.

| Cara | Kekuatan | Kelemahan | Situasi yang cocok |
|---|---|---|---|
| Paginasi bernomor | Mudah memahami posisi saat ini dan skala hasil, dapat mengunjungi ulang halaman tertentu | Perpindahan halaman terputus dan perbandingan antarhalaman merepotkan | Pencarian desktop, eksplorasi mendalam, hasil yang dapat dibagikan |
| Lihat lainnya | Pengguna mengontrol pemuatan sambil mempertahankan produk yang sudah ada | Jika hasil sangat banyak, DOM dan memori membesar | Eksplorasi mobile·kategori, hasil skala menengah |
| Infinite scroll | Eksplorasi berkelanjutan terasa natural | Posisi, akhir, dan skala keseluruhan tidak jelas, pemulihan saat kembali sulit | Layar feed yang lebih mementingkan penemuan daripada perbandingan |

Secara praktis, **untuk hasil pencarian dapat diprioritaskan paginasi atau “lihat lainnya + URL halaman yang dapat dipulihkan”**, sedangkan untuk feed rekomendasi bertipe penemuan dapat dipertimbangkan infinite scroll lebih dulu. Sekalipun menggunakan infinite scroll murni, syarat berikut harus dipenuhi.

- Menyimpan kata pencarian, pengurutan, filter, halaman, atau kursor di URL atau status yang dapat dipulihkan
- Memulihkan produk sebelumnya dan posisi scroll saat kembali dari halaman detail
- Mendukung navigasi keyboard, screen reader, dan perpindahan fokus
- Menyediakan alternatif yang dapat diakses untuk footer dan tautan navigasi utama
- Menyediakan UI kegagalan pemuatan dan coba lagi
- Menyediakan URL unik atau struktur tautan yang dapat diakses untuk setiap kumpulan hasil

### Paginasi offset dan kursor

Offset dalam seperti `OFFSET 5000 LIMIT 40` akan makin lambat dan mudah menimbulkan duplikasi atau kehilangan data ketika data banyak dan sering diperbarui. Untuk halaman dangkal dan layar administrator, offset sederhana, tetapi untuk pencarian skala besar, metode kursor yang meneruskan kunci pengurutan dari hasil terakhir lebih stabil.

```text
ORDER BY score DESC, product_id DESC
cursor = last_score + last_product_id
```

Jika hanya skor yang digunakan sebagai kursor, produk dengan skor seri dapat terlewat, sehingga kunci unik harus digunakan bersama. Jika skor rekomendasi sering berubah secara real-time, kebijakan untuk mengunci versi snapshot atau waktu acuan ranking selama sesi pencarian juga diperlukan.

## 4. Cakupan pencarian dan layar tanpa hasil: menghubungkan ekspresi pelanggan dengan data produk

Pelanggan tidak mengetahui nama produk persis yang didaftarkan operator. Agar pelanggan yang mencari “apel” dapat melihat “청송 부사”, “홍로”, dan “apel rumahan”, data produk dan kamus pencarian harus dirancang bersama.

### Prioritas bidang pencarian

| Bidang | Prioritas yang direkomendasikan | Contoh |
|---|---:|---|
| SKU·nama model·barcode | Sangat tinggi | `SM-S928N`, `880...` |
| Nama produk | Tinggi | Apel Cheongsong Busa 3kg |
| Merek·produsen | Tinggi | Samsung, Apple |
| Kategori·jenis produk | Menengah ke atas | Buah, sepatu lari |
| Atribut utama | Menengah ke atas | Kapasitas, warna, spesifikasi, model kompatibel |
| Sinonim·alias·varietas·tag | Menengah ke atas | sepatu jogging↔sepatu lari, apel↔busa |
| Deskripsi detail | Rendah | Bobot rendah untuk mengurangi noise dari deskripsi panjang |
| Isi ulasan | Opsional | Digunakan terbatas setelah meninjau kualitas·spam·informasi pribadi |

Dalam pencarian bahasa Korea, perbedaan spasi, pemisahan jamo, penulisan merek dalam Inggris·Hangul, angka dan satuan, serta kata majemuk juga harus dipertimbangkan. Misalnya, buat aturan normalisasi agar “에어팟프로2”, “에어팟 프로 2”, dan “AirPods Pro 2” terhubung ke kelompok produk yang sama.

### Pipeline pencarian yang direkomendasikan

1. Memvalidasi panjang input dan karakter yang diizinkan.
2. Menormalisasi huruf besar-kecil, spasi, karakter khusus, dan satuan.
3. Memeriksa kecocokan tepat dengan kode produk terlebih dahulu.
4. Menerapkan tokenisasi serta variasi bentuk dan ejaan.
5. Memperluas sinonim dan kamus kategori yang dikelola operator.
6. Menemukan kandidat dengan pencarian teks.
7. Jika perlu, menggunakan pencarian semantik untuk pembuatan kandidat pendukung.
8. Memfilter status penjualan·publikasi·regulasi.
9. Menghitung skor organik dan menggabungkan iklan secara terpisah.
10. Mengembalikan hasil dan informasi diagnosis.

Meskipun menerapkan AI generatif atau pencarian vektor, kecocokan tepat seperti SKU, merek, dan nama model tidak boleh dilemahkan. Dalam pencarian belanja, pendekatan hibrida yang menggabungkan **pencarian tepat + relevansi teks + pencarian semantik opsional** umumnya lebih aman. Agar AI tidak mengarang produk, harga, atau stok yang tidak ada di katalog, semua respons harus dihubungkan dengan ID produk nyata dan data saat ini.

### Layar tanpa hasil adalah etalase kedua

Ketika tidak ada hasil pencarian, jangan hanya menampilkan layar kosong. Namun, produk populer yang tidak relevan juga tidak boleh dicampur seolah-olah merupakan hasil pencarian.

Komposisi yang direkomendasikan adalah sebagai berikut.

- Menampilkan kata pencarian yang dimasukkan pengguna apa adanya dan menginformasikan dengan jelas bahwa tidak ada produk yang cocok
- Kandidat koreksi typo dan saran sinonim
- Jika menjadi 0 hasil karena filter, memberi tahu filter yang dapat dihapus
- Menyajikan hasil dengan cakupan yang diperluas memakai label terpisah
- Membedakan dan menampilkan kategori terkait, produk pengganti, dan produk populer keseluruhan
- Permintaan restock·masuk produk atau koneksi ke pusat layanan pelanggan
- Mencatat event pencarian tanpa hasil ke analisis administrator

“Tidak ada hasil” dan “tidak ada hasil setelah filter diterapkan” adalah masalah berbeda. Jika sebelumnya ada kandidat tetapi menjadi 0 karena filter harga·warna, pelonggaran filter adalah yang paling berguna. Jika katalog memang tidak memiliki produk tersebut, hal itu harus dimanfaatkan sebagai data sourcing.

## 5. Riwayat pencarian: mengelola data riset pasar dan informasi pribadi bersama-sama

Kata pencarian tanpa hasil menunjukkan permintaan yang dicari pelanggan tetapi tidak dapat dibeli. Kata pencarian populer membantu penataan dan perencanaan stok, dan alur klik·keranjang·pembelian setelah pencarian menjadi indikator inti untuk mengevaluasi kualitas pencarian.

Namun, tidak bisa disimpulkan bahwa “jika hanya menyimpan kata pencarian dan jumlahnya, itu selalu bukan informasi pribadi”. Kata pencarian itu sendiri dapat berisi nomor telepon, nomor pesanan, nama, serta informasi sensitif seperti kesehatan, agama, dan kehidupan seksual. Jika digabungkan dengan akun·IP·informasi perangkat, kemungkinan mengidentifikasi atau melacak individu meningkat.

### Item pengumpulan yang direkomendasikan

| Kategori | Penanganan yang direkomendasikan |
|---|---|
| Kata pencarian yang dinormalisasi | Agregasikan per hari·jam dan minimalkan periode penyimpanan teks asli |
| Jumlah hasil | Simpan apakah 0 hasil dan nilai rentang |
| Filter·pengurutan yang diterapkan | Simpan hanya dalam cakupan yang diperlukan untuk analisis kualitas pencarian |
| Klik·keranjang·pembelian | Jika memungkinkan, simpan sebagai metrik agregat pada tingkat kata pencarian |
| Koneksi sesi | Gunakan pengenal acak berumur pendek hanya jika benar-benar diperlukan |
| ID anggota·IP·lokasi akurat | Kecualikan dari log analisis pencarian jika tidak ada tujuan dan dasar yang jelas |
| Informasi pribadi dalam teks asli | Masking atau buang pola email·nomor telepon·nomor pesanan |

ID anggota yang di-hash juga tidak otomatis menjadi informasi anonim. Jika masih dapat dihubungkan kembali dengan pengguna tertentu, itu harus diperlakukan sebagai informasi pseudonim atau informasi pribadi. Periode penyimpanan juga jangan ditentukan seragam; tetapkan masing-masing untuk teks asli dan data agregat berdasarkan tujuan, siklus analisis, dan risiko keamanan.

### Metrik yang diperlukan di dashboard administrator

- Volume pencarian dan jumlah kata pencarian unik
- Rasio tanpa hasil
- Click-through rate hasil pencarian
- Rasio keranjang dan konversi pembelian setelah pencarian
- Rasio koreksi kata pencarian dan pelepasan filter
- Rasio paparan produk stok habis
- Konsentrasi hasil teratas dan keragaman merek
- Metrik yang memisahkan performa iklan dan hasil organik
- Kebaruan indeks pencarian dan jumlah kegagalan pengindeksan

Karena kata pencarian teks asli berfrekuensi rendah dapat mengandung informasi pribadi, metode menampilkan hanya item yang melewati standar agregasi minimum pada layar operator juga berguna.

## Prompt praktis: cara mengubah kebijakan menjadi kode

Lebih penting menulis aturan operasional dengan jelas daripada menggunakan banyak istilah pengembangan. Template berikut dapat diisi sesuai situasi layanan dan diberikan kepada AI.

```text
Rancang dan implementasikan fitur pencarian produk untuk toko online kami.

1. Kelayakan tampil
- Hanya produk yang sedang dijual, berstatus publik, dan tidak memiliki pemblokiran regulasi yang dimasukkan sebagai kandidat pencarian.
- Stok habis sementara tetap ditampilkan, tetapi ditempatkan di belakang produk dengan stok tersedia dalam kondisi yang sama.
- Produk yang penjualannya berakhir dan produk yang penjualannya dihentikan sementara disembunyikan dari pencarian·kategori.
- Pada URL langsung produk yang penjualannya berakhir, tampilkan informasi berakhir dan produk pengganti, serta hapus tombol pembelian.

2. Pengurutan default
- Relevansi kata pencarian diberi bobot paling besar.
- Mencerminkan tingkat konversi 28 hari terakhir, kecepatan penjualan 14 hari terakhir, rating terkoreksi, dan kualitas pengiriman.
- Setiap bobot dapat diubah melalui file konfigurasi atau kebijakan administrator.
- Seri diurutkan secara stabil berdasarkan product_id menurun.
- Produk iklan jangan dicampur ke skor organik, tetapi masukkan ke slot terpisah dan tandai sebagai 'iklan'.

3. Eksplorasi daftar
- Kembalikan 40 item sekali jalan.
- Kata pencarian, pengurutan, filter, halaman, atau kursor harus dapat dipulihkan dari URL.
- Jika kembali dari halaman detail, pulihkan daftar dan posisi scroll.
- Untuk hasil skala besar, gunakan paginasi kursor.

4. Cakupan pencarian
- Kecocokan tepat SKU dan nama model menjadi prioritas tertinggi.
- Cari nama produk, merek, kategori, atribut, dan tag sinonim.
- Tangani spasi bahasa Korea serta variasi merek Inggris·Hangul.
- Jika tidak ada hasil, tampilkan saran typo, pelonggaran filter, kategori terkait, dan rekomendasi pengganti secara terpisah.

5. Log pencarian
- Secara default hanya simpan kata pencarian yang dinormalisasi, rentang waktu, jumlah hasil, filter, serta metrik klik·pembelian agregat.
- ID anggota dan IP tidak disimpan di log analisis pencarian.
- Bentuk email, nomor telepon, dan nomor pesanan di-masking.
- Periode penyimpanan teks asli dan periode penyimpanan agregat dipisahkan sebagai nilai pengaturan.

6. Kebutuhan teknis
- Rancang bersama model data, kontrak API, indeks pencarian, metode sinkronisasi, penanganan pengecualian, dan metrik administrator.
- Usulkan indeks yang sesuai dengan pola kueri aktual dan jelaskan cara memeriksa execution plan.
- Meski terjadi keterlambatan indeks pencarian, validasi ulang status·harga·stok pada tahap keranjang dan pembayaran.
- Tulis skenario unit test, integration test, performance test, dan accessibility test.

Sebelum memulai implementasi, jika ada keputusan dari kebijakan yang belum saya tentukan dan memengaruhi hasil, tanyakan terlebih dahulu, dan tampilkan asumsi yang ditentukan secara acak dalam daftar terpisah.
```

Kalimat terakhir adalah perangkat inti yang mengubah AI dari sekadar pembuat kode menjadi mitra peninjau persyaratan. Namun, jangan berhenti hanya dengan menerima pertanyaan; jawaban yang telah ditetapkan harus tercermin dalam dokumen kebijakan dan kondisi pengujian.

## Desain implementasi: menetapkan kebijakan ke data dan API

### Contoh model data

```text
products
- product_id
- sales_status
- stock_status
- visibility_status
- compliance_status
- brand_id
- category_id
- searchable_name
- search_tags
- price
- inventory_quantity
- ranking_feature_version
- updated_at
```

Jangan memasukkan beberapa makna ke dalam satu bidang. Misalnya, jika hanya ada `status = 1`, tidak jelas apakah itu berarti dapat dijual, dapat dipublikasikan, stok tersedia, atau lolos regulasi. Transisi status juga dikelola dalam tabel untuk mendefinisikan pemeriksaan dan event yang diperlukan saat berpindah dari draf ke sedang dijual, dan dari sedang dijual ke berakhir.

### Informasi yang perlu disertakan dalam respons API

- Kata pencarian yang dinormalisasi
- Pengurutan dan filter yang diterapkan
- Kumpulan hasil dan kursor berikutnya
- Jumlah hasil atau perkiraan jumlah hasil
- Badge stok habis·status penjualan
- Apakah iklan dan teks penandaan iklan
- Apakah ada koreksi typo·perluasan cakupan pencarian
- Versi kebijakan pencarian dan ID permintaan untuk pelacakan

Skor mentah sebagai informasi debugging internal dan bobot yang sensitif secara bisnis tidak perlu diekspos apa adanya ke API pelanggan. Sebaliknya, operator harus dapat mereproduksi jalur perhitungan peringkat dengan ID permintaan.

### Indeks dirancang sesuai pola kueri aktual

Secara umum, untuk kolom yang digunakan dalam filter status dan pengurutan, pertimbangkan indeks keluarga B-tree; untuk dokumen full-text search, pertimbangkan keluarga inverted index. Jika menggunakan PostgreSQL, `tsvector` dan indeks GIN dapat digunakan, dan jika pencarian string mirip diperlukan, `pg_trgm` dapat digunakan. Prinsipnya sama meskipun menggunakan mesin pencari eksternal.

```sql
CREATE INDEX idx_products_visibility
ON products (visibility_status, sales_status, compliance_status);

CREATE INDEX idx_products_search_document
ON products USING GIN (search_document);
```

Semakin banyak indeks dibuat, biaya tulis dan ruang penyimpanan juga meningkat. Jangan menentukan hanya berdasarkan perkiraan; periksa `EXPLAIN ANALYZE`, slow query log, dan load test berdasarkan kueri nyata serta distribusi data. Ketika jumlah produk meningkat, lihat p95·p99 latency, tingkat timeout, dan kebaruan pengindeksan bersama-sama, bukan hanya waktu respons rata-rata.

### Pengaman tambahan saat memasang AI generatif

- Keberadaan produk, harga, stok, dan tanggal pengiriman hanya menggunakan hasil API katalog
- Perluasan kata pencarian yang dibuat model dicatat bersama teks asli dan perluasan berlebihan dibatasi
- Pencarian SKU·nama model yang tepat didahulukan daripada pencarian semantik
- Filter penghentian penjualan·recall diterapkan sama pada kandidat pencarian AI
- Melacak ID produk dan bidang dasar yang ditampilkan dalam jawaban
- Jika model gagal, fallback ke pencarian teks umum
- Memisahkan agar frasa bersifat prompt injection dalam deskripsi produk atau ulasan tidak dijalankan sebagai instruksi sistem

## Acceptance test sebelum peluncuran

| Skenario | Hasil yang diharapkan |
|---|---|
| Ada produk stok habis yang didaftarkan kemarin bersama produk stok tersedia yang terus terjual | Produk stok habis tidak mendominasi bagian atas default |
| Mencari produk yang penjualannya telah berakhir | Tidak ada di daftar, dan pada URL langsung ditampilkan informasi berakhir serta status tidak dapat dibeli |
| Produk iklan tampil di slot peringkat 1 | Pada kartu, status sebagai iklan dapat segera diidentifikasi |
| 0 hasil setelah filter diterapkan | Menampilkan saran penghapusan filter dan apakah kandidat awal ada |
| Pencarian “sepatu lari”, “sepatu jogging” | Kelompok produk terkait tampil konsisten sesuai kebijakan sinonim |
| Membuka detail lalu kembali | Kata pencarian, filter, pengurutan, daftar, dan posisi scroll dipulihkan |
| Ada beberapa produk dengan skor sama | Meski berpindah halaman berulang, urutan tetap tanpa duplikasi·kehilangan |
| Stok masih tersisa di indeks pencarian | Diblokir dengan stok terbaru pada tahap keranjang·pembayaran |
| Kata pencarian mengandung email·nomor telepon | Di-masking atau dibuang sebelum penyimpanan log |
| Pencarian serentak dalam jumlah besar | Memenuhi standar p95 latency dan tingkat error yang didefinisikan |
| Dashboard kata pencarian administrator | Teks asli berfrekuensi rendah dan pola sensitif tidak terekspos apa adanya |
| Perubahan bobot ranking | Versi kebijakan, pemberi persetujuan, waktu penerapan, serta metrik sebelum-sesudah dicatat |

## Hal yang harus diulang pada tahap operasional

Pencarian bukan fitur yang selesai setelah sekali dikembangkan. Karena komposisi produk, musim, promosi, dan ekspresi pelanggan berubah, siklus berikut harus dijadikan proses operasional.

1. Meninjau kata pencarian tanpa hasil dan kata pencarian yang melonjak setiap minggu.
2. Memperbarui sinonim dan pemetaan kategori melalui prosedur persetujuan.
3. Melihat rasio paparan stok habis, click-through rate, tingkat konversi, dan tingkat koreksi kata pencarian bersama-sama.
4. Perubahan bobot diperluas setelah evaluasi offline dan A/B test terbatas.
5. Mengaudit secara terpisah proporsi paparan iklan·produk sendiri·hasil organik.
6. Memeriksa secara berkala periode penyimpanan log pencarian, hak akses, dan kegagalan masking.
7. Meninjau ulang tingkat penggunaan indeks dan kueri lambat dengan trafik nyata.

## Kesimpulan

AI dapat dengan cepat membuat API dan layar pencarian, tetapi tidak dapat menentukan produk mana yang berhak berdiri di depan pelanggan. Pencarian toko online yang praktis selesai ketika **nilai default pengurutan, status produk, eksplorasi daftar, cakupan pencarian dan penanganan tanpa hasil, serta log pencarian** terlebih dahulu ditetapkan sebagai kebijakan, lalu kebijakan itu tercermin secara konsisten dalam model data, API, indeks, pengujian, dan metrik administrator.

Coding dapat diotomatisasi, tetapi prinsip penataan dan tanggung jawab tidak muncul otomatis. Prompt AI terbaik bukanlah istilah pengembangan yang panjang dan sulit, melainkan dokumen yang membedakan dengan jelas kebijakan yang telah diputuskan operator dan pertanyaan yang belum diputuskan.

## FAQ

### Mengapa bermasalah jika urutan default pencarian mal belanja ditetapkan berdasarkan yang terbaru didaftarkan?
Urutan terbaru didaftarkan hanya mencerminkan waktu pendaftaran, sehingga produk yang habis stok, belum melalui pemeriksaan, atau memiliki daya jual rendah dapat menempati posisi teratas. Lebih aman untuk terlebih dahulu memastikan relevansi dengan kata pencarian dan status yang memungkinkan penjualan, lalu menggabungkan sinyal seperti tingkat konversi, kecepatan penjualan, dan keandalan rating.

### Apakah bobot urutan rekomendasi boleh ditentukan otomatis oleh AI?
AI dapat mengusulkan rumus kandidat dan membuat kode simulasi, tetapi tujuan dan batas toleransi harus ditentukan oleh operator. Bobot harus dievaluasi secara offline dengan data historis, lalu diubah setelah melalui A/B test terbatas dan ketentuan penghentian.

### Apakah produk yang habis stok harus disembunyikan sepenuhnya dari hasil pencarian?
Jika ada kemungkinan restok dan pelanggan dapat menggunakan notifikasi restok, lencana habis stok dan penempatan di urutan belakang lebih berguna daripada penghapusan penuh. Produk yang habis stok dalam jangka panjang atau dihentikan pasokannya sebaiknya disembunyikan berdasarkan kriteria terpisah, dan ketersediaan pembelian harus diverifikasi kembali pada tahap keranjang dan pembayaran.

### Apakah benar halaman detail produk yang penjualannya telah berakhir dihapus menjadi 404?
Tidak selalu demikian. Jika ada nilai dari tautan lama, riwayat pesanan, pemberitahuan keselamatan, atau panduan produk pengganti, halaman detail dapat dipertahankan sambil menampilkan dengan jelas bahwa penjualan telah berakhir dan pembelian tidak tersedia. Jika sama sekali tidak ada nilai konten dan penghapusan permanen memang tepat, kebijakan 404 atau 410 dapat ditinjau.

### Mana yang lebih baik untuk mal belanja, paginasi atau infinite scroll?
Untuk hasil pencarian yang mengutamakan perbandingan dan kunjungan ulang, paginasi bernomor atau metode lihat lebih banyak umumnya lebih mudah dikelola. Jika menggunakan infinite scroll, status URL, tombol kembali, posisi scroll, aksesibilitas, dan pemulihan error harus diselesaikan, dan ini lebih cocok untuk feed berbasis penemuan.

### Jika menerapkan pencarian AI atau pencarian vektor, apakah pencarian teks yang ada tidak diperlukan lagi?
Tetap diperlukan. Pencarian belanja yang menuntut kecocokan tepat seperti SKU, nama model, merek, dan spesifikasi harus berbasis pada pencarian teks. Pencarian semantik digunakan sebagai lapisan pendukung untuk memperluas kandidat dengan ungkapan yang berbeda, dan harus dihubungkan dengan ID produk nyata serta data stok.

### Jika hanya menyimpan kata pencarian dan jumlah pencarian, apakah tidak ada masalah data pribadi?
Tidak bisa dianggap otomatis aman. Kata pencarian dapat berisi email, nomor telepon, nomor pesanan, atau konten sensitif, dan jika digabungkan dengan pengenal lain dapat digunakan untuk melacak individu. Diperlukan minimisasi tujuan, masking, kontrol akses, serta penyimpanan terpisah antara data asli dan data agregat.

### Apakah produk iklan boleh ditempatkan di bagian atas urutan rekomendasi?
Yang penting adalah merancang agar paparan iklan tidak disalahartikan sebagai rekomendasi organik biasa. Kandidat iklan dan kandidat organik harus dipisahkan, kartu produk harus menyediakan penanda yang dapat segera dikenali, dan aturan paparan iklan serta metrik kinerja harus dikelola secara terpisah.

### Indeks database apa yang diperlukan untuk pencarian produk?
Jawaban yang tepat bergantung pada kueri aktual dan distribusi data. Untuk filter status dan pengurutan dapat dipertimbangkan indeks keluarga B-tree, untuk pencarian teks penuh indeks terbalik seperti GIN, dan untuk pencarian string serupa keluarga trigram, lalu efektivitasnya harus dikonfirmasi melalui rencana eksekusi dan uji beban.

### Dengan indikator apa kualitas pencarian harus dievaluasi?
Perlu melihat bersama rasio tanpa hasil, rasio klik hasil pencarian, rasio masuk keranjang dan konversi pembelian setelah pencarian, rasio perubahan kata pencarian, serta rasio paparan produk habis stok. Dengan menggabungkan p95 latency, rasio timeout, dan kesegaran indeks, kualitas dan performa dapat dinilai sekaligus.

### Berapa lama log pencarian harus disimpan?
Tidak ada satu periode yang berlaku untuk semua layanan. Kata pencarian asli sebaiknya hanya disimpan selama periode minimum yang diperlukan untuk analisis, sedangkan tren jangka panjang sebaiknya disimpan sebagai data agregat yang menurunkan risiko data pribadi. Tujuan penyimpanan, siklus penghapusan, dan hak akses harus diselaraskan dengan kebijakan pemrosesan data pribadi serta kebijakan internal.

### Apa kalimat terpenting untuk membuat AI bertanya sebelum implementasi?
Anda dapat menginstruksikan, “Sebelum mulai implementasi, jika ada keputusan di antara kebijakan yang belum saya tentukan yang memengaruhi hasil, tanyakan terlebih dahulu, dan tampilkan asumsi yang ditentukan secara sewenang-wenang dalam daftar terpisah.” Setelah itu, jawaban tersebut harus tercermin dalam dokumen kebijakan, kontrak API, dan ketentuan pengujian agar efektif.

## Sources

- [Komisi Perdagangan yang Adil: Sanksi dalam kasus tindakan menarik pelanggan melalui tipu daya oleh Coupang dan CPLB](https://www.ftc.go.kr/www/selectBbsNttView.do?bordCd=3&key=12&nttSn=43448&pageIndex=1&pageUnit=10&rltnNttSn=46624&searchCnd=all&searchViolt=0604)
- [Law Times: Gugatan Coupang-Komisi Perdagangan yang Adil, kasus Naver Shopping menjadi isu sengketa](https://www.lawtimes.co.kr/news/articleView.html?idxno=218796)
- [Pusat Informasi Hukum Nasional: Undang-Undang tentang Kewajaran Pencantuman dan Periklanan](https://www.law.go.kr/LSW/lsInfoP.do?lsId=002011)
- [Pemrosesan Kasus Online Komisi Perdagangan yang Adil: Keputusan 2014-103 terkait pencantuman iklan kata kunci](https://case.ftc.go.kr/ocp/co/openDocView.do?docCnvrMnNo=12808&docId=20221229104156671154&docTy=LTFR&id=OCPLTFR20140759018192)
- [Komisi Perdagangan yang Adil: Sanksi atas pelanggaran Undang-Undang Pencantuman dan Periklanan serta Undang-Undang Perdagangan Elektronik oleh platform penjualan produk terkenal berharga tinggi](https://www.ftc.go.kr/www/selectBbsNttView.do?bordCd=3&key=12&nttSn=46006&pageIndex=2&pageUnit=10&rltnNttSn=37048&searchCnd=all&searchCtgry=01%2C02&searchKrwd=%EA%B4%91%EA%B3%A0&searchViolt=0609)
- [Pusat Informasi Hukum Nasional: Undang-Undang Perlindungan Informasi Pribadi](https://www.law.go.kr/LSW/lsInfoP.do?ancYnChk=0&lsId=011357)
- [Baymard Institute: Praktik Terbaik UX Ecommerce Berbasis Data](https://baymard.com/learn/ecommerce-ux-best-practices)
- [Google Search Central: Paginasi dan Pemuatan Halaman Bertahap](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
- [Dokumentasi PostgreSQL: Pencarian Teks Lengkap](https://www.postgresql.org/docs/current/textsearch.html)
- [Dokumentasi PostgreSQL: Jenis Indeks yang Disukai untuk Pencarian Teks](https://www.postgresql.org/docs/current/textsearch-indexes.html)
- [Dokumentasi PostgreSQL: pg_trgm](https://www.postgresql.org/docs/current/pgtrgm.html)

## Images

![Jaringan AI, antarmuka pencarian produk, kartu kebijakan, dan dasbor analitik untuk perencanaan pencarian toko online](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjM1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--6c0b755d9bc5bce8a57d0306acd05a2302fe176e/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2021%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2002_29_49.webp)
![Peta pencarian belanja AI dengan relasi produk, rekomendasi alternatif, dan penyimpanan data aman](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjM2MiwicHVyIjoiYmxvYl9pZCJ9fQ==--7aa0dfb3a548f3bdfe5cf4f73b74b387fe8da178/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2021%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2002_32_48.webp)