Co to jest plik produktowy i do czego służy?

Początkowo plikiem produktowym nazywano plik zawierający zestawione informacje o produktach. Termin ten można jednak postrzegać szerzej, gdyż zamiast produktów mogą znaleźć się w nim dane o usługach, ofertach, artykułach itp. Plik ten może być wyeksportowany z programu, aplikacji, strony internetowej lub utworzony ręcznie. Format zapisanych danych może przyjmować różne postaci, ale najbardziej popularne to XML, CSV lub JSON.

Zastosowanie plików produktowych sprowadza się głównie do wymiany danych między różnymi programami w sposób automatyzujący pracę. Pozwala to uniknąć potrzeby tworzenia dedykowanych API celem udostępnienia danych innym podmiotom, ogranicza się również dostęp tylko do wybranych danych. Postać pliku tekstowego umożliwia na swobodny odczyt na różnych platformach systemowych. Wygenerowane pliki produktowe są z reguły cacho’wane, co pozwala na szybszy dostęp do danych, szczególnie w przypadku dużych zbiorów danych. Dostęp do źródeł odbywa się najczęściej za pośrednictwem protokołu HTTP, gdzie nadawca przekazuje odbiorcy adres URL do pliku, a odbiorca pobiera go automatycznie i przetwarza po swojej stronie.

Na wzrost zainteresowania plikami produktowymi wpłynęły działania marketingowe, które można prowadzić za ich pośrednictwem. Reklamodawcy mogą dostarczać dane o swoich produktach do sieci afiliacyjnych, które za pośrednictwem swoich wydawców pozyskują klientów. Wydawcami w tym wypadku mogą być wszelkiego rodzaju porównywarki cenowe oraz firmy remarketingowe, ale również blogi itp., czyli wszędzie tam, gdzie wskazywanie konkretnych produktów i ich danych ma zastosowanie.

Jak powinien być zbudowany plik produktowy?

Ze względu na zastosowanie reklamowe, plik produktowy powinien zawierać dane produktów szczególnie istotne dla tych działań oraz pozwalające na identyfikację danego produktu. Najistotniejszymi stają się zatem informacje o identyfikatorze produktu w systemie reklamodawcy, nazwa, zdjęcie pozwalające na zobrazowanie użytkownikowi produktu podczas działań reklamowych, ewentualną cenę oraz link pozwalający na bezpośrednie przejście do landing page’a produktu. Dane te są wymagane jako obowiązkowe przez większość podmiotów reklamowych. Ze względu na specyfikę produktu oraz miejsce działań marketingowych, np. porównywarki cenowe, w plikach produktowych mogą być opcjonalnie zawierane inne dane, np. dostępność, kategoria, opis, dodatkowe zdjęcia, cena oryginalna (przed promocją), waluta, wartość promocji, kod ISBN, kod EAN, kod MPN, producent, kolor, rozmiar, waga i wiele innych. Możliwość mnożenia atrybutów opisujących produkty jest olbrzymia i wszystko zależy od konkretnych potrzeb.

Problemy związane z plikami produktowymi

Pliki produktowe rozwiązują problem transferu danych między programami, natomiast nadal nierozwiązana pozostaje spójność danych. Może się okazać, że symbolika pewnych oznaczeń między dwoma wymieniającymi między sobą dane aplikacjami jest zupełnie inna. Prostymi przykładami w przypadku produktów mogą być oznaczenia ich dostępności, np. w jednym programie są to wartości liczbowe określające konkretną ilość produktów na stanie, a w drugim odbierającym dane, są statusy określające produkt, jako „dostępny” lub „niedostępny”. W takim wypadku należy wykonywać mapowanie danych. O ile w tym wypadku nie jest to dość skomplikowane, o tyle wykonanie tej samej operacji w drugą stronę, tzn. przekazanie z programu ze statusami produktu „dostępny/niedostępny” do programu określającego konkretną liczbę produktów na stanie byłoby niemożliwe lub mało wiarygodne. Podobnym często spotykanym przykładem jest mapowanie kategorii produktów. Reklamodawcy na potrzeby swoich sklepów internetowych tworzą własne drzewa kategorii, np. „Ubrania / Koszule”. Porównywarki cenowe, w których chcą zgłaszać swoje produkty, posiadają również własne drzewa kategorii, np. „Moda / On / Koszule”. W celu poprawnego określenia, gdzie mają trafiać odpowiednie produkty należałoby wykonać mapowanie takich kategorii. Wydawcy posiadający odpowiednie zaplecze IT próbują naprawiać tego rodzaju problem poprzez skomplikowane algorytmy i procedury automatycznego mapowania danych zawierających słowa kluczowe w nazwach produktów, nazwach kategorii lub innych metodach, jak analiza kodów produktów, producentów itp. Może się także zdarzyć, że niektóre aplikacje nie operują na drzewach kategorii, a na identyfikatorach liczbowych tych kategorii co tworzy dodatkowe problemy. Te i wiele kwestii bardzo często wymaga indywidualnego podejścia.

