Hi, Martina (laramarco), a tried and tested Oxid user with apparently a lot of e-business experience behind her, has asked me to translate some considerations from her POV:
Deleting user data has significant drawbacks for any shop owner: - multiple costs for credit assessment are caused, - affiliate bonuses cannot be calculated correctly, - newsletter subscriptions are messed up, - marketing activities are made more difficult (the whole marketing aspect has to be reconsidered in Oxid), - user coupons become a problem, assignment to user groups are made impossible, - abc-pricing is made impossible, - buyer fraud becomes easier, - and more.... I hope I have reported everything correctly! :-) (compare below) --- BTW: Ralf or one of the developers: Could you point out to us which registration and order classes we should look at in order to prevent user deletion (I find again and again that doxygen is sometimes secretive and does not respond to just any search string extracted from a piece of code)? Cheers, Achim ---------------- Hallo Achim, glaub wir kennen uns noch nicht, ich bin die laramarco aus dem alten sowie neuen Forum und lese auch die Dev Liste. Mein englisch reicht aber nicht aus, um mit Euch mit zu diskutieren, habe eben aber folgendes Ralf in skype gestellt, vielleicht kannst Du das noch mit an die Dev Liste geben: hi ralf, ich nehme jetzt hier das skype weil mein englisch für eure dev gruppe nix taugt, aus shopbetreibersicht ist das löschen eines accounts schlicht scheiße - weil - jedes mal neue boniprüfung gezahlt werden muß - keine module a la umsatzbasierende provisionen funktionieren - weil selbst bei newsletter an und abmeldungen murks läuft - weil wie andreas schrieb, die kompletten marketing dinge einfach nicht richtig durchdacht sind - wie kann ich diesen usern gutscheine ausstellen, welche benutzergruppen kann ich ein bzw. ausschließen, auch bei den rabatten wirds nicht klappen, oder wer mit abc preisen arbeitet, wie soll das funzen und und und, da fallen mir noch zig gründe ein, betrug durch benutzen mehrerer ähnlicher namen/adressen - wenn der mal gelöscht ist, findet man nix und liefert an betrüger aus, weil eben der admin keine daten zu dem namen findet - je länger ich nachdenk, also ich bin definitiv NICHT für löschen Hoffe Du kannst meine Kurzzeilen verstehen ;) Mit freundlichen Grüßen Martina Schimbach ---- http://FollowMeButton.com/auth.php?user=laramarco Martinas Bastel- & Hobbykiste Geschäftsleitung Bestellhotline: 0800-9655324 Martinas Bastel- & Hobbykiste Inh. Martina Schimbach Zum Grund 9 35796 Blessenbach Germany ---------------- -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]]im Auftrag von Reinhard Schneidewind Gesendet: Donnerstag, 15. April 2010 20:44 An: [email protected] Betreff: Re: [oxid-dev-general]Deletingunregistereduser accounts [T-3CKCXFBU7D-56] Hi, to remove the connection from oxorder to oxuser generates a problem with our export-interface. So I agree to Achim. As I remember OXID said that they cannot make a solution for all. But would it not be possible to provide an option in the shop admin-interface where each shop provider has the ability to choose if the data should be deleted or new ids should be created. Some of you wrote that a customer which uses the option to place the order without registration do not want his data to be kept in the shop database. But in my opinion this is part of the privacy agreement. Further if I order something and use the option "without registration", I know that the data will be kept (not only for marketing purposes). The only reason why I would use this option is that, at the time of placing the order, I have no plan to place a further order in near future. Regards, Reinhard On 2010-04-15 18:38, Achim Leinberger wrote: > Hi Andreas, hi Ralf, > > the seller is legally bound to keep the records for ten years. Full stop. > > This is not up to the customer. All the customer can demand, is that his > records are purged from any marketing database. That's his legal right, but > has nothing to do with the order database. > > So I don't really see why the "vanishing buyer details bug" is not simply > corrected by keeping the frigging customer data in the user table, and > handing a new user id to the next "guest buyer". > > I really can't see any wrong with that. > > Cheers, > Achim > > > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]]im Auftrag von anzido > GmbH > Gesendet: Donnerstag, 15. April 2010 17:51 > An: [email protected] > Betreff: Re: [oxid-dev-general]Deletingunregistereduser accounts > [T-3CKCXFBU7D-56] > > > Hi Achim, > > most shop owners do want to have the user data in their shops to use them > for marketing activities and evaluation. They do want to know if somebody is > a NEW customer or if he already bought something in the shop etc. > > All those activities might not be allowed if somebody buys explicitly > WITHOUT andy registration. The data have to be kept for fulfillment > reasons - but only as long as needed. > > So from a customer point of view I would agree that data have to be deleted > after a certain period of time - which probalby has to be configurable cause > there might be some different periods of warranty etc. which have effect on > how long the data have to be kept. > Another question is, if those data have to be kept in the shop database.. I > think there might be customers who are (by pretty good reasons!) afraid that > their personal data might not be very save on a web server in the internet. > > > From a shop owners point of view (and from the experience with our > customers) you probably should keep the data in the shop and make sure that > they stay connected with orders, newsletter data and so on. > > Cheers! > Andreas Ziethen | Geschäftsführung > > > >> Hi, >> >> I'd like to know where people see the legal issues with keeping the >> fulfillment data in the database, be it under oxuser or oxorder. >> >> IMO this has nothing at all to do with the advertisement "buy without >> opening an account". Opening an account is nothing more than being able to >> login later and have all personal data available after logging in. Not >> wishing to open this account does not legally bind the seller to not store >> the details, in fact, this being a mailorder business case, data have to >> > be > >> stored. >> >> So I think this discussion is beside the point, but please explain >> > otherwise > >> if I'm wrong. >> >> Best, >> Achim >> (oxal) >> >> >> >> -----Ursprüngliche Nachricht----- >> Von: [email protected] >> [mailto:[email protected]]im Auftrag von Ralf >> Trapp >> Gesendet: Donnerstag, 15. April 2010 16:55 >> An: [email protected] >> Betreff: Re: [oxid-dev-general] Deletingunregistereduser >> accounts[T-3CKCXFBU7D-56] >> >> >> Ahoi, >> >> I summarize. You basically suggest a procedure like this: >> >> 1. During order processing, a temporary account is >> Created in a 'good' place (what exactly 'good' >> means is still to be defined). >> >> 2. All necessary information for fulfilling the order >> collected and stored somewhere in a 'good' place >> (what exactly 'good' means is still to be defined). >> >> 3. Previously created temporary account is deleted, >> order information is kept. >> >> I'm not yet talking about database and issues, just want to agree about >> basic procedure and later on about how to realize it. >> >> Regards, >> >> Ralf >> >> >> -----Ursprüngliche Nachricht----- >> Von: [email protected] >> [mailto:[email protected]] Im Auftrag von >> [email protected] >> Gesendet: Mittwoch, 14. April 2010 12:40 >> An: [email protected] >> Betreff: Re: [oxid-dev-general] Deleting unregistereduser >> accounts[T-3CKCXFBU7D-56] >> >> I think there is(!) a legal problem.. >> >> When the order process starts, the "guest" account is advertised like "buy >> without a customer account in our shop". >> >> But matter-of-factly, the shop is allocating a customer account, and it is >> keeping it forever... >> >> So you are basically cheating your customers... >> >> Imo xtCommerce handles this situation correctly: >> >> During order processing, a temporary account is created, which is deleted >> after successful order processing. >> >> All necessary information for fulfilling the order is kept in the order >> record(s) in the DB, and this particular order is never changed by the >> > shop > >> any more, if not the shop-owner changes it on purpose (address-info, >> articles aso.). >> >> If the same client should order again later on, new order record(s) will >> > be > >> created. >> >> Doing it that way, you both adhere to your promise (no customer account in >> the shop), and you can fulfill the order. >> >> Dipl.-Ing.(TH) Winfried Kaiser (aka Avenger) >> >> >> -----Ursprüngliche Nachricht----- >> Von: [email protected] >> [mailto:[email protected]] Im Auftrag von Ralf Trapp >> Gesendet: Mittwoch, 14. April 2010 12:21 >> An: [email protected] >> Betreff: Re: [oxid-dev-general] Deleting unregistered user >> accounts[T-3CKCXFBU7D-56] >> >> Hi all, >> >> from legal point of view there's no prob at all as of course shop owners >> need this data to fulfill the order. >> >> As changes here affect many (esp. external) connections to and with OXID >> eShop, I'd like to trigger a discussion about possible _solutions_ which >> > can > >> and should be implemented. >> >> Any ideas? >> >> Regards, >> >> Ralf >> >> >> -----Ursprüngliche Nachricht----- >> Von: [email protected] >> [mailto:[email protected]] Im Auftrag von anzido >> > GmbH > >> Gesendet: Freitag, 13. November 2009 09:13 >> An: [email protected] >> Betreff: Re: [oxid-dev-general] Deleting unregistered user >> accounts[T-3CKCXFBU7D-56] >> >> Hi Marco, >> >> >>> notes. Hope you recognized the wind of change of the past >>> months/weeks. :-) >>> >> I did ... - and hope it'll keep blowing! ;-) >> >> >> >> >>> > From a legal point of view - and this should be the only and lonely >>> criterion - I would propose ... >>> >> > From a legal point of view there cannot be any "proposal". This has to be >> properly investigated and at the end of the day there has to be a reliable >> statemet of how things have to be done. >> >> >>> - oxremarks would appear in oxorder as well >>> >> I don't think that the order remarks have been meant here ... - but I >> > might > >> be wrong. >> >> >>> - as there would not be any oxuser entry, the unregistered user cannot >>> have a history or related stuff >>> >> For several purposes many shop owners do want to have such history of >> unregistered users. But as I said above: Make sure that we soon get a >> reliable legal statement for that. >> >> >>> In my opinion, this is not just a dirty workaround but a legal >>> requirement. If we consequently implemented it like proposed, of course, >>> a couple of problems would come up, especially for existing interfaces >>> that used oxuser instead of oxorder for gathering data before. >>> >> Exactly. And another thing is that customers get a new customer number >> > each > >> time they order (if not registered). Actually I doubt that this is an >> oblogatory legal request. >> >> As I said: first pleyse check out the definite legal conditions. And then >> let's see what's up for the code. >> >> >> Regards >> Andreas >> >> >> _______________________________________________ >> dev-general mailing list >> [email protected] >> http://dir.gmane.org/gmane.comp.php.oxid.general >> _______________________________________________ >> dev-general mailing list >> [email protected] >> http://dir.gmane.org/gmane.comp.php.oxid.general >> >> _______________________________________________ >> dev-general mailing list >> [email protected] >> http://dir.gmane.org/gmane.comp.php.oxid.general >> _______________________________________________ >> dev-general mailing list >> [email protected] >> http://dir.gmane.org/gmane.comp.php.oxid.general >> >> >> _______________________________________________ >> dev-general mailing list >> [email protected] >> http://dir.gmane.org/gmane.comp.php.oxid.general >> > _______________________________________________ > dev-general mailing list > [email protected] > http://dir.gmane.org/gmane.comp.php.oxid.general > > > _______________________________________________ > dev-general mailing list > [email protected] > http://dir.gmane.org/gmane.comp.php.oxid.general > > _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
