Gut, wenn ihr so begeistert seid, dann will ich dem nicht im Wege stehen. Ich habe nur meine ernüchterte Sicht der Dinge und die Erfahrungen mit Kunden erzählt.
Dass ein NL-System nicht ganz banal ist, wisst ihr ja auch und so nebenbei mal lässt sich das nicht wieder auf neue Beine stellen.
Ich hatte mal für einen Kunden ein ganz neues und rechtssicheres NL-Sytem für seine Portal programmiert aber das nützt er jetzt auch so gut wie gar nicht mehr.
Und seitdem ist die Rechtslage in Neuland noch schlimmer geworden, besonders wegen dem Datenschutz.
Man muss dem Admin/Kunden volle Verwaltungsmöglichkeiten geben aber wiederum nicht die Möglichkeit, an den "Beweisdaten" etwas zu ändern.
Die Einwilligung zum Newsletter heißt auch nicht automatisch die Einwilligung zum Newsletter-Tracking.
Das heißt, Bilder im Newsletter müsste sowohl vom Server abrufbar sein aber im Falle einer Trackingverweigerung auch direkt eingebunden werden können.
Die Userdaten müssen auch als große Masse verarbeitbar sein, so 150.000 User und mehr.
Das war etwas, was der 4.8. NL gar nicht gut konnte.
Das heißt, wir brauchen eine breite Tabelle mit vielen Merkmalen (Spalten), um User danach filtern zu können und den NL zielgenau steuern zu können.
Massenverarbeitung geht dann schnell und gut, wenn ich direkte Abfragen starten kann und nicht so abstrakt verschachtelte wie bei Contenido sonst üblich. Ich habe ein wenig Erfahrung darin, große Datenmengen irgendwie in den Griff zu bekommen.
Die Sende-Maschine des NL müsste mehr Features bekommen, also mit mehreren IPs senden können (manche haben sowas), nach verschiedenen Datum und zeitversetzt und nach kombinierbaren Kriterien.
Das Problem ist ja, dass der 4.8. NL alles auf einmal raus haut und das klingelt dann regelrecht bei den den Spam-Detektoren.
Auch die Template-Verwaltung müsste besser und einfacher werden.
Es gibt ja oft nicht nur Bedarf an einem Newsletter (typische Vereinsseite) sondern bei Emailmarketing (
http://www.absolit-blog.de/ ) gibt es zielgerichtete Newsletter, also z.B. an bestimmte Gruppen von Kunden (siehe "breite Tabelle" oben).
Ganz wichtig hier wieder die Rechtslage: Es mag sein, dass User sich mal mit der und mal mit einer anderen Email-Adresse in der Datenbank befinden. Wenn der User sich abmeldet, muss er auf allen Adressen abgemeldet sein, und das heißt wiederum, man muss Daten zusammenführen und vergleichen können. Am Ende gibt es für den User eine ID und nicht die Emailadresse als Anker, denn die Email-Adresse ist nur ein Suchkriterium under mehreren, wonach man einen User finden könnte:
http://www.absolit-blog.de/rechtslage/n ... erden.html
Es braucht auch mehrere Möglichkeiten, neue Userdaten (eigentlich Adressaten) in das NL-System einzupflegen, Stichwort Massenverarbeitung. Je komfortabler das für den Admin sein soll, desto mehr programmiert man sich hier die Finger wund.
Copy&Paste sollte Standard sein, also tausende Daten die irgendwoher stammen, einfach markieren, kopieren und einfügen, fertig. Schon werden tausende Adressaten auf einen Schlag* eingelesen.
HTML, störende Leerzeichen und anderer Scheiß wird gelöscht, UTF-8 ist Pflicht.
Aber auch Dateien mit Adressdaten müssen möglich sein, vielleicht sogar in Form von XML und nicht nur CSV.
An Schnittstellen mag ich noch nicht gern denken, das ufert aus.
* wie gehe ich im Kern damit um, dass sehr viele Daten auf einmal in die Datenbank sollen?
"INSERT INTO nl_users VALUES" ist keine gute Idee, wenn es sich um sehr viele Datensätze handelt. Die Datenaufnahme muss vorher schon in kleine Häppchen aufgeteilt werden, weil manche große Hoster wenig Ressourcen an PHP verteilen. Da bleibt dann regelmäßig die Datenbank oder das PHP stehen, oder bearbeitet nur einen Teil der Aufgabe, was zu Datenmüll führt.
Und diese neuen Daten sollten Sicherheitshalber in eine Quarantäne Tabelle gespeichert werden, weil wenn die Haupttabelle mal verpfuscht ist, ist der Schaden groß.
Denn die neuen Daten müssten zuerst mit den bestehenden Daten in den Tabellen abgeglichen werden.
Die Frage wird spätestens bei einer zugemüllten Datenbank auftauchen, nach welchen Kriterien man hätte die Daten vorher vergleichen sollen?
Ist
muller@domain.tld der gleiche wie
mueller@domain.tld oder
muller@anderedomain.tld oder gar muller@domain. de, .com, .eu usw.?
Kann man muller.domain.tld überschreiben oder aktualisieren, wenn es bereits ein
muller@domain.tld in der DB gibt?
Wer hat noch nicht von Tipp- und Schreibfehlern gehört, bei dem statt mueller ein muller oder müller geschrieben wird?
Und schwupps hat man Datenmüll produziert, wenn man einfach neue Daten in die Haupttabelle einliest und Bestandsdaten überschreibt oder ergänzt.
Der Admin braucht eine Übersicht, woran er sehen kann, welche neuen Daten im Zweifel vorhanden sind und welche wirklich neu sind.
Die Übernahme der Daten sollte also kontrolliert erfolgen und bereits mit der Möglichkeit der Kategorisierung und mit Merkmalen versehbar.
Newsletter-Systeme sind nur so gut, wie ihre Datenverwaltung.
Und genau da habe ich gemerkt, dass man sehr schnell seinen eigenen Newsletter-Versand abschießen kann und womöglich tausende Abmahnungen bekommt, wenn der Datenbestand nicht stimmt.
Ich hab schon tausende Daten von Hand durchsucht, weil der 4.8 NL alles das nicht konnte. Der Kunde hats bezahlt und ging dann bald zu einem NL Profi.
Es hört sich alles kompliziert und aufwändig an und ist es auch, aber es ist machbar.
Für die Datenbereinigung kann man Robots einsetzen, die die Datenbank Stück für Stück durcharbeiten und nach Cronjob (hier reicht der Pseudocronjob) gestartet werden.
Man muss nicht alle Daten sofort und gleichzeitig verarbeiten, das kann auch im Hintergrund geschehen, wie der Versand. Das schont Ressourcen und macht selbst größere Tabellen auf kleineren Servern laufbar.
Der Versand sollte auch einen eigenen Robot bekommen, der von außen per echtem Cronjob ansprechbar ist.
Das macht es für Seitenbetreiber mit echtem Cronjob besser, denn die können den Robot dann ansteuern und der Robot holt sich die Aufgabenplanung aus einer Einstellungs-Tabelle aus der DB.
Ich habe damals solche Robots dann teils auch mit Email-Benachrichtigung ausgestattet, wenn er fertig mit der Arbeit war (mit Protokoll).
Aber auf jeden Fall immer mit einem Protokoll, das bequem abrufbar war, um zu sehen was lief und was nicht.
Das kann man in übersichtliche HTML-Dateien packen (doch das geht schnell, viele Millionen mal am Tag ohne stottern) oder kleine Daten in die DB-Tabelle.
Weil fast jeder Kunde hat mich gefragt, tut sich denn da was? Und woran kann ich das sehen?
Bei meinen Eigenprojekten konnte man es sehen und genau verfolgen.
Bei vielen NL-Plugins muss man hoffen, dass die Arbeit erledigt wurde.
Nun, das waren ein Paar Gedanken von mir zu einem brauchbaren NL-System