Prócz merytorycznych zagadnień mapowania danych mogą pojawić się również niespójności danych wynikające ze stosowania różnych standardów. Prostym przykładem może być zapis liczb. Niektóre kraje korzystają z notacji, w której separatorem części dziesiętnych jest kropka, a kolejnych grup tysięcy jest przecinek. Natomiast w innym kraju może być odwrotnie. Konfiguracja serwera lub programu może być przystosowana do odczytu konkretnego formatu, co może spowodować niepoprawny odczyt wartości. Podobna sytuacja może dotyczyć walut cen podanych w pliku produktowym, gdzie jeden program korzysta z notacji ISO 4217 (np. USD, EUR, PLN), a drugi ze skrótów przyjętych w danym kraju, np. ($, €, zł).

Najpopularniejsze formaty plików produktowych

Plik produktowy w formacie CSV:

Specyfikacja formatu CSV: http://tools.ietf.org/html/rfc4180

Opis formatu CSV:

Konstrukcja pliku CSV („Comma Separated Values”) przypomina postać tabelaryczną. Składa się z wierszy rozdzielonych znakami przejścia do nowej linii oraz kolumn rozdzielonych przecinkiem lub innym określonym znakiem, np. średnikiem, tabulatorem. Pierwszy rekord powinien zawierać nagłówki poszczególnych kolumn, choć nie jest on wymagany – jeśli znana jest kolejność kolumn i ich znaczenie – to jest zalecany. Jeśli w wartości danej kolumny spodziewamy się użyć znaku spacjalnego, jakim jest separator kolumn lub wierszy, powinniśmy taką wartość otoczyć cudzysłowem – oczywiście może być to inny znak, jak apostrofy itp., jednak należy wtedy przekazać taką informację odbiorcy danych, aby odpowiednio zinterpretował te symbole podczas odczytu danych. Pełny opis formatu CSV znajduje się dokumentacji wskazanej powyżej.

Przykład pliku w formacie CSV:

id,nazwa,cena,zdjęcie,link
1,Produkt A,12.99,http://example.org/zdjecie/1.jpg,http://example.org/produkt/1
2,Produkt B,0.78,http://example.org/zdjecie/2.jpg,http://example.org/produkt/2
3,Produkt C,21.69,http://example.org/zdjecie/3.jpg,http://example.org/produkt/3

Częste błędy w formacie CSV:

Specyfikacja formatu CSV pozwala na używanie znaku nowej linii w wartości danej kolumny pod warunkiem, że jest ona objęta cudzysłowem lub innym określonym znakiem. Może się zdarzyć, że interpretery po stronie odbiorców nie radzą sobie z takim zapisem, co powoduje błędny odczyt danych. W celu uniknięcia takich problemów zaleca się unikanie stosowania znaków przejścia do nowej linii w wartościach kolumn rezerwując ten znak jedynie do rozdzielenia kolejnych wierszy. Każde inne wystąpienie tego znaku powinno być usuwane.

Zalety formatu CSV:

Konstrukcja tabelaryczna pozwala na import/export danych przez arkusze kalkulacyjne np. MS Excel, gdzie mogą być łatwo zarządzane.
Wady formatu CSV:

Mało czytelna postać pliku
Popularne firmy korzystające z formatu CSV: Adnologies, Criteo, Zanox.

Plik produktowy w formacie XML:

Specyfikacja formatu XML: http://www.w3.org/TR/REC-xml/

Opis formatu XML:

