Product Feed untuk AI Commerce: Data Stok dan Harga Tidak Boleh Jadi Formalitas

Ada satu kalimat yang kedengarannya remeh tetapi bisa bikin seluruh pengalaman AI commerce rusak: “Stoknya nanti update kok.”

“Nanti” itu kapan?

Lima menit lagi, enam jam lagi, besok pagi, atau setelah batch malam jalan?

Di e-commerce biasa, selisih data beberapa jam kadang sudah bikin customer kesal. Di AI commerce, problem-nya bisa terasa lebih serius karena pengguna tidak selalu melihat katalog baris demi baris. Mereka bisa bertanya dalam bahasa natural, meminta AI membandingkan beberapa opsi, menyaring berdasarkan budget, lalu mengambil keputusan dari informasi yang ditampilkan sebagai bagian dari percakapan.

Kalau harga dan stok di feed sudah basi, AI bisa terlihat sangat meyakinkan saat menjelaskan sesuatu yang sebenarnya tidak lagi bisa dibeli.

Itulah kenapa product feed tidak boleh diperlakukan sebagai pekerjaan administratif. Ia adalah lapisan data operasional.

Feed bukan brosur digital

Banyak perusahaan masih memperlakukan catalog feed seperti brosur elektronik: title ada, foto ada, description ada, price ada, selesai.

Padahal katalog untuk AI commerce punya fungsi yang lebih dekat ke interface antara sistem merchant dan sistem discovery. OpenAI, misalnya, mendokumentasikan product feed sebagai sumber data terstruktur yang membantu ChatGPT mengindeks produk, memahami atribut inti, serta menampilkan informasi seperti harga dan availability secara lebih mutakhir.

Per 8 Agustus 2026, dokumentasi Agentic Commerce OpenAI merekomendasikan pola yang cukup jelas: merchant dapat mengirim full feed secara berkala, umumnya sekali sehari, lalu mengirim update sepanjang hari melalui API untuk perubahan yang perlu lebih cepat. Untuk katalog kecil, update penuh maupun reguler dapat dilakukan melalui API. Detail implementasi tentu bergantung pada jalur integrasi dan akses partner.

Poin pentingnya bukan angka “sekali sehari”. Poin pentingnya adalah arsitektur snapshot plus perubahan intraday.

Data punya dua ritme.

Ada data yang relatif lambat berubah seperti brand, model, material, atau dimension.

Ada data yang bisa berubah cepat seperti price, sale price, availability, inventory, dan promotion.

Mencampur keduanya dalam satu ritme update adalah cara gampang membuat sistem tidak efisien atau tidak akurat.

Stok adalah state, bukan copywriting

Bayangkan percakapan sederhana.

“Cari laptop 14 inci di bawah Rp15 juta, RAM minimal 16 GB, yang ready sekarang.”

Kalimat terakhir mengubah semuanya. User bukan cuma mencari spesifikasi. Ia menanyakan state saat ini.

Kalau feed menyatakan produk available karena sinkronisasi terakhir terjadi tadi malam, sementara unit habis pukul 10 pagi, rekomendasi itu kehilangan utilitas. Lebih buruk lagi kalau user sudah memilih produk setelah percakapan panjang lalu landing page menyatakan out of stock.

Di titik itu, problem tidak terasa seperti “data mismatch”. Bagi pengguna, brand atau platform memberi informasi yang salah.

Karena itu availability perlu punya definisi internal yang ketat.

Apakah “in stock” berarti stok fisik tersedia di warehouse?

Apakah berarti bisa dikirim ke semua wilayah?

Apakah preorder dianggap available?

Bagaimana dengan produk yang ready di Jakarta tetapi kosong di Surabaya?

Bagaimana dengan variant ukuran M yang habis tetapi parent product masih punya ukuran L?

Jika organisasi sendiri tidak sepakat soal arti availability, feed tidak akan menyelesaikan problem tersebut. Feed hanya mengirim ketidakjelasan dengan format yang lebih rapi.

Harga juga bukan satu angka sederhana

“Masukkan price ke field price” terdengar gampang sampai tim finance, commerce, dan promotion duduk satu meja.

Ada list price.

Ada sale price.

Ada member price.

Ada voucher yang baru muncul setelah checkout.

Ada harga berbeda per region.

Ada dynamic pricing.

Ada bundling.

Ada minimum purchase.

Ada tax yang mungkin sudah termasuk atau belum.

Ada ongkir yang mengubah total economics bagi pembeli.

AI commerce membutuhkan kejelasan tentang angka mana yang memang boleh direpresentasikan sebagai harga produk pada konteks tertentu. Feed bukan tempat untuk memasukkan angka paling menarik lalu berharap detailnya dijelaskan belakangan.

Kalau user melihat Rp999 ribu tetapi ternyata angka itu hanya berlaku dengan syarat yang tidak terbaca, secara teknis merchant mungkin punya disclaimer. Secara trust, kerusakannya tetap terjadi.

