ich möchte das der Warenkorb den sich ein Nutzer anlegt gespeichert wird.
Wenn er dann die Seite verlässt ohne das er die Bestellung abschließ würde ich ihn gern eine eMail senden.
Ich suche eine Lösung das ich mir den Warenkorb von Kunden anzeigen kann die sich mit Name usw. registriert haben aber den Bestllprozess abgebrochen haben.
Die eMail würde ich dann gern so formulieren:
Wir haben festgestellt das sie den Bestellprozess für die Artikel
1
2
3
Nicht beendet haben. Helfen Sie uns unseren Shop zu verbessern. Welche Gründe haben dazu geführt? Bla Bla Bla
Das Mail würde ich aus meiner CRM Lösung schreiben also ohne PHP. Hat da zufällig jemand eine Lösung für mich.
obwohl ich die Idee für Klasse halte, hab ich dazu doch einige Bedenken: Ich würde nach Deiner “follow up”-Email wahrscheinlich nie wieder Deinen Shop betreten, aber da gibt es sicher andere Charaktere
M. E. werden die Warenkörbe erst dann in die Datenbank gespeichert, wenn der Kunde die Bestellung abschließt. Insofern wird es eh schwierig mit Deinem Vorhaben…
Wir warten seit Jahren darauf das es eine standard Funktionalität von Oxid gibt die Warenkörbe zu behalten. Leider vergebens. Statt solchen Kernfunktionalitäten werden lieber irgendwelche AJAX Spielereien oder Kundenlogin Möglichkeiten gebaut die sowieso keiner nutzt.
Da muss ich 'mal dem Michael zustimmen. Fuer XTC gibt es da ein Module was diese ermoeglicht und aus eigener Erfahrung liegt die Erfolgsrate mit der “Follow-up” Email zwischen 30%-50%, was nicht schlecht ist fuer einen Mausklick. Wie auch immer, ich denke ein Module anstatt Core waere trotzdem die bessere Loesung.
Ich glaube auch das die Erfolgsrate zwischen 20 und 30% liegt. Ich bin selber auch ein großer Onlineshopper und habe letztens von einem Shop mal so ein EMail erhalten. Ich muß gestehen ich war begeistert von dieser zuvorkommenden eMail.
Die war so freundlich geschrieben und hat mich überzeugt in diesem SHop zu bestellen.
Ich habe damals die Produkte in den Warenkorb eingefügt und wollte bezahlen nachdem ich mich registriert hatte stellte ich fest das NUR Vorkasse zur Verfügung stand insgesamt machte der SHop auch nur einen weniger Profesionellen EIndruck also verzichtete ich zuerst auf die Bestellung und habe den Bestellvorgang abgebrochen. Die folgende eMail hat mich dann aber überzeugt.
Ich stehe auch sehr auf Datenschutz aber ich habe das damals eher unter Service abgetahn und muß sagen das ich keine Probleme damit habe. Ich habe mich ja registriert und meine eMailadresse angegeben. Ich hätte sehr gestaunt wenn ich das nicht gemacht hätte und so eine eMail bekommen hätte. :-)))))
Gruß
PS: Wenn die Warenkörbe in einem Cookie gespeichert werden dann kann man doch ein php Script schreiben das diesen ausliest und in eine DB schreibt. Wenn jemand lust hat sich die Entwicklungsarbeit zu teilen und dann gemeinsam zu verwenden ich bin dabei. Wenn sich 3 oder 4 Leute finden sollte das ein Klax sein.
Momentan sind wir am überlegen in welcher Form wir eine Infrastruktur hinstellen können, damit solche Feature Requests sinnvoll durch die Community konzipiert werden können. Damit hätten wir etwas richtig handfestes in der Hand, das prima im Produktmanagement und damit in der Entwicklung benutzt werden kann. Allerdings liesse sich das konkret angesprochene prima als Modul abbilden, das wäre im angesprochenen Fall sicher erst mal der schnellere Weg.
Das klinkt gut aber WANN soll es denn soweit sein. Bin gern dabei. Macht es nur nicht zu hochwertig sonst dauert es zu lange bis da mal was losgeht. Macht lieber einfache flache Struckturen die schnell und aggiel sind.
interessante idee das ganze und (wie immer) denke ich, das sowas im core gut aufgehoben ist. macht auch für oxid einen guten eindruck sowas by default im Angebot zu haben.
Eine Aussage wie “per Modul erhältlich” ist zwar immer schön aber nicht 100% überzeugend. Ein Modul sind immer extra Aufwand und daher extra kosten. in zeiten in denen wirklich überall gespart wird ist ein “all-in-one” paket mit minimalsten aufwand immer die beste variante.
edith meint ich soll noch folgendes sagen:
eine feature request struktur macht erst dann sinn wenn man nicht bei jedem einzelnen request hört “machs selber”, “mach nen modul”, “wende dich an firma x die für geld y macht” oder am besten ist auch ein: “braucht nicht jeder also machs selber/lass es machen”
für sowas brauch man kein wiki. ist nicht bös gemeint aber das ist zu 100% das, was ich nicht nur bei meinen requests höre sondern auch bei anderen sehe. fakt ist, das einige “tolle” features des oxid shops mit sicherheit auch nicht von jedem benutzt werden (openid als neustes beispiel) und trotzdem reingemacht wurde. (kundenwunsch? oder programmiererwunsch?)
genau dafür soll es diese feature-request-Geschichte geben, an der alle mitbauen können. Wichtig ist, dass der Programmierer ein ganz konkretes Konzept in die Hand bekommt, was wie im Core umgesetzt werden soll/kann. Wie Du selbst schreibst: Nicht alles macht für jeden Sinn.