Dokument XML posiada wielowymiarową konstrukcję hierarchiczną. Rozpoczyna się definicją formatu XML, w tym wersję i standard kodowania danych. Następnie składa się z elementów nazywanych tagami, czyli nazwami objętymi w nawiasy prostokątne – „”. Dodatkowo każdy tag może zawierać atrybuty, czyli pary klucz i wartość dopisane w tagu po nazwie i minimum jednej spacji/tabulacji/nowej linii. Zapis atrybutu to połączona nazwa klucza, znak równości oraz wartość objęta cudzysłowem, np. „”. Tagi mogą być definiowane jako elementy pojedyncze (puste) – nawias prostokątny zamykający definicję tagu poprzedzony jest znakiem slash „/” (np. „”) – lub w postaci tagu otwierającego i zamykającego – tag zamykający nie posiada atrybutów, ma taką samą nazwę, jak tag rozpoczynający, jednak nazwa poprzedzona jest znakiem slash „/” (np. „wartość tagu”). Tagi mogą być zagnieżdżone tworząc konstrukcję hierarchiczną, np. „wartość tagu 2”. Pozwala to na grupowanie danych w zależności od ich znaczenia merytorycznego. Każdy plik XML powinien zawierać przynajmniej jeden tag główny, nazywany korzeniem, w którym zagnieżdżone są pozostałe tagi. Na ogół w pliku produktowym w korzeniu zawarte są tagi zawierające definicję kolejnych pozycji produktów, a kolejne tagi w środku każdego z nich reprezentują odpowiednie dane, jak identyfikator, nazwę, opis itp.

Format XML można próbować rzutować do formatu tabelarycznego, jak CSV, lecz staje się on o wiele mniej czytelny. Ponadto format CSV narzuca stałą liczbę kolumn, w przypadku XML, poszczególne tagi odpowiadające kolumnom w każdym rekordzie mogą mieć zupełnie inną konstrukcję, która zależy np. od rodzaju produktu – ubrania mają tagi „”, warzywa mają tagi „” itp.

Przykład formatu XML:

Produkt A
12.99

http://example.org/zdjecie/miniaturki/1.jpg
http://example.org/zdjecie/1.jpg

http://example.org/produkt/1
Produkt B
0.78

http://example.org/zdjecie/miniaturki/2.jpg
http://example.org/zdjecie/2.jpg

http://example.org/produkt/2

Częste błędy w formacie XML:

Specyfikacja formatu XML narzuca, aby wszystkie wystąpienia znaków specjalnych, czyli „<”, „>” oraz „&” były zastępowane ich kodami znaków, czyli odpowiednio „<”, „>” oraz „&”. Odstępstwem od tej reguły jest zapis wartości zawierających te znaki w sekcji „CData”, np. „]]>”. Często zdarza się, że twórcy plików XML zapominają o odpowiednim zakodowaniu tych wartości przez co parsery mają problem z rozpoznaniem danych zwracając komunikat błędu. Podobne zjawisko dotyczy otwierania i zamykania tagów. Jeśli tag nie posiada tagu zamykającego, powinien w definicji kończyć się slash’em przed zamknięciem tagu, w przeciwnym wypadku, interpreter będzie przetwarzał dane oczekując tagu zamykającego, być może pomijając lub błędnie interpretując część lub wszystkie dane.

Zalety formatu XML:

Format pozwalający w czytelny sposób zaprezentować praktycznie każdy rodzaj danych.
Nazwa tagu przy każdej danej umożliwia szybką interpretację jej znaczenia bez potrzeby znajomości kolejności kolumn, jak w przypadku formatu CSV.
Dane mogą być opisywane przez dodatkowe atrybuty, np. typ zdjęcia – miniaturka czy duże.
Nie występuje problem ze znakami przejścia do nowej linii, jak w przypadku formatu CSV.

Wady formatu XML:

Ze względu na powielające występowanie nazwy tagów i atrybutów opisujących dane przy każdej pozycji produktu, wielkość pliku będzie dużo większa niż w przypadku formatu CSV, gdzie występowały tylko znaki rozdzielające kolumny i wiersze.
Popularne firmy korzystająće z formatu XML: Advertine, Ceneo, Criteo, Google PLA, Nokaut, TradeDoubler, TradeTracker, Zanox.

Plik produktowy w postaci JSON

Specyfikacja formatu JSON: http://tools.ietf.org/html/rfc7159

Opis formatu JSON:

Specyfikacja JSON („JavaScript Object Notation”) przedstawia, że praktycznie każdy rodzaj danych można zapisać w postaci tablic zwykłych (indeksowanych numerycznie) lub tablic asocjacyjnych (kluczem tablicy jest unikalna nazwa) – zwanych także obiektami prostymi. Służą do tego symbole zaczerpnięte z języka JavaScript, gdzie tablicę reprezentują nawiasy kwadratowe „[” i „]”, natomiast obiekty nawiasy klamrowe: „{” i „}”. Wszystkie wartości oraz nazwy kluczy powinny być objęte cudzysłowami. Pary klucz i wartość w obiektach odseparowane są znakiem dwukropku, np. „klucz”: „wartość”. Kolejne wartości w tablicy lub pary klucz/wartość w obiekcie odseparowane są przecinkiem. Prosty przykład tablicy w notacji JSON, to: [„Wartość A”,”Wartość B”,”Wartość C”], natomiast obiektu: {„Klucz A”:”Wartość A”,”Klucz B”:”Wartość B”,”Klucz C”:”Wartość C”}. Przedstawione elementy można ze sobą łączyć tworząc tablice zawierające zbiory obiektów i odwrotnie, wartościami dla wskazanego klucza obiektu mogą być inne tablice. Dzięki temu można utworzyć plik produktowy zawierający tablicę kolejnych obiektów reprezentujących dane produktów.

