Sumber: food_retail_database_research.md
Research: Memulai Food Database dan Retail Product Database
Dokumen ini menjawab dua pertanyaan konkret sebagai fondasi untuk dua ide intelligence layer Anda:
-
Untuk Food API (Menu Voice Intelligence): mulai dari mana, dan menu seperti apa yang harus dikumpulkan.
-
Untuk Retail Product Commerce Intelligence: dari data produk seperti apa Anda harus mulai mengumpulkan.
Kesimpulan utama: kedua database ini bukan sekadar “list makanan/produk” yang besar. Yang bernilai adalah catalog terstruktur, dengan alias/varian, atribut yang dinormalisasi, dan feedback loop dari transaksi nyata. Volume besar tanpa struktur = liability. Sampel kecil yang bersih dan tervalidasi = moat.
1. Food Database untuk Menu Voice Intelligence API
1.1 Framing ulang: bukan “semua menu di Indonesia”
Godaan pertama biasanya adalah membangun mega-database semua menu Indonesia. Ini keliru untuk value proposition Anda. Yang menaikkan presisi voice-to-order bukanlah cakupan universal, tapi kualitas catalog per-merchant ditambah layer pengetahuan bahasa Indonesia (alias, dialek, modifier). Guidance industri konsisten: mulai dari scope kecil yang terikat ke ownership dan aktualitas data (Actowiz, Capsolver).
Jadi database Anda punya dua lapis:
-
Lapis A — Merchant catalog: menu spesifik satu merchant/outlet (varian, harga, ketersediaan). Ini yang dipakai matching saat runtime.
-
Lapis B — Menu ontology Indonesia: pengetahuan kanonik tentang “apa itu nasi goreng”, sinonim, dialek, modifier standar, keluarga hidangan. Ini yang membuat sistem paham walaupun merchant menamai berbeda.
Riset akademis Nusantara Food Ontology (SAFE Nusantara) sudah membuktikan pendekatan ontology semi-otomatis untuk makanan Indonesia layak dilakukan dari sumber online berbahasa Indonesia/Melayu (Telkom University IJoICT).
1.2 Dari mana mulai: sumber seed data
Prioritaskan sumber yang legal, terstruktur, dan mudah divalidasi manusia, bukan yang paling besar.
-
Merchant design partner (paling penting). Ambil 3–5 outlet nyata (misal: 1 warung nasi, 1 coffee shop, 1 fast casual, 1 resto Padang, 1 kedai bakmi). Minta menu asli mereka (PDF, foto, spreadsheet, atau ekspor POS). Ini menjadi gold set. Cold-start playbook standar menyarankan seed expert-labeled + synthetic fill + human review loop, bukan langsung skala besar (Avante Ventures).
-
Dataset Indonesia yang sudah ada untuk knowledge ontology (Lapis B), bukan untuk transaksi:
-
Panganku (Data Komposisi Pangan Indonesia) — 200+ bahan/pangan dengan komposisi nutrisi resmi. Cek data-sharing agreement sebelum redistribusi (panganku.org licensing).
-
Indonesian Food Recipes API by ricotandrio — 13.503 resep asal Kaggle. Berguna untuk ekstraksi bahan, teknik memasak, dan alias hidangan.
-
Indonesian Food and Drink Nutrition Dataset (Kaggle) — 1.346 item dengan gambar dan nutrisi.
-
Indonesian Food Image Classification (Kaggle) — 6.500 gambar untuk visual grounding.
-
Wikipedia list of nasi goreng variations — contoh sempurna untuk ekstraksi alias/varian (Aceh, Jawa, Padang, gila, kambing, dst).
-
Menu terbuka di platform pesan-antar hanya sebagai referensi struktur (kategori section, penamaan modifier), bukan untuk redistribusi. Menu di GoFood/GrabFood/ShopeeFood dilindungi ToS; tanyakan izin merchant, atau tarik lewat authorized integration seperti Klikit atau DaftarMenu.
-
Sumber ontology umum sebagai skeleton skema:
-
Schema.org Menu untuk Menu, MenuSection, MenuItem, MenuAddOn.
-
Toast menu hierarchy untuk hierarki Menu → Group → Item → Modifier Group → Modifier Option yang battle-tested.
-
Open Food Facts Structured Data untuk model data bahan/nutrisi.
1.3 Menu seperti apa yang harus dikumpulkan (bukan hanya “nama + harga”)
Untuk voice API yang benar-benar akurat, satu MenuItem harus punya jauh lebih banyak metadata daripada yang biasanya disimpan POS. Skema variant/modifier terpisah adalah standar industri (Software Engineering StackExchange, OrderViaChat modifiers guide, Rosuii).
Bidang minimum per MenuItem (per merchant):
-
item_id,merchant_id,outlet_id -
canonical_name(rujukan ke Lapis B, misaldish://nasi-goreng) -
display_name(nama di menu merchant, contoh: “Nasgor Spesial Om Bagong”) -
aliases[](nasgor, fried rice, NG spesial) — kunci utama untuk pengenalan suara -
section(Makanan Utama, Camilan, Minuman Panas) -
base_price,currency,tax_flag -
status(active, paused, out_of_stock) -
image_url,description -
variants[](Regular/Jumbo, Ice/Hot, Panas/Dingin — one must be picked, may change price) -
modifier_groups[]denganmin_select,max_select,required -
masing-masing modifier:
name,price_delta,default,aliases[](contoh: “pedes”, “extra pedas”, “level 3” untuk modifier Spice Level) -
combo_children[](untuk paket) -
dietary_flags(halal, vegetarian, no-pork, no-msg, gluten-free) -
spice_level_default,spice_level_range -
prep_time_estimate -
channel_availability(dine-in only, delivery only, jam khusus) -
updated_at
Untuk Lapis B (Menu Ontology Indonesia), satu canonical dish punya:
-
canonical_id,canonical_name_id(Bahasa Indonesia),canonical_name_en -
dish_family(nasi, mie, ayam, minuman kopi, teh, dst) -
region_origin(Padang, Aceh, Solo, Manado) -
key_ingredients[] -
typical_modifiers[](untuk kopi: hot/ice, size, sugar level, milk type) -
common_aliases[]termasuk dialek/slang (nasgor, mi ayam vs mie ayam, es teh manis = ETM) -
common_misspellings[]dan variasi ASR umum (dari analisis transkrip Whisper) -
phonetic_variants[](untuk toleransi pengucapan) -
parent_dish/child_variants[](nasi goreng → nasi goreng Aceh, nasi goreng kambing) -
homophone_conflicts[](nasi vs nasil vs nasi kah)
1.4 Urutan pengumpulan yang direkomendasikan
-
Minggu 1–2 — 1 merchant, 1 vertical. Pilih satu segmen yang sempit (misal: coffee shop lokal, atau warung Padang). Digitalkan menu lengkap dengan semua variant/modifier. Ini benchmark kualitas.
-
Minggu 3–4 — 3–5 merchant sejenis. Bandingkan penamaan. Ekstrak alias dan modifier pattern. Ini yang membuat Lapis B mulai terbentuk.
-
Minggu 5–8 — expand ke 2–3 vertical berbeda. Nasi kotak/rice bowl, bakmi/mie, minuman boba, dessert. Setiap vertical punya pola modifier khas (level pedas untuk noodle, sugar/ice level untuk boba, dsb).
-
Sepanjang proses — kumpulkan real audio. Rekam pesanan aktual (dengan izin) di outlet design partner. Setiap transkrip yang di-koreksi kasir jadi labeled data untuk fine-tuning matcher.
-
Modifier alias mining. Dari transkrip nyata, ekstrak semua cara pelanggan menyebut “tidak pedas”, “less ice”, “tanpa gula”, “extra keju”. Ini yang tidak bisa diambil dari internet.
Target realistis fase awal: 20 outlet, ~600–1.500 canonical menu items, dengan 3–8 alias rata-rata per item, dan 500–2.000 modifier options ternormalisasi. Kualitas > volume.
1.5 Pitfall yang harus dihindari
-
Scraping GoFood/GrabFood/ShopeeFood tanpa izin merchant/platform — nilainya rendah (stale, mangled, ToS-risk) dan tidak memberi data modifier lengkap (Capsolver best practice).
-
Mengejar ribuan menu tanpa modifier — precision voice-to-order runtuh di modifier, bukan di dish name.
-
Membangun ontology sebelum menyentuh transaksi nyata — pola alias Indonesia yang bernilai tinggi (nasgor, ETM, es te, kopsus) baru muncul dari log ordering.
-
Tidak menyimpan
updated_atdan versi harga — merchant sering ubah harga tanpa memberi tahu, mahal jika API Anda mengembalikan harga stale.
2. Retail Product Database untuk Product Identity Layer
2.1 Framing ulang: apa yang dijual bukan “data produk”
Yang dijual adalah canonical product record (golden record) — satu identitas produk terverifikasi yang bisa dipakai lintas storefront, feed, marketplace, POS, dan AI discovery (Claro AI on canonical records). Fuzzy matching saja tidak cukup; ini kerja entity resolution (Claro AI comparison).
Jadi produk yang dikumpulkan harus dianggap sebagai kandidat golden record: setiap SKU harus punya identifier stabil, atribut yang mengikuti skema, dan bukti sumber (provenance).
2.2 Pilih vertikal dulu, jangan “semua produk”
Semua panduan PIM konsisten bilang: audit dan model atribut sebelum menulis satu baris data (Atropim PIM Strategy, Pimcore best practices, Anchanto). Pilih satu vertikal di mana atribut sangat menentukan pilihan pembeli. Yang cocok dengan minat Anda:
-
Automotive & motorcycle parts (fitmen tinggi: brand, part_number, OEM cross-ref, cocok kendaraan mana).
-
Industrial & robotics components (spec-driven: torque, voltage, dimension, sertifikasi).
-
Consumer packaged goods (CPG) Indonesia (barcode-driven, foto kemasan, halal cert, netto).
-
3D-printable STL & digital assets (metadata sangat berbeda: license, file size, print time, material).
Rekomendasi: mulai dari satu vertikal dengan identifier eksternal yang stabil (automotive atau CPG). Alasannya: identifier stabil (GTIN atau OEM part number) memberi Anda “ground truth pengait” untuk deduplikasi.
2.3 Identifier standar yang wajib dipahami
Ini fondasi. Semua panduan Google Merchant dan GS1 mengharuskan minimal salah satu identifier (Google Merchant Center, SKULaunch on GTIN/UPC/EAN/MPN, Seegea on MPN):
-
GTIN (Global Trade Item Number) — payung untuk UPC-A (12), EAN-13, ISBN, ITF-14. Wajib kalau produk punya barcode.
-
MPN (Manufacturer Part Number) — kode manufaktur sendiri. Wajib untuk part industrial/otomotif tanpa barcode konsumen.
-
Brand — hampir selalu wajib.
-
SKU — internal Anda, bukan identifier universal (OmniOrders on SKU).
Kombinasi golden record ideal: brand + gtin (retail) atau brand + mpn (industrial).
2.4 Sumber data untuk memulai
Prioritaskan sumber yang legal, memiliki identifier, dan dapat diverifikasi.
Global / lisensi terbuka:
-
Open Food Facts — kolaboratif, database GTIN untuk makanan/minuman, ada dump di Kaggle. Cakupan Indonesia terbatas tapi berguna sebagai skema referensi.
-
Datakick / gtinsearch.org — proyek open GTIN dengan API gratis.
-
brocade.io — open GTIN/barcode database.
-
Verified by GS1 — sumber otoritatif untuk memvalidasi GTIN/GLN/company.
Indonesia:
-
GS1 Indonesia (ui.gs1id.org) — lookup barcode anggota GS1 Indonesia (otoritatif tapi tertutup, cek program kemitraan).
-
DataKart GS1 India — model repositori nasional yang bisa Anda pelajari sebagai referensi arsitektur.
-
API item produk Indonesia (ariph007) — 50.600 produk dengan barcode+keyword; berguna untuk seed data awal.
-
Mitra Informatika barcode DB — 61.166 produk (per Agustus 2021). Kualitas variatif; gunakan sebagai bootstrap, bukan authoritative.
Skema atribut untuk dijadikan referensi (jangan reinvent):
-
Google Merchant Center product data spec — atribut wajib/opsional untuk 30+ vertikal.
-
Google Product Taxonomy (~6.000 kategori) sebagai starting taxonomy.
-
GS1 Global Data Model — model atribut lintas industri untuk consumer goods.
-
WISEPIM taxonomy guides — perbandingan 8 taxonomy standard (GPC, UNSPSC, ETIM, eCl@ss, Amazon BTG).
Untuk taxonomy vertikal spesifik: ETIM untuk industrial/electrical, eCl@ss untuk industrial umum, UNSPSC untuk procurement, Amazon Browse Tree untuk retail marketplace.
2.5 Data produk seperti apa yang harus dikumpulkan
Skema minimum canonical product (versi pertama, akan tumbuh) — mengikuti pola Shopify catalog + Merchant Center + GS1 GDM:
Core identity:
-
product_id(internal ULID/UUID) -
brand(string, dinormalisasi ke brand table) -
gtin(nullable, tapi validasi checksum kalau ada) -
mpn(nullable) -
title_canonical(bentuk baku, contoh: “Indomie Goreng Rendang 85g”) -
title_variants[](bagaimana penjual lain menulis: Indomie Goreng Rasa Rendang, Indomie Rendang 85gr) -
description_short,description_long -
language(id-ID, en, dst)
Categorization:
-
google_product_category(string atau ID Google taxonomy) -
internal_category_path(untuk vertikal Anda sendiri) -
taxonomy_refs[](mapping ke ETIM/UNSPSC kalau industrial)
Attributes (structured, per-vertikal):
-
attributes[]sebagai array{key, value, unit, source, confidence}— dinormalisasi ke attribute dictionary. Contoh untuk otomotif:oem_number,compatible_models,year_range,position(front/rear). Untuk CPG:netto_gram,halal_cert,bpom_number,expiry_type. Untuk industrial:voltage,torque_nm,certification_iso.
Media & content:
-
primary_image_url,additional_images[],packaging_shots[] -
image_embeddings[](SigLIP2 atau Qwen3-VL untuk visual retrieval — sudah pernah Anda pertimbangkan) -
ocr_textdari label (untuk retrieval dan validasi netto/expiry/batch)
Commerce:
-
default_currency,msrp_range -
pack_size,case_pack -
units_of_measure -
is_variant_of/variants[](untuk warna/ukuran)
Governance & trust:
-
source_records[](setiap kali data masuk: supplier feed, manual, OCR, marketplace scrape) dengansource_id,fetched_at,raw_payload -
merge_history[](kandidat merge, siapa/kapan yang confirm) -
confidence_scoresper atribut -
verified_by_operator_at -
compliance_flags(halal_verified, bpom_verified, sni_verified)
Structural best-practice ini konsisten di panduan Rocket.new, Atropim, MongoDB retail reference, dan Shopify catalog guide.
2.6 Urutan pengumpulan yang direkomendasikan
-
Minggu 1 — pilih 1 vertikal + 1 kategori sempit. Contoh: “oli motor 4-tak Indonesia” atau “instant noodle Indonesia 5g–120g pack”. Kategori sempit dulu.
-
Minggu 2 — kumpulkan 200–500 SKU seed dengan identifier lengkap (brand + GTIN atau brand + MPN). Sumber: satu supplier catalog nyata + Open Food Facts + API produk Indonesia + verifikasi GS1.
-
Minggu 3 — model atribut. Untuk kategori tersebut, definisikan 15–25 atribut wajib. Validasi dengan orang yang belanja/menjual kategori itu.
-
Minggu 4 — golden record pipeline. Bangun deduplication rules: exact GTIN, fuzzy pada brand+title, image embedding similarity, human review queue. Ini adalah kernel dari “Product Identity Layer”-Anda.
-
Minggu 5–8 — expand ke supplier intake. Ambil 1 supplier feed nyata (Excel/CSV berantakan) dan proses lewat pipeline. Setiap konflik yang di-resolve oleh operator = training data untuk identity gate.
-
Sepanjang proses — governance layer. Simpan setiap sumber, versi, dan keputusan merge. Ini yang tidak dimiliki PIM open-source biasa dan jadi differensiator.
Target realistis fase awal: 1 vertikal, 1–3 kategori, ~1.000–3.000 golden records dengan 90%+ atribut wajib terisi dan provenance lengkap. Ini jauh lebih valuable daripada 100.000 produk dangkal.
2.7 Pitfall yang harus dihindari
-
Menyalin Amazon/Tokopedia/Shopee title mentah tanpa normalisasi — Anda akan mewarisi duplikat, brand yang tidak konsisten, dan ToS-risk.
-
Membuat SKU internal jadi identifier utama — SKU adalah internal, bukan universal (SKULaunch).
-
Menyimpan atribut sebagai JSON blob tanpa attribute dictionary — Anda akan kehilangan konsistensi unit (kg vs gram, mm vs cm), sulit di-query.
-
Tidak menyimpan
raw_payloadsumber — begitu supplier ubah format, Anda tidak bisa reproduksi identifikasi. -
Mengabaikan image data — untuk POS visual retrieval dan verifikasi kemasan Indonesia, embedding gambar adalah bagian dari identity, bukan opsional.
3. Benang merah dua database
Meskipun beda vertikal, arsitektur data intinya sama:
| Aspek | Food Database | Retail Product Database |
|---|---|---|
| Unit dasar | Menu item + modifier tree | Product record + attributes |
| Identifier stabil | canonical_dish_id + merchant SKU | GTIN / MPN + brand |
| Alias/varian | aliases[], phonetic_variants[] | title_variants[], synonyms[] |
| Governance | verified_by_merchant, price version | source_records[], merge_history[] |
| Feedback loop | Koreksi kasir/pelanggan pada order | Konfirmasi operator saat entity resolution |
| Cold-start | 3–5 merchant seed + ontology publik | 1 vertikal + 1 supplier + open GTIN feeds |
| Moat | Alias Indonesia + modifier semantics | Golden record + provenance + attribute schema |
Untuk keduanya, aturan yang sama berlaku: kumpulkan sedikit dengan struktur dan provenance yang benar, biarkan volume tumbuh dari transaksi/koreksi nyata, jangan bootstrap dengan scraping mentah tanpa validasi.
4. Next action konkret (2 minggu ke depan)
Untuk Food API:
-
Pilih 1 merchant design partner (idealnya coffee shop atau warung Padang di Surabaya) — ambil menu asli lengkap.
-
Definisikan skema MenuItem + Modifier v1 di Neon Postgres. Import Schema.org Menu + Toast hierarchy sebagai pola.
-
Import Panganku dan Kaggle nutrition dataset sebagai Lapis B ontology awal.
-
Ekstrak 30–50 dish canonical dengan aliases dari Wikipedia + resep Indonesia.
Untuk Retail Database:
-
Pilih 1 vertikal + 1 kategori sempit (rekomendasi: CPG makanan/minuman Indonesia karena punya barcode + relevan dengan Food API-Anda).
-
Definisikan attribute dictionary v1 untuk kategori itu (15–25 atribut) mengacu pada Google Merchant spec + GS1 GDM.
-
Seed 200–500 SKU dari API produk Indonesia + Open Food Facts Indonesia + verifikasi GTIN via Verified by GS1.
-
Bangun entity resolution pipeline sederhana: exact GTIN match → fuzzy brand+title → image embedding → operator review queue.
Setelah itu, keduanya bisa saling menyuap: golden CPG records menjadi Lapis B untuk food API (mengenali brand minuman/snack di pesanan), sementara transaksi voice ordering menjadi sumber attribute enrichment (harga, ketersediaan, packaging) untuk retail records.