Source of truth harus ditentukan sebelum integrasi

Salah satu audit paling berguna sebelum membangun feed adalah menggambar aliran data tanpa istilah marketing.

Produk dibuat di mana?

SKU ditetapkan di mana?

Harga master berada di ERP atau commerce platform?

Promo dikelola siapa?

Stok authoritative berasal dari WMS, OMS, marketplace aggregator, atau database lain?

Variant mapping tinggal di PIM atau dibuat ulang di storefront?

Feed generator membaca dari sistem yang mana?

Kalau pertanyaan itu tidak punya jawaban tegas, product feed akan menjadi layer rekonsiliasi manual. Tim akhirnya mengedit file karena lebih cepat, lalu file tersebut pelan-pelan berubah menjadi source of truth bayangan yang tidak tercatat dalam architecture diagram.

Ini pola yang berbahaya.

Feed idealnya merepresentasikan sistem authoritative, bukan menggantikannya diam-diam.

Freshness harus didefinisikan berdasarkan risiko

Tidak semua merchant membutuhkan kecepatan update yang sama.

Retailer dengan ribuan SKU dan flash sale punya profil risiko berbeda dari produsen mesin industri yang price quote-nya dibuat setelah inquiry. Grocery delivery berbeda dari furniture made-to-order. Tiket event berbeda dari buku cetak.

Jadi pertanyaan “seberapa sering feed harus update?” tidak punya satu jawaban universal.

Definisikan berdasarkan volatility dan consequence.

Produk dengan stok tipis dan transaksi tinggi butuh freshness tinggi.

Produk dengan harga berubah beberapa kali sehari butuh update lebih cepat daripada katalog yang price-nya tetap berbulan-bulan.

Produk yang unavailable hanya menimbulkan minor inconvenience punya risiko berbeda dari produk yang availability-nya terkait janji pengiriman penting.

Tim sebaiknya membuat freshness SLA per tipe field atau kategori produk, bukan satu SLA untuk seluruh katalog.

Contohnya, atribut deskriptif bisa disinkronkan harian. Availability untuk fast-moving SKU mungkin perlu near-real-time atau beberapa kali per jam. Promotion expiry perlu mengikuti waktu berlaku secara presisi. Perubahan critical seperti product recall seharusnya punya jalur emergency, bukan menunggu batch normal.

Jangan lupa variant

Salah satu sumber error klasik adalah memperbarui stok parent product tetapi tidak stok variant.

Kaos masih “available”, tetapi ukuran S dan M habis.

Sepatu masih “in stock”, tetapi size 42 warna hitam kosong.

Smartphone masih tampil, tetapi storage 256 GB yang disebut user sebenarnya tidak tersedia.

AI justru membuat masalah variant lebih terlihat karena user bisa menyebut constraint sangat spesifik dalam percakapan. Sistem harus punya data yang cukup granular agar filter tersebut bermakna.

Product identity, variant identity, harga, dan stok perlu terkait secara konsisten. Jangan biarkan satu SKU menunjuk variant yang berbeda di ERP dan feed. Jangan reuse identifier untuk produk baru. Jangan mengubah struktur variant tanpa migration yang jelas.

Kalau identifier tidak stabil, histori update juga menjadi susah dipercaya.

Delta update membantu, tapi bukan obat untuk pipeline buruk

Dokumentasi OpenAI menyediakan mekanisme update untuk perubahan pada produk yang sudah ada. Secara konsep, delta update sangat berguna karena merchant tidak harus mengirim ulang seluruh katalog setiap kali stok satu variant berubah.

Tetapi delta mechanism hanya mempercepat data yang diberikan kepadanya.

Kalau event stok terlambat keluar dari warehouse system, delta juga terlambat.

Kalau price service salah, API akan menyebarkan harga salah lebih cepat.

Kalau mapping SKU rusak, update cepat justru memperluas inconsistency.

Itu sebabnya freshness bukan sekadar frekuensi pengiriman. Freshness end-to-end harus dihitung dari perubahan bisnis sampai data usable di tujuan.

Misalnya:

stok berubah pukul 10.00,

event masuk integration queue pukul 10.01,

feed service memproses pukul 10.03,

update dikirim pukul 10.04,

sistem tujuan selesai ingest beberapa saat kemudian.

Yang perlu dimonitor adalah keseluruhan latency tersebut, bukan hanya “API kami mengirim cepat”.

Observability wajib kalau feed dianggap serius

Product feed yang tidak dimonitor adalah spreadsheet otomatis dengan branding lebih mahal.

Minimal, tim perlu bisa melihat:

jumlah item aktif,

jumlah variant,

record yang gagal validasi,

record tanpa harga,

record tanpa availability,

perubahan harga ekstrem,

stok negatif atau tidak masuk akal,

URL yang gagal,

image yang hilang,

duplicate identifier,

umur data terakhir,

jumlah delta yang tertunda,

dan perbedaan antara feed dengan storefront.

