FeedMender/Czego nie sprawdzamy
Granica
Czego plik nie może nam powiedzieć
Wolimy powiedzieć to krótko z góry, niż zostawić Ci odkrywanie tego po fakcie. Analiza czyta jeden plik, jeden raz. Całe cztery klasy problemów leżą poza tym, co takie odczytanie może ustalić, a udawanie, że jest inaczej, to sposób, w jaki narzędzie do feedów traci zaufanie, którego potrzebuje.
Twoje działające strony
To, czy cena na Twojej stronie docelowej wciąż zgadza się z ceną w feedzie, czy strona przekierowuje,
czy ładuje się na urządzeniach mobilnych, czy otwiera się na właściwym wariancie, wymaga przejrzenia
Twojego sklepu przez robota, a nie odczytania Twojego pliku. To samo dotyczy znaczników
schema.org niezgodnych z feedem. Te kontrole są realne i warte zbudowania, ale żadna
z nich nie jest możliwa na podstawie przesłanego pliku. Losowa próbka 25 stron byłaby pokazem, a nie
pokryciem, więc nie przedstawiamy jej tak, jakby nim była.
Co Google faktycznie zdecydował
Mówimy Ci, co mówią Twoje dane. Merchant Center mówi Ci, co Google z nimi zrobił, a to są różne pytania. Status produktu w podziale na kraje, kody problemów, problemy na poziomie konta, konflikty między źródłami danych i każda reguła, która po cichu nadpisuje poprawkę: wszystko to wymaga dostępu do konta. Nie prosimy o niego i nie twierdzimy, że go mamy. To najcenniejsza pozycja na tej liście, bo domknęłaby pętlę i pokazała nam nasze własne pominięcia, i należy ona do wersji produktu, która ma konta i połączenie OAuth. Dzisiejszy produkt działa wyłącznie na przesłanych plikach, a powiedzenie tego wprost jest lepsze niż zostawianie pytania w zawieszeniu.
Historia
Liczba produktów, która spadła z dnia na dzień, kolumna, która po cichu zniknęła, identyfikator, który zmienił się między przesłaniami, masowe przełączenie na brak w magazynie: to widzi tylko coś, co obserwuje każde przesłanie w czasie. My widzimy jeden plik, jeden raz. Ten rodzaj monitorowania jest naprawdę cenny i naprawdę niemożliwy dla narzędzia, które nie obserwuje dalej, i pojawi się wraz z zaplanowanym pobieraniem albo wcale.
Ocena
To, czy poprawnie zbudowany kod kreskowy rzeczywiście należy do tego konkretnego produktu, czy akcesorium na zdjęciu jest wliczone w cenę, czy polityka zwrotów sklepu jest wiarygodna: to praca do ręcznego przeglądu i taką pozostaje. Część z tego można sprawdzić w zewnętrznej usłudze, w GS1 co do właściciela kodu kreskowego, w publicznej bazie EPREL co do rejestracji energetycznej, i warto to robić, gdy jest ku temu powód. Wymyślanie wartości nigdy nie wchodzi w grę. Weryfikowanie podanej wartości czasami tak, i to jest przyszła funkcja, a nie twierdzenie, które składamy dziś.
Co moglibyśmy dodać, a czego nie dodaliśmy
Przegląd pokrycia zaproponował znacznie więcej i większość z tego jest słuszna, ale leży poza pojedynczym przesłanym plikiem. Zapisanie decyzji znaczy więcej niż sama lista, bo "jeszcze nie" i "nigdy" to różne odpowiedzi, a ta różnica jest dokładnie tym, za co wolno nam pobierać opłatę.
- Wymaga Twojej strony: osiągalność strony docelowej ponad sam kod statusu, pętle przekierowań, ściany logowania, błędy dodawania do koszyka, porównanie feedu ze sklepem. Odłożone do osobnego audytu strony, zamiast wciskania tego w poprawkę feedu.
- Wymaga dostępu do Merchant Center: werdykt po przetworzeniu i kondycja konta. Odłożone do wersji produktu z kontami.
- Wymaga historii: stabilność i dryf między przesłaniami. Pojawi się wraz z zaplanowanym pobieraniem.
- Zupełnie inny kanał: wszystko tutaj jest specyficzne dla Google. Feed, który Google akceptuje, nie jest automatycznie poprawny dla Microsoftu, którego limity się różnią. Jeśli to narzędzie miałoby kiedyś być sprzedawane jako ogólny walidator feedów produktowych, a nie narzędzie dla Google, trzeba by o to pytać przy przesyłaniu, a nie zakładać z góry.
Czego celowo nie raportujemy
Google potrafi na niektórych produktach automatycznie aktualizować cenę, cenę promocyjną, dostępność i stan, a także stosować niektóre ulepszenia zdjęć. Te automatyzacje to tymczasowa rekompensata, a nie zastępstwo dla poprawnych danych źródłowych, i nie obejmują każdego produktu. Dlatego nadal raportujemy wadę w pliku i odnotowujemy, gdzie Google może ją tymczasem maskować, bo ukrycie takiego wyniku schowałoby prawdziwy problem za cudzą łatą.
Atrybuty tax i tax_category są wycofywane w Merchant API i nieobecne
w aktualnej specyfikacji danych produktów. Przetrwały w starszym Content API na czas przejściowy.
Nie walidujemy ich.
To, co sprawdzamy, sprawdzamy gruntownie. Temu poświęcona jest druga strona, a bezpłatna analiza pokazuje Ci, które z tych kontroli wyzwala Twój plik.