Do wdrożenia sklepu przygotuj dla każdego produktu minimum: nazwę, SKU lub inny identyfikator, warianty, zdjęcia, ceny, stany, opisy, atrybuty, kategorie, status publikacji i format pliku, z którego wykonawca ma zaimportować dane. Bez tego sklep może wyglądać na gotowy, ale katalog będzie wymagał ręcznych poprawek, a koszyk, filtry, panel zamówień i późniejsze kampanie produktowe zaczną działać na niepewnych danych.
Jeśli jesteś jeszcze na etapie rozmowy z wykonawcą, oddziel ten krok od tego, jakie dane do wyceny sklepu internetowego trzeba wysłać do porównania ofert. Do wyceny często wystarczy skala, typy produktów i poziom złożoności. Do wdrożenia potrzebny jest już konkretny materiał: plik, kolumny, zdjęcia, warianty, źródło cen i zasady aktualizacji.
Nie chodzi o przygotowanie idealnej bazy danych. Chodzi o to, żeby wykonawca nie musiał zgadywać, co jest produktem, co wariantem, które zdjęcie jest główne, skąd brać stan magazynowy i czy pusta komórka oznacza "brak danych", czy "usuń obecną wartość". Przy tworzeniu sklepów internetowych właśnie te niepozorne decyzje najczęściej wpływają na import, kartę produktu, wyszukiwarkę, filtry i poprawność pierwszych zamówień. Dlatego katalog warto od razu zestawić z tym, jakie funkcje sklep internetowy powinien mieć na start, zamiast traktować produkty jako osobny arkusz poza procesem sprzedaży.
Co przygotować do wdrożenia produktów w 30 sekund
Najkrótsza odpowiedź jest prosta: przygotuj plik lub eksport, w którym każdy produkt i każdy wariant da się jednoznacznie rozpoznać, wyświetlić klientowi i obsłużyć po zamówieniu. Sama lista nazw produktów nie wystarczy. W sklepie dane produktowe pracują w kilku miejscach naraz: na karcie produktu, w kategorii, w filtrach, w koszyku, w panelu zamówienia, w magazynie i w analityce.
| Element danych | Co przygotować | Co sprawdzić przed przekazaniem |
|---|---|---|
| Nazwa produktu | Pełna, zrozumiała nazwa odróżniająca produkt od podobnych pozycji | Czy klient po nazwie wie, co ogląda |
| SKU lub identyfikator | SKU, EAN, ID z ERP, ID ze starego sklepu albo inny stały klucz | Czy identyfikator jest unikalny dla produktu lub wariantu |
| Warianty | Rozmiar, kolor, pojemność, materiał, pakiet, konfiguracja | Czy każdy wariant ma własny stan, cenę lub SKU, jeśli tego wymaga sprzedaż |
| Zdjęcia | Zdjęcie główne, galeria, zdjęcia wariantów, nazwy plików albo URL-e | Czy zdjęcia da się powiązać z produktem i kolejnością galerii |
| Ceny | Cena brutto lub netto, waluta, VAT, promocja, cena wariantu | Czy wiadomo, który system jest źródłem prawdy |
| Stany | Ilość, dostępność, czas wysyłki, status na zamówienie | Czy stan dotyczy produktu zbiorczego czy konkretnego wariantu |
| Opisy | Krótki opis, długi opis, parametry, ograniczenia, zastosowanie | Czy opis odpowiada na pytania kupującego, a nie tylko wypełnia pole |
| Atrybuty | Kolor, rozmiar, materiał, marka, kompatybilność, pojemność i inne cechy | Czy wartości są spójne i nadają się do filtrów |
| Kategorie | Kategoria główna, podkategoria, ewentualnie kolekcja lub seria | Czy produkt nie trafia do kilku przypadkowych miejsc |
| Format pliku | CSV, XLSX, XML, API albo eksport ze starego sklepu | Czy wykonawca zna separator, kodowanie, nagłówki i sposób mapowania |
Minimalny pakiet do przekazania wykonawcy:
- Plik produktowy: CSV, XLSX, XML, eksport platformy albo opis API z przykładowymi rekordami.
- Klucz identyfikacji: SKU, EAN, ID produktu lub ID wariantu, który nie zmienia się między systemami.
- Logika katalogu: kategorie, warianty, atrybuty, status publikacji i pola używane w filtrach.
- Materiały widoczne dla klienta: zdjęcia, opisy, parametry, ograniczenia produktu i informacje o dostępności.
- Dane operacyjne: ceny, stany, czas wysyłki, źródło prawdy i zasady aktualizacji po starcie.
Czerwona flaga: zdanie "produkty są w Excelu" nie oznacza jeszcze gotowości do wdrożenia. Arkusz może mieć nazwy i ceny, ale nadal nie mieć SKU wariantów, kategorii, powiązanych zdjęć, spójnych atrybutów, statusów publikacji ani jasnej informacji, co zrobić z pustymi polami.
Najpierw źródło prawdy i format pliku
Zanim ktokolwiek zacznie importować produkty, trzeba ustalić, skąd pochodzą dane i który zestaw jest nadrzędny. Produkty mogą być w arkuszu, starym sklepie, systemie ERP, PIM, hurtowni, pliku XML, API albo w kilku miejscach naraz. Problem pojawia się wtedy, gdy każdy plik wygląda "trochę aktualnie", ale nikt nie wie, który ma rację.
Najprostsza zasada: dla każdego typu danych wskaż źródło prawdy. Ceny mogą pochodzić z ERP, zdjęcia z folderu w chmurze, opisy z arkusza, a stany z hurtowni. To nie musi być jeden system. Musi być jasne, który system wygrywa, gdy dane się różnią.
| Źródło danych | Kiedy wystarcza | Na co uważać |
|---|---|---|
| XLSX lub CSV | Przy małym i średnim katalogu bez częstych automatycznych aktualizacji | Różne nazwy kolumn, puste pola, ręczne zmiany bez historii |
| Eksport ze starego sklepu | Przy migracji istniejącego katalogu | Stare opisy, nieaktualne zdjęcia, błędne kategorie, brak wariantów |
| XML hurtowni | Gdy produkty i stany mają przychodzić od dostawcy | Opisy niskiej jakości, losowe atrybuty, zdjęcia bez redakcji |
| API | Gdy dane mają aktualizować się cyklicznie lub z kilku systemów | Potrzebna dokumentacja, mapowanie pól i obsługa błędów |
| ERP lub PIM | Gdy firma zarządza cenami, stanami i katalogiem centralnie | Trzeba ustalić, które pola sklep może edytować, a których nie |
Format pliku zależy od platformy i importera, więc nie ma jednej uniwersalnej listy kolumn dla każdego sklepu. Są jednak rzeczy, które warto przygotować zawsze: nagłówki kolumn, przykładowe wiersze, separator w CSV, kodowanie znaków, informację o pustych komórkach, sposób łączenia zdjęć z produktem i klucz aktualizacji. Ten klucz jest szczególnie ważny przy kolejnym imporcie, bo system musi wiedzieć, czy aktualizuje istniejący produkt, tworzy nowy, czy pomija rekord.
Przy CSV i XLSX dopisz wykonawcy, co oznacza puste pole. To drobiazg, który potrafi uratować katalog. Pusta komórka w kolumnie "opis" może oznaczać "opis niegotowy", ale w niektórych procesach importu może zostać potraktowana jako pole do wyczyszczenia. Podobnie z ceną promocyjną, zdjęciem, stanem albo kategorią.
Decyzja przed importem: jeśli katalog jest niewielki i nie zmienia się codziennie, uporządkowany arkusz zwykle wystarczy do pierwszego wdrożenia. Jeśli ceny, stany, warianty albo opisy mają aktualizować się regularnie z ERP, hurtowni, marketplace lub PIM, traktuj XML, API albo integracje w sklepie internetowym jako część procesu, a nie dodatek po starcie.
Nazwy, SKU i warianty produktów
Nazwa produktu ma być zrozumiała dla klienta, ale też użyteczna dla obsługi sklepu. Nie powinna składać się wyłącznie z marketingowego hasła ani z kodu magazynowego. Dobra nazwa odróżnia produkt od podobnych pozycji: model, typ, najważniejsza cecha, rozmiar zestawu albo przeznaczenie, jeśli to pomaga w wyborze.
SKU, EAN lub inny identyfikator ma inne zadanie. To nie jest tekst dla klienta, tylko klucz porządkujący dane w sklepie, magazynie, imporcie, zamówieniu i ewentualnych integracjach. Jeśli produkt ma warianty, często to wariant powinien mieć własny identyfikator. Inaczej panel zamówienia pokaże, że klient kupił produkt, ale obsługa nadal będzie musiała zgadywać rozmiar, kolor albo pojemność.
Przykład neutralny: bluza dostępna w rozmiarach S-XXL i trzech kolorach nie powinna mieć jednego wspólnego stanu magazynowego, jeśli realnie sprzedajesz konkretne kombinacje. Wtedy wariant "granatowa, M" powinien dać się odróżnić od "granatowa, L" oraz od "szara, M". Może mieć tę samą cenę, ale nadal potrzebuje własnej dostępności i identyfikatora, jeśli sklep ma poprawnie obsłużyć zamówienie.
| Sytuacja | Lepiej jako wariant | Lepiej jako osobny produkt |
|---|---|---|
| Różni się tylko rozmiar, kolor, pojemność lub materiał | Tak, jeśli klient wybiera opcję na jednej karcie | Nie, jeśli każda opcja ma osobną decyzję zakupową |
| Różni się cena lub stan | Tak, jeśli to nadal ta sama karta produktu | Tak, jeśli różnice zmieniają zastosowanie lub odbiorcę |
| Różni się opis, zdjęcia i kategoria | Czasem, jeśli warianty są mocno powiązane | Często, jeśli klient porównuje je jak oddzielne produkty |
| Produkt ma konfigurator lub personalizację | Czasem jako wariant plus pola dodatkowe | Czasem jako osobny proces, jeśli logika jest niestandardowa |
| Produkty mają różne słowa kluczowe i intencje | Raczej nie | Tak, jeśli potrzebują osobnych kart i treści |
Nie każdy wybór klienta musi być wariantem. Jeśli "zestaw startowy" i "zestaw profesjonalny" mają inne zdjęcia, opis, przeznaczenie, zawartość i kategorię, osobne karty produktów mogą być czytelniejsze. Jeśli jednak różni się tylko kolor obudowy, rozbijanie tego na kilka produktów może utrudnić porównanie i zaśmiecić kategorię.
Czerwone flagi przy SKU i wariantach:
- Ten sam SKU występuje przy kilku różnych wariantach, choć mają osobne stany magazynowe.
- Jeden produkt zbiorczy ma podany wspólny stan, ale nie wiadomo, ile sztuk przypada na każdy rozmiar lub kolor.
- Warianty są wpisane w opisie tekstowym, ale nie istnieją jako dane do wyboru na karcie produktu.
- Nazwy wariantów są niespójne: raz "granat", raz "navy", raz "ciemny niebieski".
- W zamówieniu nie da się jednoznacznie odczytać, jaki wariant klient kupił.
Praktyczny wniosek: zanim przekażesz produkty do wdrożenia, rozpisz jeden trudniejszy produkt z wariantami do końca. Jeśli na nim da się pokazać nazwę, SKU, cenę, stan, zdjęcie i atrybuty każdego wariantu, reszta katalogu zwykle będzie łatwiejsza do uporządkowania.
Zdjęcia, opisy i dane widoczne dla klienta
Import techniczny może utworzyć produkty w sklepie, ale to zdjęcia i opisy zdecydują, czy klient rozumie, co kupuje. Dlatego materiały produktowe warto przygotować razem z plikiem danych, a nie traktować ich jako luźny folder "do późniejszego podpięcia".
Przy zdjęciach przygotuj co najmniej zdjęcie główne i informację, które zdjęcia należą do galerii. Jeśli warianty różnią się wizualnie, dopisz powiązanie zdjęcia z wariantem. W praktyce może to być nazwa pliku zawierająca SKU, osobna kolumna z URL-em zdjęcia albo lista plików w kolejności galerii. Ważne, żeby wykonawca nie musiał ręcznie otwierać folderu i zgadywać, które zdjęcie pokazuje dany produkt.
| Materiał | Co przygotować | Ryzyko, jeśli tego brakuje |
|---|---|---|
| Zdjęcie główne | Jeden plik lub URL wskazany dla produktu | Sklep wybierze przypadkową miniaturę albo produkt będzie bez zdjęcia |
| Galeria | Kolejność zdjęć, zdjęcia detali, zdjęcia skali, zdjęcia opakowania | Klient nie zobaczy informacji, które zastępują kontakt z obsługą |
| Zdjęcia wariantów | Powiązanie zdjęcia z kolorem, rozmiarem, materiałem lub wersją | Klient może wybrać wariant, którego nie rozpoznaje wizualnie |
| Krótki opis | Najważniejsza informacja widoczna blisko ceny i CTA | Karta produktu zacznie od ogólnika zamiast decyzji zakupowej |
| Długi opis | Zastosowanie, cechy, ograniczenia, zawartość zestawu, pielęgnacja lub montaż | Klient będzie dopytywać o podstawowe informacje |
| Parametry | Dane techniczne, wymiary, skład, kompatybilność, materiał | Filtry i porównanie produktów będą słabsze |
Opis z hurtowni może być punktem wyjścia, ale nie powinien automatycznie trafiać do sklepu bez weryfikacji. Często jest zbyt ogólny, powielony w wielu sklepach, napisany językiem dostawcy albo zawiera cechy, których klient nie używa przy wyborze. Jeżeli na start nie masz gotowych opisów, oznacz status: gotowy, do redakcji, do uzupełnienia, tymczasowy albo niepublikować. To lepsze niż mieszanie gotowych kart z pustymi lub przypadkowymi opisami.
Dobry test jest prosty: pokaż kartę produktu osobie, która nie zna katalogu. Czy po nazwie, zdjęciach, cenie, wariantach, stanie i opisie wie, co kupuje? Czy rozumie różnicę między wariantami? Czy widzi ograniczenia, takie jak dłuższy czas wysyłki, nietypowy gabaryt albo konieczność dobrania kompatybilnej części? Jeśli odpowiedź brzmi "trzeba dopytać", dane produktowe nie są jeszcze gotowe do publikacji, nawet jeśli da się je zaimportować.
Czerwona flaga: zdjęcia są rozrzucone w mailach, komunikatorach i folderach bez nazw SKU, a w arkuszu nie ma kolumny ze zdjęciem głównym. To zwykle oznacza ręczne dopasowywanie materiałów i ryzyko publikacji niewłaściwej galerii.
Praktyczny wniosek: dane widoczne dla klienta przygotuj tak samo starannie jak pola techniczne. SKU porządkuje import, ale to zdjęcia, opisy i warianty porządkują decyzję zakupową.
Atrybuty, kategorie i filtry
Kategorie i atrybuty powinny odpowiadać sposobowi wyboru produktu przez klienta, a nie tylko układowi magazynu. Jeśli klient wybiera po rozmiarze, kolorze i materiale, te cechy muszą być spójne. Jeśli wybiera po kompatybilności, modelu, pojemności albo zastosowaniu, te pola powinny być danymi, a nie zdaniem ukrytym w opisie.
Najpierw rozpisz drzewo kategorii. Nie musi być skomplikowane. Ważne, żeby produkt miał jasne miejsce główne i żeby podkategorie nie powstawały przypadkowo z nazw importu. Ten sam typ produktu nie powinien raz trafiać do "Akcesoria", raz do "Dodatki", a raz do "Inne", jeśli klient ma potem używać katalogu bez zgadywania.
Atrybuty warto dzielić na trzy grupy:
- Atrybuty do wyboru wariantu, na przykład rozmiar, kolor, pojemność.
- Atrybuty do filtrów, na przykład materiał, marka, kompatybilność, zastosowanie, dostępność.
- Informacje opisowe, które są ważne na karcie produktu, ale nie muszą być filtrem.
Nie każdy parametr musi trafiać do filtrów. Filtr ma pomagać w decyzji, a nie pokazywać wszystkie pola z hurtowni. Jeżeli w kategorii pojawia się kilkadziesiąt losowych atrybutów, wiele pustych wartości i kilka wersji tej samej cechy, klient dostaje pozornie rozbudowany katalog, który utrudnia wybór.
| Problem w atrybutach | Skutek w sklepie | Co zrobić przed wdrożeniem |
|---|---|---|
| "Czarny", "black", "czarny mat" i "czarny." jako osobne wartości | Filtr koloru wygląda chaotycznie | Ustalić słownik wartości |
| Atrybut jest raz kolumną, raz częścią opisu | Filtry nie obejmują wszystkich produktów | Przenieść ważne cechy do danych strukturalnych |
| Wiele pustych wartości | Filtry prowadzą do słabych lub pustych wyników | Oznaczyć braki i zdecydować, czy atrybut zostaje |
| Kategorie są tworzone z nazw dostawcy | Menu nie odpowiada językowi klienta | Zmapować kategorie źródłowe na kategorie sklepu |
| Ten sam produkt pasuje do kilku miejsc | Ryzyko duplikacji i chaosu w adresach | Ustalić kategorię główną i ewentualne powiązania |
Decyzja praktyczna: dla każdej ważnej kategorii wybierz 3-8 cech, które naprawdę pomagają klientowi zawęzić wybór. W jednej kategorii będzie to rozmiar, kolor i materiał. W innej kompatybilność, model, zakres zastosowania i dostępność. Resztę można zostawić jako dane opisowe, jeśli nie pomaga w filtrowaniu.
Czerwona flaga: katalog ma dużo atrybutów, ale nie da się odpowiedzieć, które z nich mają być filtrami. To znak, że import przenosi dane z dostawcy, ale nie projektuje ścieżki wyboru produktu.
Ceny, stany, dostępność i status publikacji
Ceny i stany są krytyczne, bo bezpośrednio wpływają na koszyk i obsługę zamówienia. W pliku produktowym nie wystarczy jedna kolumna "cena", jeśli w praktyce sklep ma ceny brutto i netto, różne stawki VAT, promocje, warianty z dopłatą, sprzedaż B2B albo dane z ERP. Nie trzeba opisywać wszystkiego naraz, ale trzeba nazwać, które wartości mają wejść do pierwszej wersji sklepu.
Przy cenach doprecyzuj:
- czy cena w pliku jest brutto czy netto,
- jaka jest waluta,
- czy VAT jest stały, czy zależy od produktu,
- czy warianty mają różne ceny,
- czy istnieje cena promocyjna i kiedy ma obowiązywać,
- czy cena po imporcie ma być edytowana w sklepie, czy aktualizowana z innego systemu.
Przy stanach magazynowych podobnie ważna jest logika. Stan może oznaczać konkretną liczbę sztuk, status "dostępny", czas wysyłki, produkt na zamówienie albo dostępność pobieraną od hurtowni. Jeśli sklep sprzedaje warianty, stan powinien dotyczyć wariantu, a nie wyłącznie produktu zbiorczego. Jeśli sklep sprzedaje w kilku kanałach, trzeba ustalić, czy wszystkie kanały korzystają z tej samej puli.
| Dane operacyjne | Pytanie kontrolne | Ryzyko bez decyzji |
|---|---|---|
| Cena brutto/netto | Która wartość ma być pokazana klientowi i w koszyku | Błędne sumy, nieporównywalne oferty, poprawki ręczne |
| VAT | Czy stawka jest potwierdzona dla danej grupy produktów | Niejasne dane do faktury i koszyka |
| Promocja | Czy ma datę startu, końca i cenę bazową | Promocja zostaje po czasie albo nadpisuje dobrą cenę |
| Stan | Czy dotyczy produktu, wariantu, magazynu czy hurtowni | Sprzedaż niedostępnego wariantu |
| Czas wysyłki | Czy zależy od stanu, dostawcy lub produktu na zamówienie | Klient dostaje obietnicę, której sklep nie spełni |
| Status publikacji | Czy produkt jest aktywny, ukryty, szkicem, do uzupełnienia lub wycofany | Do sklepu trafiają produkty niegotowe do sprzedaży |
Status publikacji jest często pomijany, a przy wdrożeniu bardzo pomaga. Nie każdy produkt z importu musi od razu pojawić się publicznie. Część może być gotowa, część wymagać zdjęć, część opisu, a część ma być ukryta do czasu decyzji handlowej. Jeżeli statusu nie ma, wykonawca może zaimportować pełny katalog, który technicznie istnieje, ale sprzedażowo jest nierówny.
Czerwona flaga przy cenach i stanach: cena w arkuszu, cena w ERP i cena u dostawcy różnią się, a nikt nie wskazał systemu nadrzędnego. W takiej sytuacji import może być poprawny technicznie, ale błędny biznesowo.
Decyzja: zanim wykonawca zaimportuje katalog, wskaż źródło prawdy osobno dla cen, stanów, promocji i statusów publikacji. Jeżeli te dane mają aktualizować się automatycznie, dopisz częstotliwość aktualizacji i scenariusz błędu. Sklep powinien wiedzieć, co zrobić, gdy hurtownia nie zwróci stanu, ERP ma inną cenę albo plik zawiera pustą wartość.
Kontrola jakości przed importem i wdrożeniem
Ostatni krok to kontrola danych przed właściwym importem. Nie zaczynaj od masowego wgrania całego katalogu. Najpierw sprawdź próbkę, która pokazuje najważniejsze przypadki: produkt prosty, produkt wariantowy, produkt z promocją, produkt z kilkoma zdjęciami i produkt z nietypowym stanem, na przykład "na zamówienie" albo "czasowo niedostępny".
Kontrola jakości powinna obejmować nie tylko to, czy plik się wgrywa. Ważniejsze jest, czy produkt po imporcie wygląda poprawnie dla klienta i czy zamówienie z tym produktem da się obsłużyć w panelu.
| Test przed importem | Co sprawdzić | Decyzja |
|---|---|---|
| Unikalność identyfikatorów | Czy SKU, EAN lub ID nie dublują się tam, gdzie powinny być unikalne | Wstrzymaj import, jeśli warianty są nieodróżnialne |
| Kompletność pól | Czy produkty mają nazwę, cenę, status, kategorię i zdjęcie główne | Oznacz braki przed publikacją |
| Warianty | Czy warianty mają poprawne opcje, ceny, stany i zdjęcia | Nie publikuj, jeśli klient może kupić zły wariant |
| Zdjęcia | Czy pliki lub URL-e działają i są przypisane do właściwych produktów | Popraw mapowanie przed importem masowym |
| Kategorie | Czy produkty trafiają do właściwych miejsc w katalogu | Nie przenoś chaosu z arkusza do menu sklepu |
| Atrybuty | Czy wartości są spójne i użyteczne w filtrach | Uporządkuj słowniki przed budową filtrów |
| Ceny i stany | Czy sklep pokazuje właściwą cenę i dostępność | Wstrzymaj, jeśli źródło prawdy jest niejasne |
| Puste pola | Czy wiadomo, czy mają zostać pominięte, czy wyczyścić dane | Ustal regułę przed aktualizacją istniejących produktów |
Po próbnym imporcie przejdź produkt jak klient. Wejdź w kategorię, użyj filtra, otwórz kartę produktu, wybierz wariant, dodaj do koszyka i sprawdź, czy w koszyku oraz panelu zamówienia widać właściwą nazwę, SKU, wariant, cenę i dostępność. To nadal nie jest pełne sprawdzenie sklepu przed uruchomieniem, ale pozwala wychwycić błędy danych, zanim staną się błędami sprzedażowymi.
Warto też podzielić uwagi na blokery i poprawki. Blokerem jest brak identyfikatorów wariantów, błędne ceny, niepowiązane zdjęcia, niejasne stany, zły status publikacji albo kategorie, które uniemożliwiają klientowi znalezienie produktu. Poprawką po imporcie może być dopracowanie części opisów, uzupełnienie mniej ważnych zdjęć, rozwinięcie parametrów albo lepsze nazwy filtrów, jeśli zakup nadal działa poprawnie.
Decyzja krok po kroku przed przekazaniem katalogu:
- Wskaż źródło prawdy dla produktów, cen, stanów, zdjęć i opisów.
- Ustal format pliku oraz klucz aktualizacji: SKU, EAN, ID produktu lub ID wariantu.
- Rozdziel produkt i warianty, szczególnie tam, gdzie różnią się stanem, ceną lub zdjęciem.
- Uporządkuj zdjęcia i opisy tak, żeby karta produktu odpowiadała na realne pytania kupującego.
- Wybierz kategorie i 3-8 atrybutów, które pomagają filtrować produkty w danej kategorii.
- Oznacz status publikacji: gotowy, szkic, do uzupełnienia, ukryty albo wycofany.
- Zrób import testowy na reprezentatywnej próbce, zanim ruszy pełny katalog.
- Sprawdź produkt w kategorii, na karcie produktu, w koszyku i w panelu zamówienia.
Najważniejszy wniosek jest praktyczny: dobry plik produktowy nie polega na tym, że ma dużo kolumn. Polega na tym, że każda ważna kolumna ma właściciela, znaczenie i wpływ na decyzję klienta albo obsługę zamówienia. Jeśli dane produktowe są spójne przed wdrożeniem, sklep łatwiej uruchomić, testować i rozwijać. Jeśli są chaotyczne, nawet najlepszy importer tylko szybciej przeniesie chaos do katalogu.