NAVV
Navv Commerce Intelligence · Dokumen riset

Rencana data CPG, menu, dan database produk

Dua dokumen sumber disajikan bersama agar strategi pengumpulan data retail dan restoran mudah dibaca berdampingan.

Catatan bukti: isi, angka, dan rekomendasi di bawah berasal dari naskah sumber. Target bukan data yang sudah terkumpul; klaim dan sumber tetap perlu diperiksa sebelum menjadi dasar keputusan atau komitmen.
Dokumen 1

Sumber: cpg_and_public_menu_data_plan.md

Rencana Detail: CPG Makanan Kemasan + Menu Publik

Dokumen ini menerjemahkan strategi umum menjadi eksekusi konkret untuk dua stream data:

  1. CPG Makanan Kemasan Indonesia — foundation retail product database.

  2. Menu Publik (Franchise & Chain) — bootstrap food menu database dari sumber yang boleh dipakai.

Dua stream ini dipilih karena saling melengkapi: item CPG (Indomie, Kopiko, Aqua) muncul di menu warung/kafe, dan menu chain memberi Anda ontology hidangan Indonesia yang sudah ternormalisasi oleh brand nasional.


Bagian A: CPG Makanan Kemasan Indonesia

A.1 Kategori otoritatif yang harus dipakai

Jangan bikin kategori sendiri. Gunakan dua taxonomy paralel:

1. BPOM (regulator Indonesia) — 16 kategori pangan (Keputusan Kepala BPOM tentang Kategori Pangan, BPOM Regulation No. 34/2019, dijelaskan di Insightof.id dan istanaumkm.pom.go.id):

KodeKategori
01.0Produk susu dan analognya
02.0Lemak, minyak, dan emulsi minyak
03.0Es untuk dimakan (edible ice, sherbet, sorbet)
04.0Buah dan sayur (termasuk jamur, umbi, kacang, rumput laut, biji-bijian)
05.0Kembang gula / permen dan cokelat
06.0Serealia dan produk serealia
07.0Produk bakeri
08.0Daging dan produk daging (termasuk unggas & buruan)
09.0Ikan dan produk perikanan (moluska, krustase, amfibi, reptil)
10.0Telur dan produk-produk telur
11.0Pemanis, termasuk madu
12.0Garam, rempah, sup, saus, salad, produk protein
13.0Produk pangan untuk keperluan gizi khusus
14.0Minuman (tidak termasuk produk susu)
15.0Makanan ringan siap santap
16.0Pangan campuran (komposit)

Ini wajib kalau produk Anda menyentuh BPOM/nomor izin edar. Setiap makanan olahan yang dijual di Indonesia harus punya kode kategori BPOM ini.

2. GS1 GPC (Global Product Classification) — 4 tingkat hierarki: Segment → Family → Class → Brick (GS1 how GPC works, GS1 Switzerland, GS1 Netherlands one-pager). Untuk food semuanya di bawah Segment “Food/Beverage/Tobacco”. Ini yang dipakai retailer besar dan supplier dan menjadi jembatan ke ekosistem global.

3. Google Product Taxonomy ID 412 “Food, Beverages & Tobacco” (Google Merchant Center, Marpipe guide, taxonomy dump on GitHub). Wajib kalau produk akan muncul di Google Shopping / feed publik.

4. Open Food Facts categories taxonomy (wiki) — kolaboratif, multi-lingual, hirarkis dengan sinonim. Untuk seed data dan matching brand internasional.

Rekomendasi implementasi: primary key kategori Anda gunakan BPOM code untuk urusan Indonesia, dan simpan mapping tabel ke GPC brick, Google category ID, dan Open Food Facts category tag. Kalau kelak Anda ekspor ke marketplace atau feed, mapping sudah tersedia.

A.2 Enam kategori awal (fokus 90 hari pertama)

Dari 16 kategori BPOM, pilih 6 yang paling relevan untuk CPG makanan kemasan yang beredar di Indomaret/Alfamart dan menjadi input voice ordering (banyak disebut nama brand di warung/kopi):