Przykład formatu JSON:

[
{
„id”: „1”,
„nazwa”: „Produkt A”,
„cena”: „12.99”,
„zdjecia”: [
{
„typ”: „miniaturka”,
„zdjecie”: „http://example.org/zdjecie/miniaturki/1.jpg”
},
{
„typ”: „duze”,
„zdjecie”: „http://example.org/zdjecie/1.jpg”
}
],
„url”: „http://example.org/produkt/1”
},
{
„id”: „2”,
„nazwa”: „Produkt B”,
„cena”: „0.78”,
„zdjecia”: [
{
„typ”: „miniaturka”,
„zdjecie”: „http://example.org/zdjecie/miniaturki/2.jpg”
},
{
„typ”: „duze”,
„zdjecie”: „http://example.org/zdjecie/2.jpg”
}
],
„url”: „http://example.org/produkt/2”
}
]

Częste błędy w formacie JSON:

Podobnie, jak w przypadku formatu CSV czy XML, format JSON również zawiera znaki specjalne, których użycie w nazwie klucza lub wartości powinno zostać poprzedzone znakiem ucieczki, w tym wypadku znakiem backslash „\”. Mowa o znakach cudzysłowu oraz backslash „\”. Częstym błędem jest pominięcie tej operacji co skutkuje błędnym zinterpretowaniem danych. Należy również pamiętać o unikalnych nazwach kluczy w obrębie danego obiektu.

Zalety formatu JSON:

Często mniejszy plik w porównaniu z XML, natomiast trochę większy niż CSV, ale zdecydowanie bardziej czytelny, dzięki umiejscowieniem nazw kluczy przy wartościach.
Przygotowany do użytkowania za pośrednictwem języka JavaScript (wbudowane parsery JSON w przeglądarce), bez potrzeby dodatkowego przetwarzania, jak w przypadku XML czy CSV.
Wady formatu JSON:

W niektórych bibliotekach programistycznych parsowanie pliku JSON wymaga jego wczytanie w całości, potem dopiero zdekodowanie do postaci tablic i obiektów, co utrudnia przetwarzanie dużych zbiorów danych, które można przetwarzać strumieniowo, jak w przypadku XML czy CSV.
Brak rozróżnienia typu danych, np. liczbowe czy tekstowe podczas parsowania danych.
Popularne firmy korzystające z formatu CSV: Akakce (mało popularny format w przypadku zastosowania plików produktowych).

Bezpieczeństwo plików produktowych

Ze względów bezpieczeństwa dostępu do danych może zajść potrzeba ograniczenia dostępu do plików produktowych tylko dla wybranych podmiotów. W takim przypadku można zastosować kilka rodzajów weryfikacji:

Jeśli plik produktowy umieszczony jest na serwerze FTP można ograniczyć dostęp do niego poprzez wskazanie nazwy użytkownika oraz hasła to pobrania danych.
Jeśli znamy adres IP odbiorcy pliku można utworzyć białą listę („White List”) adresów IP, dla których dostęp do danych będzie dozwolony.
Odpowiednia analiza nagłówków żądania, np. używana przeglądarka itp. może posłużyć do dodatkowej autoryzacji.
Translacja/mapowanie formatów plików produktowych

Część reklamodawców udostępnia swoje pliki w określonych formatach. Czasem są to popularne formaty, np. używane w różnego rodzaju porównywarkach cenowych, jak Ceneo, Nokaut, czy Google PLA, a czasem zupełnie nie znane specyfikacje. W przypadku mniejszych sklepów internetowych często wynika to z zastosowania open source’owych rozwiązań, które dopasowują się do popularnych rozwiązań. Natomiast duże firmy posiadające własne zaplecze IT stawiają na własne dedykowane rozwiązania. Z drugiej strony wydawcy korzystający z danych przekazywanych od reklamodawców często muszą dopasowywać je do własnych, jeszcze innych standardów. Mogą wykonać to na dwa sposoby: modyfikować swoje aplikacje, aby umożliwiały import kolejnych formatów, co jest bardzo kosztowne, lub doprowadzić przekazane pliki produktowe do postaci zrozumiałej dla ich aplikacji, czyli wykonać tzw. mapowanie. Drugie rozwiązanie jest zdecydowanie prostsze i tańsze w wykonaniu, gdyż nie narusza bezpieczeństwa funkcjonowania przetestowanej już aplikacji.

