Als kleiner Nachtrag zu meinem vorherigen Beitrag, ohne weitere Kommentare, hier ein hilfesuchender Ex-Kunde bei frag-einen-anwalt.de:

ich 19 habe betrug bei Hitmeister begangen ich habe accounts erstellt mit erfundenen Daten und scheinkäufe durchgeführt insgesamt beträgt der schaden rund 1500 Euro die Polizei hat bereits eine HD bei mir durchgeführt und einige waren beschlagnahmt.ich bin derzeit Arbeitlos möchte jedoch Ab September eine Schule für Sozialpflege besuchen wofür ich ein Reines Privat führungszeugnis vorlegen muss . Ich bin vorher nie Strafrechtlich in erscheinung Getreten und bin auch Ehrenamtlich im Rettungsdienst Tätig, welche strafe kann mich erwarten.

HD = Hausdurchsuchung. Fett-Markierungen sind von mir. Zu frag-einen-anwalt.de

Unter http://www.hitmeister.de/blog/ werden die gesammelten Mitarbeiter von Hitflip/Hitmeister zu e-Commerce relevanten Themen bloggen. Die ersten zwei Beträge zu Preisvergleichern bzw. Brand PPC sind auch schon online.

Ich werde meine bloggerische Tätigkeit in Zukunft sowohl hier wie auch da entfalten - je nachdem wo es besser reinpasst!

Bei Hitmeister haben wir ja (wie im Artikel zu den Rücklastschriften beschrieben) einige Probleme mit Fraudstern. Wir gehen da sehr rigoros vor, vor kurzem kam es zur zweiten Hausdurchsuchung durch die Polizei bei einem lieben Kunden, der meint mit über 50 Accounts Elektronikartikel bestellen zu müssen, ohne dabei einen Cent in der Tasche zu haben. Aber gut, heute wollte ich mal das 3-D Secure Verfahren etwas beleuchten und warum man es als Händler implementieren sollte.

Chargebacks (Rückbelastungen) sind bei Kreditkarten sehr ärgerlich für den Händler. Der Kunde kann bei CNP (Card Not Present) Transaktionen über das Internet ohne Probleme sagen, er sei für die Buchung nicht verantwortlich und die Zahlung stornieren. Bei Betrugsfällen o.ä. eine gute Sache, nur leider wird dieser Mechanismus von schwarzen Schafen missbraucht. Für den Händler entstehen hohe Kosten. Zum einen die stornierte Transaktion, dann die Gebühr der Kreditkartenfirma für das chargeback (teilweise 10-15 Euro) und nicht zuletzt kommt man, wenn man zu viele Chargebacks hat, bei den Kreditkartenfirmen auf Beobachtungslisten, muss mehr Sicherheiten hinterlegen usw. Jeder Händler möchte also Chargebacks vermeiden.

Die üblichen (Scoring-ähnlichen) Verfahren, wie IP/BIN Check o.ä. sollte eh jeder implementieren bzw. bei seinem Payment-Dienstleister aktivieren, um den gröbsten Missbrauch (russische Kunden mit ägyptischen Kreditkarten usw.) abzufangen.

Als Lösung für Betrüger wurde von MasterCard 3-D Secure entwickelt. Bei Visa nennt sich das ganze Verified by Visa und ist das gleiche in Grün. Mit 3-Ds erhält jeder Kunde eine PIN oder Passphrase, die er zur Bestätigung einer Transaktion auf der Website seiner Bank eingeben muss. Der Kunde wird also vom Händler zu seiner Bank umgeleitet und dann zurück zum Händler.

Erstmal vorneweg: 3-D Secure und Verified by Visa sind ganz schrecklich zu implementieren. Wenn man seinem Entwickler das folgende Prozessdiagramm vorlegt wird dieser vermutlich ernsthaft über eine Karriere als Landwirt nachdenken:

(Quelle: Visa)

Aus 3-DS ergeben sich einige Konsequenzen für alle Beteiligten.

