Integrasi & ERP
Mengapa Live Search Adobe Commerce Memaparkan Produk Yang Anda Tiada Lagi
Live Search membaca salinan katalog yang dieksport, bukan pangkalan data anda. Mengapa ia terpesong, dan tetapan yang diam-diam menghentikan kemas kini.

Danny Khow, Pengasas Bersama & Pengarah Urusan6 minit bacaan
Seorang pelanggan mencari di kedai anda, menemui produk, mengklik masuk, dan produk itu kehabisan stok. Atau harga pada halaman hasil carian ialah harga minggu lepas. Katalog dalam admin betul, produk itu betul, dan hasil carian masih salah.
Kami menyebut hal ini secara sepintas lalu ketika menulis tentang apa yang Live Search dan cadangan AI benar-benar hasilkan: merentas pelaksanaan tersebut, memastikan data produk Live Search kekal tersegerak dengan tepat memerlukan kerja integrasi yang sebenar, terutamanya pada katalog yang stok dan harganya sentiasa bergerak. Ia masalah saluran data dan bukan masalah AI, dan ia berhak mendapat penjelasannya sendiri.
Live Search tidak membaca pangkalan data anda
Inilah bahagian yang paling kerap terlepas pandang, dan segala yang lain berpunca daripadanya.
Live Search ialah perkhidmatan SaaS. Storefront anda tidak menyoal katalog MySQL anda sendiri apabila pelanggan menaip dalam kotak carian. Ia menyoal perkhidmatan Adobe, dan perkhidmatan itu menjawab daripada satu salinan katalog anda yang telah dieksport ke sana lebih awal. Sambungan SaaS Data Export — dibuka dalam tab baharu itulah yang menyelenggara salinan tersebut.
Jadi "produk itu betul dalam admin" dan "produk itu betul dalam hasil carian" ialah dua dakwaan berasingan. Yang pertama mengatakan pangkalan data anda betul. Yang kedua mengatakan saluran eksport telah menyampaikan pembetulan itu, dan kedua-duanya boleh berjarak beberapa hari tanpa apa-apa kelihatan rosak.
Bagaimana satu perubahan produk benar-benar sampai ke indeks carian
Adobe mendokumenkan aliran ini — dibuka dalam tab baharu sebagai satu rantaian, dan ia berbaloi diketahui kerana kerosakan pada mana-mana sambungan menghasilkan gejala yang sama:
- Pengesanan perubahan. Mview mengesan baris yang diubah dalam jadual seperti
catalog_product_entitydan menulis entri ke changelog. - Pengindeksan suapan. Pengindeks suapan membaca changelog dan menyusun item suapan.
- Pengumpulan. Pembekal mengumpul data medan mengikut skema setiap suapan.
- Penyahduaan hash. Hash kandungan menentukan apa yang benar-benar berubah. Data yang tidak berubah dilangkau, bukan dihantar semula.
- Penghantaran. Kelompok dihantar melalui POST ke Feed Ingestion Service Adobe.
- Penulisan semula status. Respons mengemas kini jadual suapan, setiap item.
- Cuba semula. Kegagalan dihantar semula mengikut jadual.
Tiada satu pun daripadanya serta-merta, dan kesemuanya bergantung pada cron:
| Tugas | Kumpulan | Kekerapan |
|---|---|---|
indexer_update_all_views | index | setiap 1 minit |
saas_data_exporter | commerce_data_export | setiap 5 minit |
*_resend_failed_items | resync_failed_feeds_data_exporter | setiap 5 minit |
cleanup_deleted_feed_items | commerce_data_export | setiap hari 2:00 |
Panduan Adobe sendiri menyatakan kemas kini produk sepatutnya diindeks dalam beberapa minit, kemas kini tokokan boleh mengambil masa 15 hingga 20 minit, dan indeks pertama selepas pemasangan boleh mengambil masa melebihi 30 minit. Jika cron tidak sihat, atau changelog tersekat di belakang satu operasi katalog yang besar, tiada satu pun angka itu kekal benar.

