Jakie są sposoby przechowywania informacji o anonimowym/gościnnym użytkowniku w bazie danych?

Question

Nasza aplikacja zawiera między innymi sklep internetowy, a użytkownicy są zwykle proszeni o zarejestrowanie się przed zakończeniem sprzedaży, tworząc w ten sposób unikatowy customer_ID. Po powrocie mogą się zalogować, a ich dane kontaktowe i historia transakcji są pobierane z bazy danych.

Obecnie badamy, co zrobić w przypadku klienta "anonimowego" lub "gościa", otwierając sklep internetowy dla klientów, którzy nie chcą się zarejestrować, a także dla sprzedaży zalogowanej w aplikacji backendowej, gdy przyjmowanie adresu e-mail klienta, adresu pocztowego itp. jest po prostu zbyt czasochłonne. Rozwiązanie ma również aplikacje poza sklepem internetowym.

Wiele firm korzysta z tej samej bazy danych, a baza danych jest zbudowany na party model struktury, więc musimy przeanalizować kilka opcji:

1. przechowywania wszystkich anonimowych klientów pod jednym wstępnie zdefiniowane customer_ID w tabeli transaction:
   1. customer_ID = 0 dla każdego anonimowego użytkownika, a customer_ID > 0 dla każdego prawdziwego użytkownika
      • Ten í y prosta do ciężkiej kodu do aplikacji
      • Ale bardziej w celu określenia, które klienci należą do których firma
      • Jeżeli dane dla customer_ID = 0 istnieje w tabeli customer w bazie danych lub jako obiekt w aplikacji?
        • Jeśli w bazie danych, jakie ograniczenia na poziomie bazy danych można wprowadzić, aby zapewnić, że zawsze istnieje?
        • Jeśli nie w bazie danych, a następnie klucz obcy z transaction.customer_ID do customer.customer_ID działa już
   2. customer_ID jest taka sama jak firmy party_ID
      • łatwiejsze do określenia zagregowane sprzedaży dla każdej firmy , itp.
      • Spowoduje to zamieszanie, ponieważ wydaje się, że firma jest jej własnym klientem, a nie innymi unikatowymi klientami.
2. Generowanie unikalnego customer_ID dla każdego nowego klienta anonimowego (na sesję)
   • co jeśli te same fizyczne użytkownik powraca? Będzie wiele rekordów powtarzających ten sam rodzaj danych; e-mail, adres wysyłki, itp
3. Użyj innego unikatowego klucza, takie jak adres e-mail, aby odnosić się do klienta
   • nie zawsze wiarygodne, jak ludzie używają czasami więcej niż jeden adres e-mail, lub zostawić stare adresy za.
   • Co zrobić, jeśli nie ma adresu e-mail, który należy podjąć, tak jak w przypadku hali produkcyjnej, faktur pro forma itp.?
4. Niektóre inne rozwiązania inspirowane stosem Stack Overflow!

Dodawanie

Połączenie # 2 i # 3 Sugerowano gdzie indziej - próbę zapisania pojedynczy rekord dla każdego klienta, korzystając z adresu e-mail, jeśli to możliwe, lub nowy rekord na każdej wizycie Jeśli nie.

muszę podkreślić, że nie potrzebę przechowywanie zapisu dla każdego anonimowego klienta, ale po prostu wydaje się, że relacyjna baza danych została zbudowana do czynienia z relacji, więc o NULL lub customer_ID w transaction tabela, która nie odnosi się do rzeczywistego rekordu klienta, wydaje się po prostu błędna ...

Muszę również podkreślić, że celem tego pytania jest ustalenie, jakie są rzeczywiste rozwiązania w zakresie rejestrowania "przypadkowych" transakcji, w których nie ma adresu pocztowego lub podany jest adres e-mail (wyobrazić sobie chekout w supermarkecie) wraz z transakcjami w sklepie internetowym, w których adres e-mail i adres pocztowy są podawane bez względu na to, czy są przechowywane, czy nie.

Jakie rozwiązania wykorzystała społeczność SO w przeszłości?

Answer 1

Zakładając, że wymagają adresu e-mail dla wszystkich zamówień internetowych, można utworzyć konto czasowe dla każdego klienta na zakończenie każdego zamówienia, gdy nie jesteś zalogowany.