• Wenn ein Händler 3-DS implementiert, gibt es einen sogenannten liability shift, sprich der Händler ist nicht mehr für Chargebacks verantwortlich, auch wenn der Kunde noch gar nicht 3DS nutzt! Den letzten Satz bitte nochmal lesen. Ein Händler, der jetzt 3-DS implementiert, vermeidet also künftig fast alle Rücklastschriften!
• Für den Kunden ändert sich erstmal wenig. Es gibt meines Wissens erst einen Kreditkartenherausgeber in Deutschland (AirPlus), der 3-DS an seine Kunden ausgerollt hat. Ansonsten finde ich ja 3-DS von der Usability her nicht so toll (noch eine PIN), aber bisher ist es eh wurscht, wenn keine Bank das unterstützt. Diese Tatsache führt aber auch dazu, dass man die Implementierung von 3-DS nicht wirklich testen kann, weil es keine Kreditkarten gibt! Wir helfen uns hier mit Prepaid-Karten aus Österreich aus, die 3DS unterstützen.
• I am not a lawyer, aber ich finde in Zukunft wird der Kunde von 3-DS ziemlich gekniffen sein. Er bekommt etwas mehr Sicherheit, kann dafür aber nicht mehr ohne weiteres Chargebacks einreichen, weil er ja seine PIN eingegeben haben soll. Dass 3-D Secure Betrug über z.B. Session-Hijacking nicht verhindert, wird dabei nicht berücksichtigt. Also im Prinzip das gleiche Problem wie bei PINs am Geldautomaten, die laut den Banken unglaublich sicher sind.

Fazit: Für einen Händler, der viel mit Kreditkarten-Chargebacks konfrontiert ist, macht es also durchaus Sinn jetzt schon 3-D Secure zu implementieren, weil die Haftung für Chargebacks größtenteils auf die Banken übergeht. Die Implementierung ist aber wegen der Komplexität der Systeme und den mangelhaften Testmöglichkeiten grausam.

Ein Thema, mit dem ich mich auf Hitmeister viel beschäftige, ist Fraud. Bei mehreren 100.000 Kunden in der Datenbank hat man zwangsläufig auch mit Betrügern und Irren zu tun. Wir bieten die Zahlung per Lastschrift auf eigenes Risiko an und geben damit den Kunden effektiv einen Kurzkredit. Eine zentrale Frage, die wir da bearbeiten, ist wem man wann und bis zu welchem Betrag die Zahlung per Lastschrift erlaubt. Kunden, die kein Geld auf dem Konto haben oder aber die Lastschrift zurückgehen lassen, verursachen bei uns erhebliche wirtschaftliche Schäden.

Gleichzeitig ist es für uns wichtig, möglichst vielen Kunden die Zahlung per Lastschrift zu erlauben. Wenn dem Kunden diese Zahlungsmöglichkeit nicht angezeigt, verdoppelt sich die Abbrecherquote auf der Zahlungsseite. Und das obwohl wir mit Kreditkarte, Paypal, Sofortueberweisung usw. viele andere Methoden anbieten. Die Deutschen lieben Lastschrift (fast so viel wie Rechnung, wie eine interessante Studie im shopbetreiber-blog gezeigt hat), ausblenden kostet also Kunden.

Wer per Lastschrift zahlen kann, wird durch verschiedene Faktoren determiniert:

• Kundenhinstorie
• SCHUFA, Creditreform, Bürgel Scores
• Mikrogeographische Merkmale
• Zusammensetzung des Warenkorbs
• usw. (secret sauce)

Mein Kollege Matthias, unser Leiter Kundenservice, meinte er hätte das Gefühl, dass Nachts wesentlich mehr Fraud betrieben wird, als tagsüber. Die Tageszeit könnte also ein Faktor für die Menge an Rücklastschriften sein. Genauso wie der Wochentag, oder auch der Tag im Monat (wenn am Ende des Monats das Geld knapp wird…)

Ich bin mal hergegangen und habe den Fraud im Tages-, Wochen- und Monatsverlauf analysiert. In den Grafiken unten habe ich die Zahlen normalisiert und dabei den Durchschnitt auf 100 gesetzt. Als Datenbasis dienten alle Lastschriften auf Hitmeister bisher. Die genauen Zahlen sind natürlich streng geheim…