PrioritasBPOMFokus kategoriAlasan strategis
P115.0Makanan ringan siap santap (snack, keripik, wafer)Volume tertinggi, brand-driven, banyak disebut di voice orders
P106.0Serealia (mi instan, sereal, oatmeal)Indomie/Mie Sedaap dominan; anchor Indonesian identity
P114.0Minuman non-susu (RTD tea, kopi kemasan, sari buah, air)Menu warkop selalu ada Teh Botol, Aqua, Kopiko
P207.0Produk bakeri (biskuit, roti, wafer roll)Roma, Malkist, Beng-Beng adjacencies
P205.0Kembang gula & cokelatSilver Queen, Cha Cha, Kopiko candy
P201.0Susu dan analognya (susu UHT, kental manis, susu bubuk)Frisian Flag, Ultra Milk, Bear Brand banyak dipakai kopi kekinian

Vertikal “huruf P” yang beredar di Alfamart/Indomaret dokumentasinya sangat baik untuk seed volume (listing Pikiran Rakyat Malang dan 50 snack Alfamart & Indomaret).

A.3 Big-3 principal Indonesia (starting point untuk brand)

3 principal ini kuasai ~60%+ shelf minimarket Indonesia (Kontan report on FMCG Indonesia). Mulai dari brand mereka:

Tambahkan 5–7 principal tier-2: Nestlé Indonesia, Unilever Food (Bango, Royco), Garudafood (Kacang Garuda, Gery, Chocolatos), Orang Tua (Tango, Formula, Vita Jelly), Kraft Heinz ABC (kecap ABC, saus), Ultrajaya (Ultra Milk, Teh Kotak), Sinar Sosro (Teh Botol, S-tee, Fruit Tea).

Total 10 principal → mudah 300–600 SKU dengan barcode legal di 6 kategori.

A.4 Skema atribut produk CPG (v1) — mengikuti regulasi Indonesia

Regulasi label pangan olahan Indonesia (BPOM No. 31/2018 diperbaharui No. 20/2021) mewajibkan atribut spesifik di label (tabel-gizi.pom.go.id, Artworkflow guide, Insightof labeling). Skema Anda harus menangkap semuanya:

Core identity (wajib): - product_id (ULID internal) - gtin (EAN-13, barcode) — divalidasi checksum - brand (Indomie, Kopiko, Roma…) - manufacturer (PT Indofood CBP Sukses Makmur, PT Mayora Indah…) - title_id (nama produk resmi Bahasa Indonesia) - title_variants[] (bagaimana konsumen menyebut: “Indomie Rendang”, “Indomie Goreng Rendang”, “Indom Rendang”) - bpom_category_code (contoh: 06.4.1 untuk mi instan) - bpom_registration_number (MD/ML/BPOM RI MD xxxxxxx atau P-IRT)

Compliance Indonesia (wajib): - halal_status (halal_certified / not_certified / not_applicable) - halal_cert_number + halal_cert_issuer (LPPOM MUI / BPJPH) - halal_harmonization_code — mengikuti Kode Sistem Harmonisasi Halal BPJPH 2025 - production_country (ID / imported) - importer_name (jika impor)

Packaging & size (wajib): - net_weight_value, net_weight_unit (gram/ml) - pack_type (sachet, pouch, bottle, can, tetra) - pack_size_group (single-serve, family, jumbo) - case_pack_qty - barcode_type (EAN13, ITF14 untuk inner/outer)

Nutrition (opsional tapi disarankan): - serving_size, servings_per_pack - nutrition_facts_json (energi kkal, protein, lemak, karbohidrat, gula, natrium) - allergens[] (susu, telur, gluten, kacang, kedelai)

Media: - primary_image (foto packshot depan) - back_label_image (untuk OCR ingredients & expiry) - image_embeddings (SigLIP2 atau Qwen3-VL) - ocr_text_ingredients

Commerce: - msrp_range - available_at[] (Alfamart, Indomaret, Superindo, Alfamidi, warung) - sap_gpc_brick, google_category_id (mapping)

Governance: - source_records[] (setiap payload: produsen situs, GS1 lookup, Open Food Facts, scan operator) - verified_by_bpom_registry_at - verified_by_halal_registry_at - merge_history[] - confidence_scores per atribut

Ini penting: banyak PIM tidak menyimpan bpom_registration_number atau halal_harmonization_code. Ini yang jadi differensiator untuk data Indonesia.