Tetapan yang diam-diam menghentikan kemas kini
Inilah bahagian paling tajam dalam keseluruhan perkara ini. Perubahan berterusan sampai ke perkhidmatan melalui penyegerakan separa, dan penyegerakan separa hanya berjalan apabila cron dihidupkan dan pengindeks berada dalam mod Update by Schedule.
Tukar semula satu pengindeks kepada Update on Save dan tiada lagi changelog untuk dibaca oleh pengindeks suapan. Tiada ralat. Admin kelihatan sihat. Katalog anda cuma berhenti sampai ke Live Search, dan anda mengetahuinya daripada seorang pelanggan.
Ini berkait terus dengan naik taraf 2.4.8: Adobe menukar mod pengindeks lalai daripada Update on Save kepada Update by Schedule pada pemasangan baharu dan naik taraf. Tetapan lalai itu kini memihak kepada anda. Apa yang ia tidak lakukan ialah melindungi kedai yang seseorang telah menukar pengindeksnya kembali kepada Update on Save sewaktu menyahpepijat perkara lain, dan tidak pernah menukarnya semula.
"Dihantar" bukan bermakna "sudah hidup"
Admin mempunyai jawapan sebenar untuk ini, di System > Data Transfer > Data Feed Sync Status. Ia melaporkan empat keadaan bagi setiap suapan:
| Status | Maksudnya |
|---|---|
Submitted to service | Berjaya dihantar, tiada tindakan diperlukan |
Failed, will retry | Penghantaran gagal, sistem akan cuba lagi |
Failed, requires attention | Ralat aplikasi atau data, seseorang perlu lihat |
Awaiting submission | Perubahan dikesan, belum diproses |
Ia turut menunjukkan rekod sumber berbanding rekod yang dihantar, tunggakan changelog, dan mod setiap pengindeks, iaitu cara terpantas menangkap masalah dalam bahagian sebelum ini.
Satu peringatan daripada dokumentasi Adobe sendiri berbaloi dinyatakan terus terang, kerana ia membezakan antara semakan lima minit dan pencarian dua hari: eksport yang berjaya tidak menjamin data itu tersedia di hilir dalam perkhidmatan yang disambungkan. Submitted to service bermakna kedai anda telah menyerahkan data itu. Ia tidak bermakna indeks carian sudah selesai menyerapnya.
Mencari satu SKU yang salah
Apabila satu produk sahaja yang bermasalah dan bukan keseluruhan katalog, persoalannya ialah sambungan mana dalam rantaian itu yang menjatuhkannya. Artikel penyelesaian masalah — dibuka dalam tab baharu Adobe terus menuju ke jadual suapan, dan membawa pertanyaan yang boleh disalin.
Cari SKU itu dalam cde_products_feed, dipadankan pada nilai sku dan storeViewCode di dalam JSON feed_data-nya. Jika tiada baris kembali, perubahan itu tidak pernah menjadi item suapan langsung, dan kerosakannya berada di hulu pada pengesanan perubahan atau pengindeksan suapan. Jika barisnya ada tetapi lapuk, bandingkan modified_at-nya dengan masa pengubahsuaian produk itu sendiri, kemudian semak cap masa eksport terakhir dalam scopes_website_data_exporter. Perbandingan tunggal itu memisahkan "kami tidak pernah mengumpulnya" daripada "kami mengumpulnya dan tidak pernah menghantarnya", iaitu dua kerosakan berbeza dengan pembetulan berbeza. Atribut produk mempunyai suapannya sendiri, cde_product_attributes_feed, berbaloi disemak berasingan apabila produk itu ada tetapi satu medan salah.