Zuerst zum Wochenverlauf: keine wirklich messbaren Auswirkungen. Schwankungen um die 5% im wochenverlauf würde ich als “random noise” ignorieren bzw. nicht als Faktor benutzen.

Im Monatsverlauf: am Ende des Monats steigt die Rücklastschriftquote schon an. Ich habe den linearen Trend mal eingezeichnet. Die Varianz zwischen den Tagen ist aber so hoch, dass sich das nicht wirklich als Faktor eignet. Eventuell irgendwann in der Zukunft mal, bei Leuten, mit niedrigen SCHUFA-Scores.

Was hingegen interessant ist, ist wie sich der Fraud (also Rücklastschriften) im Tagesverlauf entwickelt.

Nach ca. 01:00 Nachts steigt der Fraud massiv an. Zwischen 01:00 und 08:00 Uhr ist die Rücklastschriftenquote teilweise doppelt so hoch wie tagsüber. Diese Information wird sicherlich in die nächste Iteration unseres Fraud-Prevention-Systems einfliessen.

Ich spiele immer wieder mit dem Gedanken, von dem aktuellen regelbasierten System zu einem Bayesschen Filter zu wechseln. Das Grundproblem bei der Bonitätsprüfung ist letztendlich das gleiche wie beim Spam-Management: wie unterscheide ich ham (gute Kunden) von spam (schlechte Kunden). Der Vorteil von einem Bayesschen Filter: das System lernt die Filterregeln von alleine und erkennt Muster und Tendenzen die wir per Hand nicht finden. Sind GMX-Adressen beliebter bei Betrügern? Gibt es bei Vornamen Häufungen? Was kaufen Betrüger gerne? Der Nachteil: das System wird irgendwo zu einer Blackbox, die von uns nur noch begrenzt nachvollziehbare Entscheidungen fällt. Da braucht man Wege um den alpha und beta Fehler zu messen. Ein interessantes Thema, was mich aber immer wieder auch ärgert. Warum bestellen Leute Sachen, die sich nicht bezahlen können? Bei Nahrungsmittel oder Strom meinetwegen, aber muss jemand der Privatinsolvenz angemeldet hat noch eine PS3 kaufen, die er nicht bezahlen kann?

Seit unserem Umzug herrscht bei Hitflip öfters mal ein längerer Stau vor den Toilettenräumen. Unser 220qm-Büro hatte insgesamt 6 Toiletten, das 400qm-Büro nur 2.

Als Chef weine ich natürlich der Unmenge an Arbeitszeit nach, die meine Kollegen damit verbringen, zu gucken, ob das Klo frei ist. Als Mitarbeiter bin ich öfters frustriert, wenn ich wieder ewig warten muss. Und als (halb-)Techie ist das natürlich eine spannende Herausforderung.

In den letzten Wochen haben wir uns länger mit dem Problem beschäftigt, wie wir uns die Wartezeit sparen können.

Heraus kam der GNUPott. Der GNUPott besteht aus einem kleinen Kästchen mit einem Atmel Prozessor und zwei Photodioden, per USB-Anschluss an einen Server angeschlossen. Dazu gibt es eine kleine C-Software, die den GNUPott anspricht. Der GNUPott wird alle 15 Sekunden abgefragt und meldet, ob das Licht auf dem Klo an ist oder nicht. Das wird sehr hübsch in unserem Wiki dargestellt (siehe Bild). So kann jeder im Büro mit dem Browser nachgucken ob sich das aufstehen lohnt!

Immer im Wiki gucken, ob das Klo gerade frei ist, ist natürlich eine Verbesserung aber noch nicht wirklich praktisch. Das muss schneller gehen! Die Entwicklung von Firefox Extensions ist ja eigentlich sehr einfach. Zack wurde abends der FirePott entwickelt. Der FirePott ist ein Firefox-Plugin, der einem immer den aktuellen Klo-Zustand im Firefox-Browser anzeigt.