A.5 Sumber data (urut prioritas legal)

  1. Situs prinsipal (paling authoritative, aman legal):

  2. indofood.com

  3. mayoraindah.co.id

  4. wingscorp.com / wingsfood

  5. Halaman produk masing-masing brand (indomie.com, teh-botol-sosro.com, ultramilk.co.id)

  6. Registri regulator (authoritative untuk compliance):

  7. BPOM Cek BPOM untuk validasi nomor izin edar

  8. BPJPH Halal Registry untuk validasi sertifikat halal

  9. GS1 Indonesia lookup untuk otoritas GTIN

  10. Open dataset:

  11. Open Food Facts world-id — cakupan Indonesia terbatas tapi tumbuh; kontribusi Anda bisa dua arah (ambil + berikan kembali)

  12. Datakick / gtinsearch.org

  13. Kaggle Open Food Facts dump

  14. API produk Indonesia (ariph007) — 50.600 seed products, sanity-check dulu

  15. Mitra Informatika DB — 61.166 seed, kualitas variatif

  16. Retail public content (untuk cross-reference harga & ketersediaan, bukan sumber utama):

  17. Katalog promo Alfamart/Indomaret PDF publik (Rakyat Cirebon Disway example)

  18. Blog listicles snack minimarket — hanya untuk alias mining, bukan authoritative

  19. Verifikasi manual:

  20. Scan kemasan fisik di minimarket sekitar Surabaya untuk 100 SKU teratas (paling akurat untuk atribut kemasan, netto, nomor BPOM)

A.6 Step-by-step 12 minggu

Minggu 1: skema + taxonomy - Setup Neon Postgres. Buat 6 tabel utama: products, brands, manufacturers, categories_bpom, category_mappings, source_records. - Import BPOM 16 kategori + subkategori sebagai seed. - Import Google Product Taxonomy dump (~5.500 kategori) dan Open Food Facts categories. - Setup mapping table skeleton (BPOM code ↔ GS1 GPC brick ↔ Google category ↔ OFF tag).

Minggu 2: brand & principal master - Seed 10 principal (Indofood, Mayora, Wings, Nestlé ID, Unilever, Garudafood, OT, Kraft ABC, Ultrajaya, Sosro) dari situs korporat resmi. - Untuk tiap principal, katalogkan brand family (Indofood → Indomie, Sarimi, Chitato, dst). - Attributes yang dikumpulkan per brand: parent_company, established, principal_category, logo, brand_website.

Minggu 3–4: kategori P1 — snack (BPOM 15.0) - Target 150–200 SKU snack terpopuler. Sumber utama: situs prinsipal + Open Food Facts world-id + scan fisik top 30. - Atribut wajib terisi ≥ 90%: gtin, brand, bpom_reg_no, halal_status, net_weight, pack_type, primary_image. - Bangun entity resolution v1: exact GTIN → fuzzy (brand + normalized_title) → operator queue.

Minggu 5–6: kategori P1 — mi instan & serealia (BPOM 06.0) - Target 80–120 SKU. Ini brand-heavy: Indomie (~30 varian), Mie Sedaap (~15), Sarimi, Supermi, Pop Mie, Sereal Energen, Quaker Oats, Milna. - Focus pada varian rasa (Rendang, Ayam Bawang, Goreng, Kari Ayam) sebagai title_variants[]. Ini akan dipakai Food API untuk voice matching.

Minggu 7–8: kategori P1 — minuman non-susu (BPOM 14.0) - Target 150–200 SKU. RTD tea (Teh Botol, Teh Pucuk, Frestea), kopi kemasan (Kopiko, Nescafe RTD), sari buah (Buavita, ABC, Minute Maid), AMDK (Aqua, Le Minerale, Cleo). - Perhatian khusus pada pack_size_group dan pack_type — voice orders sering menyebut ukuran (600ml, botol kecil, gelas).

Minggu 9: kategori P2 — bakeri (BPOM 07.0) - Target 80–100 SKU biskuit, wafer, wafer roll. Roma, Beng-Beng, Astor, Malkist, Khong Guan, Nissin, Oreo, Chocolatos.

Minggu 10: kategori P2 — cokelat & permen (BPOM 05.0) - Target 60–80 SKU. Silver Queen, Cha Cha, Choki-Choki, Kopiko candy, Kis, Mentos, Alpenliebe.