Mapowanie danych nie jest zadaniem trywialnym. Może wystąpić wspomniany wcześniej problem ze spójnością danych, np. przy określaniu dostępności produktów itp. W innych przypadkach może brakować wymaganych danych. Można nadać im wartości domyślne, ale czasem może być to niemożliwe i trzeba te dane w jakiś sposób wygenerować lub oszacować. Niestety obniża to wiarygodność danych.

Dodatkowo każde kolejne mapowanie danych na podstawie wcześniej przetłumaczonego pliku powoduje redundancję niespójności danych. Gdzie tylko to możliwe należy starać operować się na oryginalnych danych źródłowych.

Zagadnienia dodatkowe

Zgłębiając tematykę plików produktowych można napotkać na wiele problemów dodatkowych wynikających z przetwarzania danych oraz odnośnie samych danych, np.

Kodowanie danych powinno być zgodne z kodowaniem pliku. Jeśli aplikacja działa na bazie kodowania UTF-8, dane dostarczone w innym kodowaniu powinny być odpowiednio przekodowane. Problem często pojawia się w plikach XML, gdzie definicja pliku XML informuje aplikację, że dane zapisane są w formacie UTF-8, natomiast dokument zawiera znaki niezgodne z tym kodowaniem. Może to spowodować przerwanie pracy parsera i wszystkie dane nie zostaną przetworzone.
Duże pliki produktowe często dostarczane są w postaci archiwów, np. ZIP, które znacząco redukują wielkość pliku, dlatego warto zadbać, aby aplikacja aktualizująca bazę danych na podstawie takiego pliku produktowego umożliwiała rozpakowanie go przed rozpoczęciem przetwarzania, w innym wypadku prawdopodobnie zostanie zgłoszony błąd niepoprawnego formatu pliku.
Linki docelowe zawarte w pozycjach produktów w pliku produktowym powinny kierować bezpośrednio do landing page’a danego produktu. Niektóre serwisy ukrywają zawartość danych tylko dla zalogowanych użytkowników, co może powodować zmniejszenie konwersji. Zaleca się stworzenie dedykowanych rozwiązań, np. w postaci wygenerowanego parametru umożliwiającego podgląd karty produktu również dla niezalogowanych użytkowników.
Aktualizacja plików produktowych jest bardzo ważna – część firm wykonuje tą operację tylko w przypadku zmian w opisach produktów. Nic bardziej mylnego, gdyż niektóre dane mogą ulec modyfikacji niezależnie od zmian w opisach wykonywanych przez osobę obsługującą te dane, np. zmiana stanu magazynowego. Może ona ulegać automatycznemu zmniejszaniu wraz z wykonywanymi zakupami przez użytkowników na stronie sklepu internetowego. Produkty mogą zostać wyprzedane, a plik produktowy wskazywać, że nadal są dostępne. Informacje te powinny być aktualizowane na bieżąco. Zaleca się stałe odświeżanie zawartości plików, przynajmniej raz dziennie. Aktualizacja nie powinno być też zbyt częsta, jeśli czas generowania pliku trwa długo, szczególnie w przypadku dużej liczby danych i mało efektywnych aplikacjach, np. jeśli plik generuje się 15 min, to nie ma sensu generować go co 10 min – w tym wypadku odstępy czasowe ok. 1 h byłby rozsądnym rozwiązaniem.
Jeśli pliki produktowe wykorzystywane są do dynamicznych kreacji zaprojektowanych przy użyciu języka JavaScript, a dane dostępne są pod inną domeną niż działający skrypt, niemożliwe jest pobranie danych z pliku produktowego – problem dotyczy połączeń „Cross-domain”, które są blokowane ze względów bezpieczeństwa przez przeglądarki. Sposobem pozwalającym na obejście tego typu ograniczenia jest zastosowanie technologii JSONP, która pozwala na pobranie zawartości pliku i przekazanie jej w postaci atrybutu funkcji o nazwie wskazanej z żądaniu do pliku. Niestety źródło danych musi być przystosowane do zwrócenia danych w odpowiednim formacie, co nie zawsze jest możliwe. Można natomiast posłużyć się serwerami proxy udostępniającymi taką możliwość.