@mortus
Nie rozumiesz zasad e-commerce. Nie będę tego tłumaczyć 2 raz. Analiza rynkowa nie jest dokonywana na podstawie tego co jest w koszyku tylko an tym co zostało kupione. Ehhh... A po tym gdzie proces zakupów został przerwany jest ważne z kilku powodów i możemy w ten sposób dowiedzieć się czy np warunki przesyłki mu nie odpowiadały, może nie wszystko jest napisane jasno i miał wątpliwości, może okres realizacji zamówienia był za długi itd. itp.

To Ty kolego nie rozumiesz, że nijak się to ma do implementacji koszyka na zakupy. Informacja o tym, co zostało kupione powinna się znaleźć w tabeli zamówień zrealizowanych, a informację o tym, w którym "miejscu" użytkownik odstąpił od dokonania zakupu powinien przesyłać sam system, a nie konkretnie koszyk na zakupy. Zauważ, że jeśli użytkownik dokona zakupu, to przechodzi do modułu odpowiedzialnego za realizacje zamówień, jeśli wycofa się w tej chwili, to właśnie ten moduł powinien raportować, że użytkownik wycofał się z realizacji zamówienia. Tak na dobrą sprawę powodów, dla których użytkownik "napełnił" koszyk i zostawił może być mnóstwo i możemy tylko przypuszczać, dlaczego postąpił on tak, a nie inaczej. Wątpię aby te dane były przydatne z punktu widzenia Twojej analizy rynkowej. Inaczej ma się sprawa zamówień na produkty, które już są w koszyku (kolejny, że tak to nazwę, krok podczas zakupów). Tutaj wykorzystujemy implementację koszyka tylko do pobrania informacji o produktach, które użytkownik do koszyka "wrzucił" i tyle. Resztą zajmuje sie moduł obsługi zamówień. Zrozum wreszcie, że są to dwie różne "rzeczy".

@spokoloko123 pomysł bardzo fajny, ale i tak ten kosz warto zrobić na sesji, a w bazie rejestrować zmiany kosza. Chociaż realizując Twoją koncepcję warto by zrobić coś bardziej rozbudowanego, ponieważ samo zapisanie kosza to marne narzędzie analityczne. Co Ci daje informacja, że ktoś zrezygnował mając mp3player'a w koszyku? Jeżeli chcemy na poważnie analizować utraconych klientów to warto by rejestrować wszystkie kroki tego klienta na naszej stronie, czyli nie tylko co dodał, ale też co oglądał i całą drogę jaką dany klient przebył w serwie, skąd zaczął, a gdzie skończył. Wydaje mi się, że takie narzędzie do analizy to zupełnie odrębny i o wiele bardziej zaawansowany temat. Ponadto tego typu dane nabierają wartości raczej przy dużym ruchu na stronie, małej ilości danych nie da się poddać rzetelnej analizie.

Taka analiza ma tylko i wyłącznie sens w przypadku użytkowników, którzy dokonali wcześniej rejestracji.

To zależy, co chcemy analizować. Bo jeśli np. badamy, czy asortyment jest wystarczający (tzn. umożliwia zadowolenie większości potencjalnych klientów) to musimy rejestrować większość ruchów użytkownika, o czym pisał tehaha, np. to po jakich kategoriach się poruszał, jakie produkty dodawał do koszyka, czy z niego usuwał, czy w ogóle coś dodawał i usuwał. Tutaj nie ma potrzeby zakładania konta, czy rejestrowania się i użytkownik nie musi wiedzieć, że go "obserwujemy" dopóki jest on użytkownikiem anonimowym. Jeśli analizujemy "sprawność" systemu, to musimy zapisywać i analizować informacje, o jakich pisał spokoloko123, czyli to, czy użytkownik zrezygnował z zakupu, na jakim etapie wtedy był, czy może jednak zdecydował się dokonać zakupu, a może nie odpowiadał mu sposób dokonywania płatności, itd.. Im więcej danych zbierzemy, tym dokładniejsza i bardziej wiarygodna będzie analiza.

Ogólnie jest to tak szerokie zagadnienie, że można by książkę napisać, albo więcej książek. Jednak nadal przekonuję, że nijak ma się do sposobu implementacji sklepowego koszyka.

Edycja:
Poza tym to off-top.

No ale jeśli użytkownik nie będzie zarejestrowany,to wobec czego będziecie go kojarzyć(jest anonimowy jak nazwa wskazuje),po Ip (jest zmienne),DNS(także zmienne),User Agent(może korzystać z różnych browserów)?Może dodać koszyk usunąć, zamknąć browser, otworzyć inny browser i dokonać zakupu tego samego przedmiotu, a ty dostaniesz dwie różne statystyki tego samego użytkownika w rezultacie czego statystyki będą odzwierciedlały fałszywy obraz.
Jedyne co mi na myśl przychodzi to budowanie statystyk dla anonimowego użytkownika na podstawie coocies, ale to chyba byłoby wariactwo.