Minggu 11: kategori P2 — susu (BPOM 01.0) - Target 60–80 SKU. UHT (Ultra Milk, Frisian Flag, Greenfields, Diamond), SKM (Bendera, Indomilk), susu bubuk (Dancow, Anmum), susu spesial (Bear Brand, HiLo, Milo RTD).

Minggu 12: validasi & governance layer - Cross-validasi 300 SKU teratas ke Cek BPOM untuk bpom_registration_number. - Cross-validasi 300 SKU ke BPJPH untuk halal certificate. - Trigger merge_history review untuk semua candidate merges dengan confidence < 0.9. - Publish v1 golden record set dan dokumentasikan attribute coverage.

Target akhir minggu 12: ~700–900 golden records di 6 kategori BPOM, 10 principal, atribut wajib > 90% terisi, dan setiap SKU punya provenance chain dan minimal 2 sumber cross-validation.


Bagian B: Menu Publik (Franchise & Chain Indonesia)

Untuk Menu Voice Intelligence API, seed dari franchise/chain yang menerbitkan menu di situs resmi. Ini legal untuk dipelajari (public information), memberi Anda alias/varian yang sudah dinormalisasi oleh brand, dan menjadi anchor knowledge Lapis B ontology.

B.1 Prinsip legalitas & etika

  • Baca dulu: pelajari struktur menu, dokumentasikan pattern (bukan copy verbatim untuk redistribusi komersial). Nama hidangan generik tidak protected; deskripsi puitis brand adalah.

  • Kutip sumber: setiap MenuItem simpan source_url dan source_fetched_at.

  • Hormati robots.txt & rate limit: gunakan fetch berjeda, cache lokal, jangan hit real-time saat runtime.

  • Untuk API komersial ke pihak ketiga, jangan expose data brand langsung. Yang di-expose adalah canonical dish + your normalized alias set (Lapis B), bukan menu spesifik chain.

B.2 Tier chain berdasarkan aksesibilitas menu

Tier 1 — Menu publik di situs resmi, terstruktur jelas Prioritas tinggi karena data authoritative dan pattern konsisten.

  • Starbucks Indonesiastarbucks.co.id/menu (beverages: espresso, brewed coffee, frappuccino, tea; food: sandwiches, pastries)

  • McDonald's Indonesia — mcdonalds.co.id/menu (Big Mac, McSpicy, PaNas, ayam goreng McD, sarapan lokal)

  • KFC Indonesia — kfcku.com (paket ayam, Winger, Colonel Yakiniku, minuman)

  • Burger King Indonesia — burgerking.co.id

  • Pizza Hut Indonesia — pizzahut.co.id (paket, size, topping, crust variants)

  • Domino's Pizza Indonesia — dominos.co.id

  • Chatime Indonesiachatime.co.id (kategori: milk tea, fruit tea, brewed tea; topping matrix)

  • Kopi Kenangan — kopikenangan.com

  • Fore Coffee — fore.coffee

  • Janji Jiwa — janjijiwa.com

  • Tomoro Coffee — tomorocoffee.com

  • Mixue — mixue.co.id (es krim, boba, tea)

  • HokBen — hokben.co.id (bento, ramen, side dishes)

  • Solaria — solariagroup.com

  • Yoshinoya Indonesia — yoshinoya.co.id

Tier 2 — Menu publik tapi struktur PDF/gambar (butuh OCR)

  • Warung Padang chain (Sederhana, Salero Bundo, Pagi Sore) — biasanya PDF menu

  • CFC (California Fried Chicken), Texas Chicken Indonesia

  • A&W Indonesia, Wendy's Indonesia

  • Es Teler 77

  • Bakso Boedjangan, Bakso Lapangan Tembak Senayan

  • Sate Khas Senayan

  • Ayam Geprek Bensu, Geprek Bensu, I Am Geprek Bensu

  • Warteg chain yang mulai digitalisasi

Tier 3 — Menu di aggregator dengan izin merchant (Klikit, DaftarMenu, atau langsung ke merchant)

  • Warung/kafe independen — ambil hanya lewat design partnership.

  • Ini sumber TERKAYA untuk alias lokal dan modifier culture, tapi butuh consent explicit.

B.3 Kategori menu Indonesia yang perlu di-taxonomize

Menu chain akan expose kategori berikut. Bangun canonical taxonomy dari sini:

Makanan utama - Nasi: nasi goreng (+ 30 varian by geo/style), nasi uduk, nasi kuning, nasi liwet, nasi campur, nasi padang, nasi ayam, nasi bebek, rice bowl (chicken katsu, beef, salmon) - Mie & bakmi: bakmi ayam, mie goreng, mie kuah, mie ayam pangsit, mie yamin, ramen, udon, soba - Ayam: ayam goreng, ayam bakar, ayam geprek, ayam penyet, ayam kremes, ayam rica-rica, ayam tepung - Daging: rendang, sate (ayam/kambing/sapi), semur, empal, iga bakar - Ikan/seafood: gurame, nila, pindang, cumi, udang - Bakso, soto (soto ayam/betawi/madura/kudus/lamongan), gado-gado, ketoprak, pecel

Camilan / side - Kentang goreng, singkong goreng, tahu goreng, tempe mendoan, kerupuk, dimsum, gorengan - Roti, pastry, cake, donut, martabak

Minuman - Kopi: espresso, americano, latte, cappuccino, es kopi susu gula aren, kopi tubruk, V60, kopi joss - Teh: teh tarik, teh manis, teh tawar, teh melati, thai tea, matcha latte - Boba/milk tea: berbagai flavour × topping × sugar × ice level - Jus: alpukat, mangga, jeruk, wortel, sirsak - Smoothie, milkshake, es campur, es teler, cendol, dawet - Es kelapa, air kelapa, sparkling, mocktail

Modifier universal Indonesia yang wajib di-taxonomize - Tingkat pedas: level 0/1/2/3/4/5, tidak pedas, sedang, extra pedas, mati, gilaaa - Sugar level (boba/kopi kekinian): 0%, 25%, 50%, 75%, 100%, less sugar, normal, extra sweet - Ice level: no ice, less ice, normal, extra ice - Size: small/regular/large, cup ukuran mL - Milk options: full cream, low fat, oat milk, almond milk, soy milk - Nasi: putih, merah, uduk, ½ porsi, tambah nasi - Tambahan: pakai kerupuk, pakai telur (mata sapi/ceplok/dadar), tanpa sayur, tanpa MSG - Bumbu request: extra sambal, sambal terpisah, level pedas + jenis sambal (ijo, matah, korek, bawang) - Delivery / dine-in / take-away preferences

B.4 Skema MenuItem canonical (Lapis B ontology) untuk chain

canonical_dish {
  canonical_id: dish://nasi-goreng
  canonical_name_id: "Nasi Goreng"
  canonical_name_en: "Fried Rice"
  dish_family: "nasi"
  cuisine_region: ["indonesia", "javanese"]
  parent_dish: null
  child_variants: [
    dish://nasi-goreng-aceh,
    dish://nasi-goreng-kambing,
    dish://nasi-goreng-jawa,
    dish://nasi-goreng-seafood,
    dish://nasi-goreng-gila
  ]
  key_ingredients: ["nasi", "kecap manis", "bawang putih", "cabai"]
  typical_modifiers: [
    modgroup://spice-level,
    modgroup://protein-choice,
    modgroup://egg-topping,
    modgroup://kerupuk
  ]
  common_aliases_id: ["nasgor", "NG", "nasi goreng biasa"]
  common_misspellings: ["nasgor", "nasi gorang", "nasi gorank"]
  phonetic_variants: ["nasgor", "nasi gorang", "nasi kokreng"]  # dari ASR errors
  homophone_conflicts: []
  chain_appearances: [
    { chain: "Solaria", menu_url: "...", section: "Nasi & Mie" },
    { chain: "HokBen", menu_url: "...", section: "Rice" }
  ]
  source_confidence: 0.95
  last_verified_at: "2026-09-22"
}

Chain appearances jadi salah satu proof-of-existence terkuat: kalau 5 chain besar punya varian yang sama, itu pasti canonical.

B.5 Step-by-step 8 minggu (paralel dengan CPG stream)

Minggu 1: seed taxonomy from public knowledge - Import list variasi hidangan Indonesia dari Wikipedia list of nasi goreng variations dan halaman terkait (mie, sate, soto). - Import Panganku untuk 200+ bahan pangan authoritative. - Import Kaggle Indonesian food recipes — ekstrak dish names + ingredients + region.