Als gute Internet-Bürger haben wir das ganze natürlich direkt unter eine GPL-Lizenz gestellt und inklusive Quellcode und Schaltungsdiagrammen veröffentlicht. Vielleicht hilft es ja noch einem Büro weiter!

Wie jedes Jahr organisieren wir wieder einen kleinen “Stammtisch” zum Thema Internet Marketing. Wobei klein relativ ist, im letzten Jahr kamen über 350 Teilnehmer. Das Konzept bleibt aber gleich: Die Teilnahme ist kostenlos, lediglich eine vorherige Anmeldung ist notwendig. Getränke (Kölsch & Softdrinks) und Fingerfood werden von den Sponsoren des IMK bezahlt. Es gibt keine Vorträge, dafür umso mehr Raum für nette Gespräche.

Zeit: Donnerstag, 04.06.2009, 19h
Ort: RheinEnergie Stadion – 12. Mann, Aachener Str. 999, 50933 Köln

Die kostenlose Anmeldung ist ab dem 30.03.2009 möglich auf der offiziellen Seite des Internet Marketing Köln 2009. Also eventuell schon mal den Termin vormerken! Einige Sponsorenplätze sind auch noch frei.
Die Teilnehmerzahl ist übrigens auf 350 Personen begrenzt und immer sehr schnell ausgebucht.

Auf einer Konferenz habe ich einen Vortrag von dem Usability-Guru Jakob Nielsen gehört. Der brachte mich auf die Idee mit Software und Webcams richtige Usability Tests unserer Seite durchzuführen. Bisher hatten wir das immer eher informell gemacht. Zusätzlich machen wir natürlich jede Menge rein IT-gestütztes statistisches A/B-Testing.

Wir haben zum Relaunch von Hitmeister relativ ausgiebige Usability Tests mit Probanden in unseren Büros durchgeführt. Zum Glück hatte eine neue Mitarbeiterin von mir, Jennifer, während ihres Studiums erste Erfahrungen mit der Materie sammeln können.

Zur Durchführung der Tests haben wir uns nicht einer Agentur anvertraut, sondern selbst die notwendige Ausrüstung gekauft und die Tests selbst durchgeführt. Das kostet vielleicht € 1.500 für die Ausrüstung plus noch mal ein paar hundert Euro für die Probanden.

Die notwendige Ausrüstung:

• das Morae Bundel von Camtasia für ca. € 1.300
• eine Logitech-Webcam für ca. € 100
• und ein alter Laptop wurde als Testrechner umfunktioniert.

Die Probanden haben wir über www.catfire.net gefunden. Dort kann man für € 49 im Monat in einer Datenbank potenzieller Probanden suchen und diese nach einigen Kriterien aussuchen. Wir haben Personen gesucht, die repräsentativ für unsere Zielgruppe sind, sowie einige „Ausreißer“ (besonders jung, besonders alt usw.).

In einem Konferenzraum bei uns wurde für die Dauer der Tests ein kleines Labor eingerichtet. Jennifer saß mit den Teilnehmern im Raum und ist die Fragen durchgegangen. Die Produktmanager, Entwickler und Grafiker konnten sich jederzeit mit dem Morae Observer mit in die Aufnahmen einklinken und den Nutzer sehen und hören. Zusätzlich sieht man den Bildschirm und alle Eingaben. Die Tests wurden am Ende protokolliert und es wurden direkt konkrete Maßnahmen abgeleitet.

Wir haben während den letzten 8 Wochen des Entwicklungsprozesses jeden Freitag 3-4 Probanden da gehabt, um die Seite zu testen. Während am Anfang eher generelle Aufgaben getestet wurden, ging es in den späteren Tests immer tiefer ins Detail. Alle Produktmanager haben Aufgaben an Jennifer herangetragen. Die meisten Bereiche, wo unterschiedliche Meinungen zur besten Umsetzung herrschten, wurden direkt getestet. Genauso auch größere Änderungen. Die Ergebnisse der Tests sind dabei direkt in den Entwicklungsprozess wieder eingeflossen und wurden – wo möglich – direkt noch mal getestet.