Można to zrobić za pomocą adres wysyłkowy i inne informacje podawane podczas realizacji transakcji w celu wypełnienia konta i wysłania do nich losowego hasła tymczasowego (opcjonalnie oznaczenie go jako wymagające zmiany przy pierwszym logowaniu, jeżeli ta funkcjonalność jest wbudowana na stronie internetowej). Wymaga to minimalnego wysiłku z ich strony, aby skonfigurować konto i umożliwia im zalogowanie się w celu sprawdzenia statusu zamówienia.

Ponieważ kluczem podstawowym w bazie danych jest identyfikator customer_id, nie powinien powodować konfliktów, jeśli nadal będą tworzyć nowe konta z tym samym adresem e-mail/adresem itp., Chyba że posiadasz już kod zapobiegający duplikatom. Rzadko zdarza się, aby ktoś utworzył więcej niż jedno konto tymczasowe, ponieważ łatwiej jest zalogować się za pomocą hasła wysłanego do nich pocztą elektroniczną niż wprowadzić ponownie dane.

W przypadku zleceń backendu zazwyczaj tworzymy konto w taki sam sposób jak powyżej dla każdego klienta. Jeśli jednak nie mają oni adresu e-mail (lub chcą kupować tylko przez telefon), generujemy konto wraz z ich informacjami o wysyłce i pustym adresem e-mail (musimy zakodować wyjątek, aby nie wysyłać tymczasowych haseł/zamów potwierdzenia, gdy są puste). Podany jest identyfikator customer_id, a informacje o wysyłce i nazwa firmy są przechowywane na koncie w celu sprawdzenia i przyspieszenia przyszłych zamówień.

Answer 2

Zwykle korzystam z adresu IP użytkownika, tworzę konto z samym ID i jego adresem IP. Kiedy się rejestruje, po prostu aktualizuję jego zapis. Inne rzeczy niż IP mogłyby (i powinny) być również użyte, np. Tworzenie losowego tokena do wstawienia pliku cookie w celu ominięcia dowolnego używanego systemu sesji, aby można było na przykład dłużej przetrwać.

Teraz, w aplikacji, musisz uczynić swoją klasę użytkownika zdolną do "identyfikacji" użytkowników za pomocą tego adresu IP/tokena, prawdziwej sesji lub dowolnego innego systemu logowania, jaki możesz mieć.

Answer 3

Wątpię, czy istnieją doskonałe rozwiązania tego problemu. Po prostu musisz dokonać wyboru: jak ważna jest gwarancja rozpoznawalnej historii klienta, w przeciwieństwie do poprawy uzyskiwanych konwersji, które nie zmuszają klienta do przejścia przez pełny proces rejestracji.

Jeśli przejdziesz bez wymuszania rejestracji, nie będziesz w stanie rozpoznać powracających klientów w 100% przypadków. Można argumentować, że nawet z rejestracją, która nie będzie możliwa, ponieważ użytkownicy czasami decydują się na tworzenie nowych kont z różnych powodów. Ale możesz być w stanie zrobić coś, co jest "wystarczająco dobre" dzięki zrozumieniu danych, które już posiadasz.

Na przykład w niektórych krajach kody pocztowe są dość szczegółowe. Czy są wystarczająco szczegółowe? Zależy od tego, w jakich krajach prowadzisz działalność, a także od sposobu budowania bazy klientów. Jeśli masz zazwyczaj tylko jednego użytkownika na gospodarstwo domowe, może.

Lub w zależności od metod płatności, które popierasz, możesz rozważyć utworzenie jednokierunkowego skrótu numeru karty kredytowej ("identyfikator pseudo-unikalny"). Niektóre rozwiązania płatnicze faktycznie zwracają unikalny "identyfikator płatnika", który może być doskonały - zakładając, że otrzymujesz coś ze wszystkich obsługiwanych przez ciebie usług płatniczych.

Answer 4

Przypisałbym unikalny identyfikator klienta, aby zapisać dane, a następnie przy przyszłych zakupach, które ten sam anonimowy nabywca może sprawdzić, czy ten sam adres e-mail i/lub pierwsza linia adresu i kodu pocztowego już istnieje . Jeśli poprosisz o numer telefonu, porównaj to. Zasadniczo potrzebujesz czegoś dość wyjątkowego, pozbywając się możliwych błędów (np. Patrząc tylko na pierwszą linię adresu - jest bardzo prawdopodobne, że jest więcej niż jedna główna ulica!Ale będzie tylko jeden 123 Main Street z kodem pocztowym ABC123).