Minggu 2: Tier 1 fetch — top 5 chain - Starbucks, McDonald's, KFC, Chatime, Kopi Kenangan. - Untuk tiap chain: fetch menu, parse ke skema MenuItem, tandai chain_id + menu_url + fetched_at. - Ekstrak modifier pattern (sugar/ice level dari Chatime, size dari Starbucks, paket dari KFC).

Minggu 3: Tier 1 fetch — 5 chain berikutnya - Pizza Hut, Domino's, Fore, Janji Jiwa, HokBen. - Fokus: modifier variants (crust, topping, size untuk pizza; jenis susu untuk kopi kekinian; sauce untuk bento).

Minggu 4: canonical dish extraction - Cluster menu items lintas chain — dishes yang muncul di ≥ 2 chain jadi canonical candidate. - Assign canonical_id, dish_family, common_aliases. - Target: 80–120 canonical dishes dengan chain appearances ≥ 2.

Minggu 5: Tier 2 chain (OCR) - Padang chain, ayam geprek chain, bakso chain. - Pipeline: PDF/gambar → OCR (Tesseract atau Qwen-VL) → manual review → structured menu.

Minggu 6: modifier taxonomy consolidation - Bangun modifier_groups master: spice-level, sugar-level, ice-level, size, milk-choice, egg-topping, kerupuk, protein-choice, nasi-choice. - Untuk tiap modifier group, dokumentasikan aliases yang muncul di berbagai chain (“no ice” = “tanpa es” = “no es” = “ga pake es”).

Minggu 7: alias & phonetic enrichment - Untuk 100 canonical dish teratas, tambahkan common_aliases (slang, singkatan) dan phonetic_variants (untuk toleransi ASR). - Sumber alias: post blog “sebutan lain untuk X”, forum kaskus/reddit, sosmed, dan idealnya real audio transcripts kalau sudah ada.

Minggu 8: cross-link CPG ↔ menu - Untuk minuman di menu warkop yang menggunakan brand CPG (Teh Botol Sosro, Aqua, Kopiko, Susu Bear Brand), link MenuItemproduct_id di CPG database. - Ini adalah “aha moment” arsitektur Anda: menu API yang mengenali “Es Kopi Susu Bear Brand” bisa auto-resolve ke Ultra UHT + bear brand + gula aren + espresso shot, kombinasi CPG + resep.

Target akhir minggu 8: ~1.500–2.500 chain menu items di-parse, 150–250 canonical dishes dengan aliases, ~40 modifier groups dengan alias lengkap.


Bagian C: Integrasi Dua Stream

Setelah 12 minggu (CPG) dan 8 minggu (Menu paralel), Anda punya:

StreamVolumeUtility utama
CPG golden records~700–900 SKU di 6 kategori BPOMRetail identity layer, cross-channel commerce
Chain menu items~1.500–2.500 items dari 15 chainSeed untuk voice ordering + benchmark modifier
Canonical dishes~150–250 dishesLapis B ontology untuk Food API
Modifier groups~40 groups dengan aliasesPrecision layer voice ordering

Titik integrasi: - Brand CPG muncul di menu: MenuItem “Es Teh Botol” → link ke CPG product Teh Botol Sosro 350ml. - Compliance carry-over: MenuItem yang berbahan CPG mewarisi halal_cert dan bpom_reg_no dari CPG record. - Voice pipeline: transkrip “es kopi susu gula aren less sugar” → canonical dish es-kopi-susu + modifier gula-aren + modifier sugar-level:less + (jika chain-context Kopi Kenangan) → resolve ke SKU actual di chain.


Bagian D: Deliverables per fase

Bulan 1 (Minggu 1–4): - Taxonomy tabel populated (BPOM 16 kategori, GS1 GPC mapping, Google mapping). - 10 principal + 100 brand records. - 200 CPG SKU (snack + mie). - 5 chain menu parsed, 30 canonical dishes.

Bulan 2 (Minggu 5–8): - 500 CPG SKU (+ minuman + bakeri). - 10 chain menu parsed, 100 canonical dishes. - Modifier taxonomy v1 (40 groups).

Bulan 3 (Minggu 9–12): - 900 CPG SKU (+ cokelat + susu). - Validasi BPOM + halal registry untuk 300 SKU teratas. - 200 canonical dishes dengan aliases + phonetic variants. - Cross-link CPG ↔ menu (~50 links).