Dieses Vorgehen hat bei uns extrem gut funktioniert. Die Tests ist wesentlich „runder“ rausgekommen als jemals ein Relaunch zuvor. Die Konversionsrate ist gestiegen, die Supportanfragen sind runter und alle sind glücklich.

Eine Anmerkung noch: wir waren unsicher, in wie weit man Testern unfertige Seiten zeigen kann. Das war überhaupt kein Problem. Fehlende Bilder, kaputte Bereiche usw. wurden geflissentlich ignoriert. Man kann also sehr früh testen, die Tester sind sehr tolerant!

Ich kann jedem Projektleiter, der noch 2-3k in seinem Finanzkrisen-strapazierten-Budget übrig hat, sich die Ausrüstung zu kaufen und in diese Kamera-Tests zu investieren. Die Ergebnisse sind wirklich extrem hilfreich.

P.S. Bevor jemand fragt: Nein dies ist kein gekaufter Beitrag von TechSmith, ich bin begeistert!

Wenn eine Webseite anfängt viele Daten auszuliefern ist es irgendwann sinnvoll diese Tätigkeit einem spezialisierten Anbieter zu überlassen. Betreiber von Content Delivery Networks (CDN) stellen in Rechenzentren auf der ganzen Welt Server auf und versprechen der Webseite, den Content von einem Server auszuliefern, der möglichst nahe beim Kunden steht. Der Betreiber der Webseite verspricht sich hiervon 2 Vorteile: 1) der Kunde bekommt seine Daten schneller und 2) der Betreiber der Website braucht selber keine großen Kapazitäten vorhalten, sondern überlässt die Skalierung dem CDN. Wie groß der Effekt von Punkt 1 ist, hat Tom Leighton von Akami kürzlich in der ACM-Queue vorgestellt:

Die kürzeren Paket-Laufzeiten sind für Websites wie unsere, die fast ausschliesslich Kunden in Deutschland oder Europa haben, irrelevant. Wegen Punkt 2, der Skalierung, hatte ich mir mal CDNs angeschaut aber mich dann doch dagegen entschieden. Die Traffic-Menge ist noch nicht so signifikant.

Amazon hat mit CloudFront einen Dienst vorgestellt, der einem erlaubt auf S3 eine “Optimierungsschicht” vorzulegen. S3 liefert die Daten von da aus, wo der Betreiber sie hochgeladen hat. CloudFront nimmt diese Daten und liefert sie von da aus, wo der Kunde sitzt.

Ich habe mir mal die Preise von Amazon CloudFront genauer angeschaut und sie mit einem anderen CDN vergleichen. Welches darf ich leider nicht sagen, es war aber eher ein mittelpreisiges. Nennen wir es einfach X-CDN. Was mir dabei aufgefallen ist: CloudFront ist wesentlich günstiger als X-CDN für große Dateien. Aber für kleine Dateien ist es ziemlich teuer!

So viel kostet die Ausliferung für 1.000.000 Abfragen für einige typische Dateigrößen:

Die Preisliste bei X-CDN war unverhandelt, das heisst da geht bestimmt auch noch was.

Mein Fazit: Amazon CloudFront ist gar nicht so günstig, wie oft angenommen wird (mehr dazu siehe Eckenfels IT-Blog oder Blogaddict. Netzwertig hatte die Preise schon korrekt eingeschätzt). Bevor man blind zu Amazon CloudFront rennt sollte man durchrechnen, ob sich ein normales CDN wie Akamai, Panther Express oder Limelight sich nicht doch rechnet und dort entsprechende Angebote einholen. Der Setup ist m.E. dort auch oft einfacher, da man nicht über S3 gehen muss und die Gebühren sind - wie man sieht - je nach Nutzungsverhalten nicht unbedingt höher.

Nachtrag Wenn ein Anbieter von CDNs hier seine Preise offen legen möchte, trage ich das gerne nach!

