Feed produktowy do Copilota: co Microsoft naprawdę czyta

Zakupy w Copilocie to dwie osobne roboty, nie jedna. Pierwsza decyduje o tym, czy Twój produkt da się w ogóle znaleźć, i opiera się na feedzie w Microsoft Merchant Center. Druga decyduje o tym, czy da się go kupić bez wychodzenia z asystenta, i opiera się na warstwie transakcyjnej z operatorem płatności. Microsoft opisuje to dokładnie w tym podziale: feedy odpowiadają za odnajdywanie, protokół transakcyjny za zakup.

Ten tekst mówi, co z tego jest dostępne dla europejskiego sprzedawcy dzisiaj, jakie pola są naprawdę wymagane, gdzie siedzą pułapki, których nie widać w panelu, i jak zbudować ten feed, żeby nie wymagał opieki co tydzień. Wszystko sprawdzone w dokumentacji Microsoftu 30 października 2026.

Kto może dziś sprzedawać w Copilocie, a kto tylko być widoczny

Tu jest zdanie, które oszczędza tydzień pracy. Copilot Checkout, czyli dokończenie zakupu wewnątrz Copilota, jest pilotażem dla wybranych klientów i obowiązuje w nim ograniczenie, które Microsoft podaje wprost: kwalifikują się wyłącznie sprzedawcy anglojęzyczni obsługujący kupujących w Stanach Zjednoczonych, w dolarach. Sprzedawca pozostaje przy tym stroną transakcji.

Druga połowa, czyli odnajdywanie produktów, ma znacznie szerszy zasięg. Kampanie Microsoft Shopping są dostępne w długiej liście krajów, w której jest Polska, a w dokumentacji Content API polski jest na liście języków treści i PL na liście krajów docelowych.

Jest jednak szczegół, który trzeba sprawdzić, zanim ktoś zacznie liczyć przychód. Lista walut w obiekcie ceny w dokumentacji Content API nie zawiera PLN, mimo że zawiera euro, funta, koronę szwedzką i dolara. Nie wyciągamy z tego wniosku o produkcie, bo dokumentacja i panel bywają niezgodne, ale przed wdrożeniem walutę swojego rynku trzeba potwierdzić na własnym koncie.

Pola wymagane: lista, która zaskakuje dwa razy

Dokumentacja Content API ma kolumnę „wymagane przy wstawieniu” i warto ją przeczytać dosłownie, bo kilka pozycji nie jest oczywistych.

Pierwsze zaskoczenie to wymóg zgodności ceny ze stroną produktu. Brzmi oczywiście, dopóki ktoś nie wprowadzi w sklepie promocji liczonych w czasie rzeczywistym, a feed wysyła raz na dobę w nocy. Wtedy każda zmiana ceny w ciągu dnia tworzy kilkanaście godzin, w których kanał pokazuje inną kwotę niż strona, a to jest złamanie wymogu, nie drobne opóźnienie. Rozwiązaniem nie jest częstsza wysyłka całego katalogu, tylko osobny, szybki kanał dla ceny i dostępności.

Drugie zaskoczenie to pola przesyłki. Są w kolumnie „wymagane”, ale przypis zawęża ten wymóg do rynku niemieckiego. Jeśli ktoś czyta tylko kolumnę, zbuduje model danych dla całej Europy pod wymóg jednego kraju i będzie zbierał wagi produktów, których nikt nie potrzebuje.

Resztę pól warto czytać razem z tym, co z karty produktu czyta asystent.

Identyfikator, którego nie zmienisz po fakcie

Identyfikator produktu w Merchant Center jest złożeniem czterech rzeczy: kanału, języka treści, kraju docelowego i Twojego offerId. W dokumentacji wygląda to jak Online:en:US:Sku123. Wszystkie cztery składniki są niezmienne po dodaniu produktu, bo z nich powstaje identyfikator.

To przesądza o jednej decyzji, którą zwykle podejmuje się w pięć minut, a żyje się z nią latami: z czego wyprowadzasz offerId. Jeśli z SKU, które zmienia się przy zmianie dostawcy albo opakowania, to każda taka zmiana jest nowym produktem w katalogu, z zerową historią. Jeśli z identyfikatora wewnętrznego, którego nikt nigdy nie przepisuje, masz spokój.

Tu nie ma dobrego sposobu na poprawkę po fakcie. Zmiana konwencji offerId to migracja katalogu.

Pułapka trzydziestu dni, czyli jak katalog cichnie sam