Dashboard seperti ini tidak harus fancy. Yang penting bisa mendeteksi anomali sebelum customer yang menemukannya.

Buat juga reconciliation job. Ambil sampel produk dari feed, lalu bandingkan dengan halaman live dan source system. Kalau ketiganya berbeda, jangan debat berdasarkan screenshot. Cari sumber divergence.

Promo adalah area paling rawan

Harga normal biasanya punya alur yang relatif stabil. Promo lebih messy.

Campaign marketing bisa dibuat mendadak. Voucher punya audience restriction. Flash sale punya jam tertentu. Marketplace punya subsidy sendiri. Member tier punya harga khusus. Ada promo yang secara legal harus menampilkan reference price tertentu.

Kalau semua kompleksitas itu dipaksa menjadi satu sale price tanpa konteks, AI bisa memberikan kesan bahwa harga berlaku universal.

Merchant perlu menentukan promo mana yang eligible untuk product feed, syarat apa yang harus ikut, kapan mulai dan berakhir, serta bagaimana fallback dilakukan setelah periode selesai.

Dan jangan mengandalkan manusia untuk “ingat mencabut promo besok pagi”. Sistem perlu expiry logic.

Stale data punya biaya yang sulit terlihat

Ketika stok salah, biaya paling kelihatan adalah conversion loss. Tetapi ada biaya lain.

Customer service menerima pertanyaan tambahan.

User mengulang pencarian.

Return atau cancellation bisa meningkat kalau variant keliru.

Analytics jadi noisy karena click datang ke produk yang tidak bisa dibeli.

Tim marketing salah menilai demand.

Platform bisa menerima signal engagement yang buruk.

Brand kehilangan trust.

Di AI commerce, ada satu efek tambahan: pengguna makin terbiasa meminta AI menyaring pilihan. Kalau data brand sering tidak bisa diandalkan, secara praktis brand menjadi kandidat yang lebih sulit digunakan dalam decision workflow, terlepas dari mekanisme ranking spesifik platform yang tidak selalu dipublikasikan.

Ini bukan klaim bahwa ada “freshness score rahasia” yang otomatis menghukum merchant. Itu interpretasi operasional yang lebih sederhana: sistem pengambilan keputusan bekerja lebih baik ketika inputnya benar.

Pisahkan fakta, estimasi, dan ketidakpastian

Tidak semua bisnis bisa memberikan availability real-time. Tidak semua harga bisa final sebelum lokasi, volume, atau konfigurasi diketahui.

Itu tidak masalah selama representasinya jujur.

Untuk B2B, “request quote” bisa lebih tepat daripada memaksakan angka palsu.

Untuk made-to-order, lead time range mungkin lebih berguna daripada label in stock.

Untuk produk yang harga akhirnya bergantung pada konfigurasi, tampilkan starting price hanya jika maknanya jelas dan didukung landing page.

AI commerce tidak menuntut semua bisnis menjadi retail sederhana. Yang dibutuhkan adalah data yang menjelaskan reality dengan cukup presisi.

Governance sederhana yang bisa diterapkan

Setiap field kritis perlu punya lima hal: owner, source, update rule, validation rule, dan fallback.

Price dimiliki siapa? Source-nya apa? Kapan berubah? Range wajar berapa? Kalau source gagal, apa yang dilakukan?

Availability sama.

Promotion sama.

Merchant policy sama.

Dengan begitu, ketika error terjadi, orang tidak perlu mencari-cari siapa yang “biasanya pegang feed”.

Buat juga aturan kill switch. Jika feed price tiba-tiba turun 90 persen untuk 20 ribu SKU akibat bug, pipeline harus bisa berhenti sebelum perubahan tersebar. Automation yang bagus bukan automation tanpa manusia. Automation yang bagus tahu kapan manusia harus masuk.

AI commerce membuat data operasional menjadi bagian dari customer experience

Dulu merchant bisa memisahkan “konten website” dan “sistem backend” dengan cukup nyaman. AI commerce mempersempit jarak itu.

User bertanya dengan bahasa manusia, tetapi jawaban yang berguna tetap bergantung pada data yang sangat struktural: identifier, price, stock, variant, seller, destination, fulfillment, policy.

Di sinilah banyak organisasi akan menemukan bahwa problem AI mereka ternyata problem data lama yang baru terlihat dari interface baru.

Jadi jangan tanyakan hanya apakah feed valid.

Tanyakan apakah feed benar.

Apakah ia cukup fresh untuk jenis bisnis kita?

Apakah perubahan stok bergerak cukup cepat?

Apakah harga yang ditampilkan benar-benar bisa dibeli oleh user dengan syarat yang jelas?

Apakah variant yang direkomendasikan memang tersedia?

Apakah landing page mengonfirmasi informasi yang sama?

Kalau jawabannya iya, product feed mulai berfungsi sebagai infrastruktur AI commerce. Kalau belum, feed hanya membuat data lama terlihat lebih modern.