Wir haben vor kurzem die ersten Hitmeister Optimierungs-Tage (HOT 1 - Abkürzungen sind ganz wichtig) durchgeführt. Ich wollte hier mal von unseren Erfahrungen berichten.

Ziel der HOT: Jedes Software-Projekt hat Code, der Liebe braucht. Das sind Stellen die undokumentiert sind, selten getestet, trotzdem wichtig und zentral, für die sich alle ein bisschen schämen und wo keiner ran will. Die sollte “man” mal aufräumen. Je länger diese Problemstellen ignoriert werden, desto größer werden sie. Eine gute Analogie sind Schulden, die immer weiter anwachsen. Im Englischen nennt man das auch technical debt oder karmic debt. Wir wollten bei Hitmeister mal was für unser Karma tun. Das Ziel war es den Code aufzuräumen, zu dokumentieren, Tests zu schreiben und zu refactoren. Also lauter Sachen erledigen, die im Tagesgeschäft öfters liegen bleiben. Und das in einem Sprint-artigen Modus.

Vorgehen

• Wir haben uns für HOT 1 zwei Tage Zeit genommen. Innerhalb der Firma wurde vorher kommuniziert, dass die Technik an den zwei Tagen nur für absolute Notfälle zur Verfügung steht und ansonsten nicht ansprechbar ist.
• Im Vorfeld der HOT wurden in einem Wiki-Dokument Ideen gesammelt, was man angehen könnte. Zu jeder Idee wurden die erwarteten Auswirkungen dazu geschrieben.
• Am Vormittag des ersten Tages wurden die Ideen diskutiert und evaluiert. Es haben sich Zweierteams gebildet, die die verschiedenen Baustellen angegangen sind. Dabei wurde nicht jede Aufgabe zu zweit gemacht. Manche Aufgaben wurden wirklich im pair-programming-Stil gelöst, andere waren eher do-and-review.
• An den folgenden 1,5 Tagen haben die Teams dann - soweit möglich - die Aufgaben gelöst und umgesetzt. Hierbei gab es recht viel Diskussionsbedarf.
• Nach den HOT wurden dann die Ergebnisse besprochen und ein Fazit gezogen.
• Einige Arbeiten sind leider nicht fertig geworden in den zwei Tagen, das hat sich dann noch etwas fortgezogen.

Ergebnis: Wir haben in den zwei Tagen über 5.000 Zeilen Code gelöscht (echten Code, keine Libraries), ca. 200 Todos entfernt und unzählige Tests und Kommentare geschrieben. Nach ersten Tests sollte die Menge an SQL-Abfragen um etwa 20% sinken, die memcached-Aufrufe um etwa 30%.

Fazit: Die ersten Hitmeister Optimierungs Tage waren sehr erfolgreich. Wenn Anfang Dezember der Code live geht sollte das die Seitenladezeit und die Serverlast etwas reduziert. Was aber wesentlich wichtiger ist, ist dass der Code wieder sauberer, lesbarer und robuster geworden ist. Ein zusätzlicher Vorteil der HOT war, dass alle Entwickler viel “fremden” Code gelesen haben und so ein besseres Verständnis der Plattform bekommen haben. Weitere Ergebnisse:

• Die Arbeit war teilweise zu viel, teilweise auch zu wenig. Die Aufgaben waren nicht so aufgeteilt, dass alle in 2 Tagen fertig wurden bzw. auch 2 Tage gebraucht haben. Das sollte besser eingeteilt werden.
• Die Arbeit in Teams, im Sprintmodus, ist sehr gut angekommen und hat gut funktioniert. In Zukunft macht dieses Vorgehen für abgeschlossene Komponenten viel Sinn.
• Ein grosser Batzen Arbeit im ersten HOT war die Vorsortierung der TODOs im Code. Beim nächsten HOT wird da dann erst aufgeräumt.
• 100% frei von Tagesgeschäft waren die Tage nicht, aber es war nur “unaufschiebbares”. Unsere Firma kann mal ein paar Stunden ohne Technik laufen…