To jest fragment dokumentacji, który w praktyce kosztuje najwięcej, a czyta się najszybciej. Produkt, dla którego nie podasz daty wygaśnięcia, wygasa po 30 dniach od momentu dodania albo ostatniej aktualizacji. Wystarczy zatem przerwa w wysyłce, żeby katalog zaczął znikać partiami, w kolejności, w jakiej był dodawany.

Drugi element tej samej układanki: usunięcie produktu przestaje działać z opóźnieniem do 12 godzin, a dokumentacja zaleca, żeby najpierw ustawić dostępność na „out of stock”, a dopiero potem usuwać. Odwrotna kolejność znaczy, że przez pół dnia Copilot i wyszukiwarka mogą pokazywać produkt, którego nie da się kupić.

Nowość w feedzie: deklaracja treści z AI

W dokumentacji jest atrybut, którego rok temu nie było: deklaracja, czy oferta zawiera treści wygenerowane albo zmodyfikowane przez AI. W pliku tekstowym nazywa się advertiser_ai_label, w Content API advertiserAILabel, a przyjmuje trzy wartości: z prośbą o widoczny znak wodny, bez takiej prośby albo z deklaracją, że treści AI nie ma.

Microsoft opisuje to jako deklarację reklamodawcy, a nie wynik detekcji. Przetwarzanie wymaga włączonego pilotażu na sklepie, a wartość nierozpoznana kończy się ostrzeżeniem walidacji i wyczyszczeniem pola.

Dla sklepu, który generuje opisy modelem, to jest nowa pozycja w procesie, a nie detal techniczny. Decyzja, co deklarujemy, powinna zapaść raz i zostać zapisana w regule generowania opisów, a nie być wpisywana ręcznie przy każdym eksporcie. Jeśli opisy powstają u Ciebie z AI, zobacz, jak to układamy w tekście o tłumaczeniu katalogu z AI.

Gdzie te wdrożenia pękają

Z naszej praktyki przy feedach kanałowych wracają cztery rzeczy, niezależnie od platformy sklepu.

• Jednorazowy import zamiast pulsu. Ktoś wysyła katalog raz, sprawdza, że produkty są widoczne, i wraca do tematu po kwartale, gdy pozycje już wygasły.
• Cena z innego momentu niż strona. Promocje liczone w sklepie w czasie rzeczywistym, feed wysyłany w nocy. Wymóg zgodności ceny jest wtedy łamany codziennie o 9 rano.
• Testy na produkcji. Dokumentacja daje parametr dry-run właśnie po to, żeby sprawdzić żądanie bez dotykania danych. Mało kto z niego korzysta, dopóki nie wyczyści katalogu.
• Brak limitów w kodzie. Żądanie zbiorcze przyjmuje do 12 000 pozycji i do 4 MB, więc przy większym katalogu paczkowanie jest częścią integracji, a nie opcją.

Jak to zbudować, żeby nie wymagało opieki

Architektura jest ta sama, którą opisaliśmy przy integracji feedu Kauflandu, i to nie przypadek: kanały różnią się nazwami pól, a nie mechaniką.

• Jedno źródło prawdy o produkcie. Katalog, z którego lecą wszystkie kanały, z polami wymaganymi pilnowanymi na wejściu.
• Schemat kanału w kodzie. Mapowanie pól Microsoftu, limity znaków i reguła offerId opisane raz, z testem.
• Dwa rytmy wysyłki. Pełna synchronizacja codziennie, cena i dostępność częściej. Odświeżenie chroni przed wygaśnięciem po 30 dniach.
• Walidacja i dry-run przed produkcją. Braki identyfikatorów, za długie tytuły i niezgodne ceny wychodzą u Ciebie, a nie w przeglądzie edytorskim.

Taki zakres robimy u klientów jako automatyzację feedów, a przy wejściu na nowe kanały jako ekspansję na marketplace. Jeśli chcesz sprawdzić, czy Twój katalog przejdzie wymagania Microsoftu bez przepisywania opisów ręcznie, napisz do nas i obejrzyjmy razem Twoje dane produktowe.

I zastrzeżenie, które przy tym temacie jest ważniejsze niż zwykle. Zakupy w asystentach zmieniają się z miesiąca na miesiąc, pilotaże otwierają się i zamykają, a tego, kiedy Copilot Checkout obejmie Europę, nie wie nikt poza Microsoftem. Dlatego w tekście nie ma ani jednej daty, której nie podaje dokumentacja, ani żadnej obietnicy ruchu. Przed wdrożeniem sprawdź aktualną wersję u źródła.