Gdy się już zorientujesz, możesz automatycznie utworzyć dla nich konto - wysyłając do klienta wiadomość e-mail z informacją, że zauważyłeś, że wcześniej ją kupił, a aby zaoszczędzić czas, użyj tego adresu e-mail i tego automatycznie wygenerowanego hasła. Gdy logują się po raz pierwszy, wykonaj szybką kontrolę bezpieczeństwa (może wartość ostatniej faktury), a następnie pozwól im sprawdzić ich dane. Możesz nawet zrobić to podczas procesu kasowania. Myślę, że pokazując, że możesz zaoszczędzić im czasu, zrobienie tego automatycznie może być bonusem.

Jeśli nie chcesz tego robić, możesz ustawić plik cookie, ale musisz ostrzec użytkownika, jeśli handlujesz z poziomu UE (prawa dotyczące plików cookie).

Problem z osobą o innym adresie e-mail i adresie pocztowym może być taki, że zamawia on firmę, a następnie może zamówić do osobistego użytku (trudno powiedzieć, ponieważ nie wiemy, co sprzedajesz).

Answer 5

Oczywiście można śledzić sesję sprzedaży za pomocą plików cookie. ale także zarejestrować użytkowników anonimowych w swojej witrynie, ale nie pozwól im uświadomić sobie, że wypełniają formularz rejestracyjny. Pozwól im śledzić proces sprzedaży, a pod koniec procesu sprzedaży wygeneruj unikalny identyfikator klienta i wyślij go e-mailem, a także wyświetl to powiadomienie. na stronie po zakończeniu sprzedaży i zalogowaniu się na stronie przez podanie swojego identyfikatora klienta.

Answer 6

Sposób, w jaki to robię, to: Wcale nie.

Po prostu pozwól, aby ludzie płacili przez Paypal lub cokolwiek, co umieścisz jako rozwiązanie płatnicze i uzyskaj dane z tego miejsca, automatycznie utworzą użytkownika i zamówienie po przetworzeniu płatności za pomocą dostarczonego API.

W tym momencie masz wszystkie potrzebne informacje, które możesz z pewnością przechowywać w ilości wystarczającej do statystyk/marketingu e-spam.

Zachowaj to proste, nie wymagaj niczego, nawet osoby do wprowadzenia identyfikatora klienta lub e-maila, a wszyscy będą go uwielbiać.

Czyniąc to, nadal mam wszystkie informacje, którymi mogłem się zainteresować, a wrażenia użytkownika są tak szybkie i łatwe, jak to tylko możliwe.

Answer 7

Mmmm ... generujemy identyfikator uniq dla użytkowników-gości - wartość hash lub uuid dla nazwy użytkownika i zapisz ją w tabeli koszyka. Przechowujesz to również w tabeli klienta, jeśli nie przeszkadza ci zaśmiecanie bazy danych takimi danymi. Uuid jest przechowywany w pliku cookie w przeglądarce klienta, dopóki nie sprawdzi koszyka. Plik cookie jest również przyjemny przy przypisywaniu anonimowego konta (i zawartości jego koszyka) do ważnego konta, jeśli użytkownik zdecydował się zarejestrować później/przed sprawdzeniem koszyka.

Answer 8

Utworzę unikalny identyfikator klienta i zapiszę go na komputerze użytkownika jako plik cookie. Powinno to zmniejszyć liczbę użytkowników z wieloma identyfikatorami klienta.

Ale z całą powagą, o ile twoja liczba identyfikatorów nie dostanie się do setek tysięcy (i gratulacje, jeśli tak jest!), To nie zaszkodzi twojej bazie danych, dopóki masz odpowiednie indeksy na kolumna id klienta.

Jeśli miałeś identyfikator = 0 dla każdego klienta, czy nie miałbyś tyle samo wierszy? Myślę, że to nieuniknione, jeśli chcesz zachować wszystkie dane, prawda? Identyfikator zerowy może również powodować dodatkowe problemy z indeksem.