In Zukunft werden wir ca. einmal im Monat einen HOT machen, der sich dann aber stärker auf wirkliches refactoring konzentrieren soll. Im zweiten HOT (oder HRT) sollen dann die vorsortierten Todos durchgegangen werden. Ich bin von unseren Erfahrungen sehr angetan, und würde jedem Team raten so etwas mal zu probieren.

Frontend Performance-Optimierung ist ja derzeit ein grosses Thema, weil es viel bringt (Hintergrundinfos: hier, hier, hier). Die letzten paar ms Ladezeit auf Serverseite rauszukitzeln wird disproportional teuer. Ein Grossteil der Ladezeit entsteht eh durch Browser-Requests und Ladezeiten, die kann man angehen. Dazu gibt es aber genug Literatur.

Oft werden Performance-Optimierungen durch Werbetags zunichte gemacht, die oben in der Seite eingebaut werden. Das sind meistens kleine Stückchen JavaScript, die von einem Vermarkter kommen. Diese rufen einen Adserver auf, der wiederum andere JavaScripts einblendet, zum Beispiel von einem Werbekunden, der wiederum ein IFRAME schreibt. Oft werden da 4-6 Requests gemacht, nur um ein Bild anzuzeigen. Dazu kommen Targeting Skripte von nugg.ad oder wunderloop sowie Tracking-Pixel der IVW und AGOF.

Das schlimme daran: auf einmal bestimmt die Latenz von fremden Servern die Ladezeit der eigenen Seite. Die eigenen Server können noch so optimiert sein, wenn die Server von einem Werbetreibenden in die Knie gehen ist die eigene Seite langsam oder platt. Und durch die Netzwerke ist es gar nicht so einfach rauszufinden, wer eigentlich gerade verantwortlich ist für die schlechte Performance von srv42.freeadserver4you.net.

Auf Hitflip hatten wir Fälle, wo der Seitenaufbau um 15 Sekunden verzögert wurde durch schlechte AdTags. Da hilft dann keine Frontendoptimierung. Und manchmal klappen die dann gar nicht, wie heute morgen auf Spiegel Online:

Was kann man dagegen tun?

• Schmerzensgrenzen definieren. Was für eine Verzögerung der Seite bin ich bereit zu akzeptieren?
• Beim Vermarkter das Thema ansprechen. Gerne hier auf Google AdSense verweisen, mit denen hatten wir noch nie Probleme hinsichtlich Ladezeit (Ormigo ist da übrigens auch top). Wenn ich bei Google € 2 eCPM bekomme und bei einem Vermarketer € 2,50 kann es besser sein die € 2 zu nehmen und eine schnelle Seite haben. Für mich ist die schlechte Technik ein deutlicher Wettbewerbsnachteil bei einigen Vermarktern.
• Unbedingt einen grossen roten Knopf im eigenen Backoffice bauen, der sofort alle Werbung von der Seite entfernt. Es bringt nichts, wenn man erst in irgendwelchen Templates rumprökeln und dann ein Update fahren, um ein langsames Banner zu entfernen. Sobald ein Banner Performanceprobleme bringt, muss es raus. Und da man das oft nicht Banner-spezifisch steuern kann, braucht man einen grossen roten Knopf.
• Es sollte beim Vermarkter einen Ansprechpartner für solche Probleme geben. Das muss schnell gehen und kann nicht über das Account Management gehen.
• Wenn möglich mit dem Vermarkter bezüglich Einbindung verhandeln. Muss es der dicke AdTag aus dem Jahre 1998 sein, der 12 redirects macht und noch 4 Tracker lädt, oder geht es nicht auch etwas schlanker?
• Und zuletzt, wenn das Design es zulässt: mit CSS und JS Tricks die Banner als letztes laden, auch wenn die oben sind. Dann gehen zwar Werbeeinnahmen flöten, aber die Nutzer werden es einem Danken.

Es wäre eigentlich mal cool Messungen hinsichtlich der Performance von verschiedenen Vermarktern zu machen und ein Ranking zu erstellen. Wenn mir mal sehr langweilig ist, gehe ich das an… Eigentlich ist ja Vermarktung nicht unser Geschäft.