Oczywiście jeśli użytkownik się zarejestruje, a co więcej poda swój wiek, to przyczyni się do tego, że analiza będzie bardziej szczegółowa. Będzie można np. określić grupę docelową dla produktów z danej kategorii.
Natomiast każdy ruch użytkownika, czy to dodanie przedmiotu do koszyka, czy przejście do kategorii to nic innego jak wywołanie żądania obsługiwanego przez określony moduł systemu i każdy taki moduł "zobowiązany jest do raportowania swojego stanu". Te informacje zapisujemy w bazie danych i poddajemy analizie.

@Niktoś identyfikacji użytkownika pomiędzy żądaniami dokonujesz na podstawie ID sesji
Oczywiście, że tak może być, każde badanie statystyczne jest obciążone błędem pomiaru i zawiera "obserwacje odstające", nie istnieje idealne badanie, które przedstawi 100% rzeczywisty obraz sytuacji. Aczkolwiek tego typu badanie i tak będzie wartościowe, ponieważ po pierwsze niewiele kosztuje w porównaniu do innych metod badawczych bo drugie statystyki są gromadzone w sposób ciągły i przy dużych ruchu można wyciągnąć bardzo wiele wniosków i obserwować zmiany po ulepszeniach i zmianach w serwisie.

Tak czytam i aż mnie dziw bierze jak bardzo ludzie nie rozumieją o co chodzi w sesjach. Sesje to nasz pośrednik pomiędzy klientem i serwerem w bezstanowym protokole HTTP. Aby móc powiązać te dane potrzebujemy:
- utworzyć identyfikator sesji (SID czy jakkolwiek go sobie nazwiemy)
- gromadzić dane sesji

Sesje implementujemy po stronie klienta za pomocą:
- doklejania parametru sesji (SID) do adresu (jeżeli nie ma obsługi np cookies)
- za pomocą cookies
- można się ewentualnie pokusić o local storage (choć nie wiem czy ktoś tak aktualnie robi, są rozwiązania w JS wykorzystujące różne handlery w zależności od technologii którą klient wspiera) tyle że też nowoczesne przeglądarki ze wsparciem ogółu technologii zwanych HTML5 otwierają ogromne pole do popisu dla włamów
Po stronie klienta możemy trzymać albo sam SID, albo jakieś dodatkowe, tymczasowe dane ale nic ważnego (ciastko można skasować, można je zmienić, wirus może próbować je odczytać albo zmienić).

Oraz po stronie klienta za pomocą dowolnego mechanizmu przechowywania. Może to być:
- relacyjna baza danych
- nierelacyjna baza danych
- pliki tekstowe
przy czym rozwiązania te są zupełnie niezależne od naszej implementacji sesji a zależą od dostępności technologii i wymagań projektu. Jak ktoś wcześniej zauważył można nawet podmontować obszar pamięci jako katalog i obsługa operacji na danych jest zrzucona na system operacyjny (kernel, który we wszystkich rozwiązaniach i tak pośredniczy, to tak off-topicowo).
Tutaj, z racji tego że klient dostępu do tych danych nie ma, przechowujemy dane ważne. Tyle że rozwiązania te muszą być zabezpieczone przed typowymi próbami nieupoważnionego dostępu jak choćby SQL Injection czy inne wymienione w wątku.

W obu przypadkach od nas zależy co przechowujemy w tych implementacjach ponieważ każde z nich ma jakieś ograniczenia. Cookie do 4kB, relacyjne bazy danych mogą być wolne (ale nie przesadzajmy, przy ilości zapytań potrzebnych do obsługi całego sklepu to pryszcz dla silnika), trzymanie w pamięci może sprawić że dane stracimy.

Sam mechanizm sesji to całkowicie nasza inicjatywa bo akurat w tym przypadku można skorzystać z gotowych, dostępnych w PHP metod ale też napisać klasę która nic z SessionHandler czy interface nie implementuje. Chodzi tylko o to żeby powiązać SID klienta z SID serwera. Co więcej, można nawet napisać taki mechanizm, który dla danych mniej istotnych tworzy namespace pracujący w backendzie na noSQL a dla danych istotnych dla baz relacyjnych.

dla jednego browsera: permanent cookie, panopticlick
sytuacja "zamknąć browser, otworzyć inny browser i dokonać zakupu tego samego przedmiotu" jest możliwa ale marginalna (ZU trzyma się jednej przeglądarki)