Semua data tersimpan di Neon Postgres dengan skema yang mengizinkan versioning (temporal tables atau updated_at + audit table) sehingga governance layer bisa menjadi selling point tersendiri.


Referensi

Dokumen 2

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:

  1. Untuk Food API (Menu Voice Intelligence): mulai dari mana, dan menu seperti apa yang harus dikumpulkan.

  2. 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.

  1. 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).

  2. Dataset Indonesia yang sudah ada untuk knowledge ontology (Lapis B), bukan untuk transaksi:

  3. Panganku (Data Komposisi Pangan Indonesia) — 200+ bahan/pangan dengan komposisi nutrisi resmi. Cek data-sharing agreement sebelum redistribusi (panganku.org licensing).

  4. Indonesian Food Recipes API by ricotandrio — 13.503 resep asal Kaggle. Berguna untuk ekstraksi bahan, teknik memasak, dan alias hidangan.

  5. Indonesian Food and Drink Nutrition Dataset (Kaggle) — 1.346 item dengan gambar dan nutrisi.

  6. Indonesian Food Image Classification (Kaggle) — 6.500 gambar untuk visual grounding.

  7. Wikipedia list of nasi goreng variations — contoh sempurna untuk ekstraksi alias/varian (Aceh, Jawa, Padang, gila, kambing, dst).

  8. 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.

  9. Sumber ontology umum sebagai skeleton skema:

  10. Schema.org Menu untuk Menu, MenuSection, MenuItem, MenuAddOn.

  11. Toast menu hierarchy untuk hierarki Menu → Group → Item → Modifier Group → Modifier Option yang battle-tested.

  12. 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, misal dish://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[] dengan min_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

  1. 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.

  2. Minggu 3–4 — 3–5 merchant sejenis. Bandingkan penamaan. Ekstrak alias dan modifier pattern. Ini yang membuat Lapis B mulai terbentuk.

  3. 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).

  4. 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.

  5. 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_at dan 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:

Indonesia:

Skema atribut untuk dijadikan referensi (jangan reinvent):

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_text dari 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) dengan source_id, fetched_at, raw_payload

  • merge_history[] (kandidat merge, siapa/kapan yang confirm)

  • confidence_scores per 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

  1. Minggu 1 — pilih 1 vertikal + 1 kategori sempit. Contoh: “oli motor 4-tak Indonesia” atau “instant noodle Indonesia 5g–120g pack”. Kategori sempit dulu.

  2. 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.

  3. Minggu 3 — model atribut. Untuk kategori tersebut, definisikan 15–25 atribut wajib. Validasi dengan orang yang belanja/menjual kategori itu.

  4. 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.

  5. 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.

  6. 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_payload sumber — 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:

AspekFood DatabaseRetail Product Database
Unit dasarMenu item + modifier treeProduct record + attributes
Identifier stabilcanonical_dish_id + merchant SKUGTIN / MPN + brand
Alias/varianaliases[], phonetic_variants[]title_variants[], synonyms[]
Governanceverified_by_merchant, price versionsource_records[], merge_history[]
Feedback loopKoreksi kasir/pelanggan pada orderKonfirmasi operator saat entity resolution
Cold-start3–5 merchant seed + ontology publik1 vertikal + 1 supplier + open GTIN feeds
MoatAlias Indonesia + modifier semanticsGolden 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:

  1. Pilih 1 merchant design partner (idealnya coffee shop atau warung Padang di Surabaya) — ambil menu asli lengkap.

  2. Definisikan skema MenuItem + Modifier v1 di Neon Postgres. Import Schema.org Menu + Toast hierarchy sebagai pola.

  3. Import Panganku dan Kaggle nutrition dataset sebagai Lapis B ontology awal.

  4. Ekstrak 30–50 dish canonical dengan aliases dari Wikipedia + resep Indonesia.

Untuk Retail Database:

  1. Pilih 1 vertikal + 1 kategori sempit (rekomendasi: CPG makanan/minuman Indonesia karena punya barcode + relevan dengan Food API-Anda).

  2. Definisikan attribute dictionary v1 untuk kategori itu (15–25 atribut) mengacu pada Google Merchant spec + GS1 GDM.

  3. Seed 200–500 SKU dari API produk Indonesia + Open Food Facts Indonesia + verifikasi GTIN via Verified by GS1.

  4. 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.