Mythen

Oft habe ich jetzt schon oft gehört, dass ein Montag oder Dienstag ideal wäre oder dass man niemals an einen Wochenende senden sollte. Andere wiederum senden ihren Newsletter immer Freitags raus.

Ich kann nur sagen, dass es keine Standard Regeln gibt. Man darf auch nicht davon ausgehen was man als logisch erachtet.

Man muss den besten Zeitpunkt anhand seiner Zielgruppe ermitteln und durch statistische Auswertungen und Probieren das Datum finden.

1. Zugriffsstatistiken auswerten

Ein Kunde von mir sendete seinen Newsletter jahrelang immer Freitags, da er meinte die Empfänger hätten am Wochenende mehr Zeit sich die Themen anzuschauen. Als ich mir die Webstatistik der Seite ein mal genauer anschaute viel mir auf das die betroffene Webseite am Wochenende nur sehr gering besucht wurde. Als wir dann den Newsletter am Wochenanfang sendeten, kam die doppelte Resonanz.

Hierbei wurde das beste Ergebnis anhand von einer Analyse der Zugriffsstatistik gefunden.

2. Probieren

Bei einem Verein, bei dem es um ein Thema geht das nicht beruflicher Natur geht, hat es sich ergeben das ein Newsletter am Wochenende mehr als das dreifache an Resonanz ergab.

Hier wurde das beste Ergebnis durch Probieren gefunden.

Uhrzeit

Auch die Uhrzeit ist entscheidend. Es macht großen Unterschied ob man den Newsletter Morgen, Mittags oder Abends versendet. Genau wie beim Wochentag muss man sich hier an seiner Zielgruppe orientieren.

Beispielsweise kann es sein das nach einen Login verschiedene Dinge geprüft werden müssen. Zusätzlich sollen vielleicht noch Aktionen geloggt werden.

Wenn man jedesmal den Code für den Login erweitern würde, dann hätte man innerhalb kürzester Zeit eine riesige Klasse mit schwer wartbaren Code.

Bei dem Observer Pattern gibt eine Anwendung nur bekannt das ein bestimmtes Ereignis (Event) stattgefunden hat. Andere Programmteile können sich von außen an den EventDispatcher anmelden und werden dann von diesen benachrichtigt wenn das Ereignis eintritt.

In der PHP Bibliothek PEAR gibt es dieses Pattern schon fertig programmiert: Event_Dispatcher.

1. Handler erstellen

Als Erstes benötigt man einen Handler der das Ereignis verarbeitet.

class Handler{
/**
* @param    Event_Notification
*/
public function getOnlogin(Event_Notification $oEvent_Notification){
$oValueObjects_User = $oEvent_Notification->getNotificationObject();
$aInfos = $oEvent_Notification->getNotificationInfo();
// mach irgendetwas
}
}

2. Handler registrieren

Jetzt muss der Handler beim Event Dispatcher registriert werden.

require_once 'Event/Dispatcher.php';
$oEvent_Dispatcher = Event_Dispatcher::getInstance();
$oEvent_Dispatcher->addObserver(array(new Handler(),'onLogin'),'onLogin');

Der erste Parameter ist ein PHP Callback. Als dritten Parameter kann man von eingrenzen von welche Objekten dieser Event geworfen werden darf.

3. Ereignis auslösen

Jetzt muss das Ereignis noch ausgelöst werden.

require_once 'Event/Dispatcher.php';
Event_Dispatcher::getInstance()->post($this,'onLogin',$aInfo);

Im dritten Parameter kann man noch Informationen in Form eines Array übergeben.

Nutzen

Veränderung vermeiden

Der Nutzen in dem Pattern liegt darin das man die Anwendung nicht mehr nachträglich anpassen muss um Erweiterungen einzubauen.

Verantwortlichkeiten sauber trennen

Die Verantworltichkeit der Kompontenten bleibt frei von Nebensächlichkeiten. Zum Beispiel kümmert sich dann die Login Komponente nur um das Login und sonst nichts. Alles andere wird über die Events abgearbeitet.

Fazit

Ich verwende dieses Pattern sehr viel und es macht die Anwendung wartbarer und den Einbau von Erweiterungen einfacher. In anderen Sprachen wie .NET ist das Pattern bereits in die Sprache eingebaut.

Ich habe solche Tools jetzt schon in mehreren Projekten eingebaut. Ein Unternehmensberater hat sogar einem Kunden empfohlen so ein Tool zu implementieren.

Bei allen Projekte war der finanzielle Anzreiz für den Empfehlenden hoch. Bei einem Online-Shop bekommt der Kunde einen Gutschein mit 50% Ermäßigung. Bei einer Recruiting Firma erhält der Kunde mindestens einen 10 Euro Gutschein und wenn es zu einen Projekteinsatz kommt bekommt er noch mal 300 Euro.

Der Aufwand für so ein Programm ist mehr als auch zu Anfang dachte. Es ist relativ viel Logik zu implementieren. Der Prozess läuft asynchron und muss richtig getrackt werden. Zusätzlich benötigt man in den meisten Fällen noch ein Gutschein System oder man muss ein bestehendes System ansprechen.

Die Erwartungen waren hoch und wurden dann immer eintäuscht da die Nachfrage sehr gering ist. Es scheint kaum Nutzer zu geben die sich die Mühe machen wollen und Empfehlungen zu schreiben.

In allen Projekten war bereits ein großer Kundenstamm da. Ich denke bei neuen Projekten kann es Sinn machen, aber bei älteren Projekten entspricht der Aufwand nicht den Nutzen den so ein Tool bietet.