Untuk menggerakkan saluran itu secara manual:
bin/magento cron:run --group=saas_data_exportermencetuskan penyegerakan serta-mertabin/magento indexer:reindex cde_products_feedmembina semula suapan produkbin/magento saas:resync --feed productsmenghantar semula item baharu, dikemas kini, dan yang pernah gagal
Tangani --cleanup-feed dengan berhati-hati. Ia muncul dalam arahan Adobe untuk pulih daripada Data Space ID yang berubah, dan Adobe menyatakan dengan jelas ia untuk pembinaan semula persekitaran sepenuhnya dan bukan penyelesaian masalah rutin. Ia bukan bendera yang ditambah kerana satu penyegerakan semula tidak menjadi pada kali pertama.
Mengapa perubahan stok dan harga yang kerap ialah kes yang sukar
Katalog yang berubah dua kali sehari nyaris tidak terjejas oleh mana-mana perkara di atas. Kelewatan lima belas minit pada satu suntingan produk tidak kelihatan.
Kesukaran datang apabila stok dan harga bergerak berterusan, iaitu keadaan biasa bagi peruncit yang menjalankan promosi, saluran pasaran, atau ERP yang menolak kemas kini sepanjang hari. Kini changelog tidak pernah sunyi, eksport sentiasa bekerja, dan tetingkap ketika salinan yang dieksport bercanggah dengan katalog menjadi terbuka secara kekal dan bukan sekali-sekala.
Itu juga sebabnya perkara ini kerap ternyata bukan masalah carian langsung. Jika paras stok sampai ke katalog lewat daripada ERP atau POS di hulu, Live Search sedang mengeksport dengan setia nombor yang sudah pun salah ketika ia menerimanya. Saluran itu melakukan tugasnya pada input yang salah. Mendiagnosis indeks carian dahulu, sedangkan kerosakannya pada sistem dua lompatan di hulu, ialah cara paling lazim kehilangan seminggu atas hal ini.
Bagi peruncit yang stoknya benar-benar berada di beberapa tempat serentak, merentas kedai web, pasaran, dan kedai fizikal, pembetulan asasnya ialah satu sumber kebenaran tunggal untuk produk, harga, dan inventori, bukan penalaan lebih ketat pada satu eksport. Itulah masalah yang WOW Sync wujud untuk selesaikan, dan ia berada di hulu segala yang diterangkan di sini.
Jika hasil Live Search dan katalog anda bercanggah dan anda lebih suka tidak menghabiskan seminggu mencari puncanya, berbincanglah dengan kami.
Sumber: Adobe Experience League, Panduan SaaS Data Export — dibuka dalam tab baharu, Segerakkan Data dengan SaaS Data Export — dibuka dalam tab baharu, Data Feed Sync Status — dibuka dalam tab baharu, dan Katalog Live Search tidak tersegerak — dibuka dalam tab baharu, serta pengalaman integrasi kami sendiri pada katalog Adobe Commerce.
Teruskan membaca
Artikel berkaitan
Lebih lanjut tentang platform, integrasi, dan cara pembeli menemui jenama.

Integrasi & ERP
Integrasi ERP dan Adobe Commerce: Memastikan Pemenuhan dan Inventori Betul
Memilih corak integrasi, mereka bentuk aliran data bagi pesanan dan stok, serta mengendalikan hasilnya — panduan praktikal untuk pasukan Adobe Commerce.
Baca artikel
Integrasi & ERP
Integrasi Magento kepada SAP: Apa Yang Sebenarnya Rosak
Hanyutan stok, harga tak sepadan, jurang penyegerakan pesanan, dan keputusan data induk yang menentukan sama ada integrasi Magento-SAP bertahan.
Baca artikel
Tip E-Dagang
Penemuan AI Bermula di Laman Web Anda Sendiri, Bukan di ChatGPT
74% pembeli Malaysia sudah guna AI ketika membeli-belah. Apa yang Live Search dan cadangan AI Adobe Commerce hasilkan merentas 4 pelaksanaan sebenar.
Baca artikel
