Shopping. Commerce.

augmented_reality_iphone_plantronics

In-store Augmented Reality mit neuer IBM App. Ja, es geht nicht um E-Commerce, Multi- oder Omni-Channel oder sonstwie um Schlagwörter, sondern um Shopping und Commerce, Einkaufen und Verkaufen. Und das Erlebnis dazu. Es wird Zeit ohne Grenzen von On- und … Weiterlesen

Wenn Storytelling versagt. Der Problemfall Saturn.

Storytelling, Teil III

Schon seit längerer Zeit sind insbesondere große Unternehmen daran, ihre digitalen Inhalte und deren strategische Strukturierung aufzuwerten und zu professionalisieren. Häufig wird als kommunikativer Rahmen der Ansatz des „Storytelling“ genutzt, jedoch oft zu kurz gedacht.

Im dritten Teil der Serie geht es darum, Schwachstellen von Stories zu erkennen- am Beispiel der Elektronik-Fachmarktkette Saturn.

Um im vorab besprochenen Beispiel zu bleiben: Saturn hat keine ausdefinierte Markenstory, versucht aber über sehr scharfe Informationsspitzen (abgefeuert durch Claims) Nuancen von leicht dechiffrierbaren Geschichten zu erzählen.

Der aktuelle Claim „Soo! muss Technik“ ist Nachfolger vom weit bekannteren und zur damaligen Zeit stark kritisierten „Geiz ist geil“. „Soo! muss Technik“ ist als Informationsspitze lanciert, um indifferenten Kunden zu suggerieren: bei Saturn bist Du immer richtig, sofern Du Dich für Technik begeistern kannst. Saturn tut alles dafür, um Technik ins rechte Licht zu rücken.

Im Wochenmagazin „DIE ZEIT“ wurde von einer „Nullaussage“ und einem „Luftloch der Kommunikation“ gesprochen, was etwas übertrieben ist, aber inhaltlich auch nicht komplett falsch.

Indirekt betont der Claim die Wertschätzung des Retailmarktes gegenüber digitalen Kanälen, da die lokalen Möglichkeiten, Technik zu präsentieren, aus Saturn-Sicht besser geeignet sind, Kunden zu überzeugen. Auch online wären Showrooms etc. möglich, werden jedoch nicht ausreichend bespielt- der beratende Effekt des Servicemitarbeiters fehlt und wird digital nicht ersetzt. Ab hier bricht der Ansatz der Markenstory („immer und überall richtig“), u.a. weswegen der digitale Abverkauf bei der Kette auch so stottert.

Am Beispiel sieht man, wie schwer es ist, eine gute Story zu lancieren und wie wenig Sinn es macht, Storytelling an Werbebotschaften auszurichten (statt umgekehrt). Saturn stand beim Wechsel des Claims  vor der schwierigen Situation, „Geiz ist geil“ abzulösen.

Aus meiner Sicht entstand jedoch die Notwendigkeit weniger aus dem offenbar zu beobachtenden Kaufverhalten („Qualität vor Quantität“), sondern aus dem Schmerz heraus, die dahinterliegende Story nicht mehr authentisch erzählen zu können. Zu häufig waren Personen mit mobilen Endgeräten im Laden, die die Preise im Lokal mit Online-Shops verglichen und dabei die geringe (preisliche) Wettbewerbsfähigkeit festgestellt haben- ein No-go, wenn man sich als Marke den besonders Geizigen verspricht.

Der folgende vierte Teil der Storytelling-Serie widmet sich erfolgreichen Beispielen von Storytelling-Ansätzen.

Mentale Verfügbarkeitssets im Storytelling

Storytelling, Teil  II

Schon seit längerer Zeit sind insbesondere große Unternehmen daran, ihre digitalen Inhalte und deren strategische Strukturierung aufzuwerten und zu professionalisieren. Häufig wird als kommunikativer Rahmen der Ansatz des „Storytelling“ genutzt, jedoch oft zu kurz gedacht. Im ersten Artikel der Storytelling-Serie ging es um die Frage, wieso Geschichten Umsatz machen

Im zweiten Teil der Storytelling-Serie wird besprochen, wie sich Nutzer an Geschichten erinnern und was dies mit e-Commerce zu tun hat.

Wiedererkennung oder: Warum Saturn am Sonntag nur Markenprodukte verkauft.

Menschen greifen besonders häufig dann auf Erfahrungsmuster zurück, wenn sie schnelle Entscheidungen treffen müssen. Auf dieser Basis sollten insbesondere große Marken ihre Kunden häufig unter Stress versetzen: im e-Commerce wird dies gerne über die Limitierung von Angeboten gelöst, beispielsweise hinsichtlich Zeit und Verfügbarkeit der Ware. Besonders gut dürfte dies funktionieren, wenn einerseits der Shop, andererseits das verkaufte Produkt eine hohe Markenbekanntheit haben.

Die Metro-Group Tochter „Saturn“-bekannt durch ihre hoch aggressiven Claims- verkauft am  „Super Sunday“ nahezu ausschließlich stark bekannte Markenprodukte wie das Apple iPad und setzt den Kunden durch die zeitliche und logistische Begrenzung doppelt unter Stress. Das kombiniert mehrere verkaufsfördernde Aktivitäten; die Produkte sollten am jeweiligen Tag eine besonders hohe Konversionsrate aufweisen. Übrigens: auch hier kann noch optimiert werden. Hat der Nutzer noch die Möglichkeit des Quick-Checkouts (wie beispielsweise bei Amazon), ist dem Shop noch mehr geholfen. Die Markenstory-sowohl von Saturn als auch beispielsweise von Apple- hilft in der Theorie dabei, die Shopping-Journey recht unterbrechungsfrei zu gestalten. Je konsistenter die Gesamtbotschaft ist, desto leichter fällt dem Kunden der Kauf- der frontopolare Kortex, der für eine Vielzahl an ökonomischen Entscheidungen im menschlichen Gehirn verantwortlich ist, wird nur kurz beansprucht, da er auf Erfahrungsmuster zurückgreifen kann.

Wiedergabe. Wieso „Virales Marketing“ oft Geschichten schreibt.

Oftmals ist es schwierig, objektiv Produkte und deren Merkmale zu differenzieren. So kann man bereits für 0,49 Euro beim Einzelhandel-Discounter Aldi den „Bavaria Senf“ kaufen, der sich nur unwesentlich vom originären Markenprodukt des Herstellers Develey unterscheiden dürfte, der diesen selbst produziert. Der Markensenf kostet jedoch ca. 81% mehr als das Discounter-Produkt. Der größte Unterschied zwischen den beiden Erzeugnissen dürfte im Branding-Effekt liegen, der im Wesentlichen an die Unternehmens-Heritage von Develey geknüpft ist (einziger Senfhersteller in Bayern), für den die Konsumenten den Aufpreis offenbar gerne bezahlen. Es kommt also auch hier wieder im Kern auf die Geschichte an.

Eine gute Geschichte bleibt im Gedächtnis und kann in unterschiedlichen Konstellationen reproduziert und wiedergegeben werden. Dies nutzen heute Unternehmen, um sich mit Hilfe der Nutzer ins Gespräch zu bringen und sich in Konversationen zu halten. Adaptiert spricht man von viralen Effekten, sofern sich am Schema des initialen Informationstriggers und der Weiterverbreitung in one to many-Konversationen nichts ändert.

Der folgende dritte Teil der Serie widmet sich der Frage, wann Storytelling versagt am Beispiel der Elektronikkette Saturn.

Wie Google Traffic-Ströme beeinflusst

Wie Google Traffic-Ströme beeinflusst

Seine bedeutende Marktstellung verdankt Google der nach wie vor hohen Nutzerakzeptanz seines zentralen Services, der Google-Suche. Höchstes Gebot beim US-Suchmaschinenriesen ist daher die weitere Verbesserung und Entwicklung von neuartigen Suchergebnissen – mit immer weitreichenderen Folgen für globale Trafficströme. Convenience Search … Weiterlesen

Content-Migration und die Schnittstellen

Migriert man die Daten von einem CMS in ein Neues, so ist aufgrund des Datenumfangs häufig eine automatisierte Migration unumgänglich. Es stellen sich dabei jedoch die Fragen:

  • Welche Schnittstellen sind für diesen Migrationsprozess zu verwenden?
  • Was kann überhaupt automatisiert migriert werden?

Die Abbildung zeigt, welche Metamodellebenen dabei zu betrachten sind. Man beachte, dass nur für die Inhalte eine automatisierte Content-Migration möglich ist, während die Funktionalitäten entweder durch das neue Produkt oder dessen Anpassungen und Erweiterungen abgedeckt werden müssen.

Metamodellebenen einer CMS-Lösung

Metamodellebenen einer CMS-Lösung

Die Content-Migration setzt sich aus Datenexport, Transformation und Datenimport zusammen. Hierbei ist die Wahl der geeigneten Export- und Importschnittstellen entscheidend. Üblicherweise stehen folgende zur Auswahl

  • Schnittstellen des CMS Produkts
  • APIs der darunterliegenden Frameworks
  • Direktzugriff auf die Datenbank

Die Schnittstellen des CMS Produkts eignen sich meist dann, wenn auf eine höhere Version des bereits verwendeten CMS Produkts migriert werden soll, da Hersteller, im eigenen Interesse, Unterstützung anbieten. Im Gegensatz dazu ist der Direktzugriff auf die Datenbank zwar der mächtigste Ansatz, da er alle Daten verfügbar macht, aber auch der aufwändigste, denn das Verständnis der Semantik und Relationen muss sorgfältig aufgebaut werden. Insbesondere Meta-Attribute müssen behandelt werden. Ein Teil dieser Arbeit kann evtl. entfallen, wenn man APIs von verwendeten Frameworks nutzen kann. Beim Datenimport ist zu beachten, dass APIs und Schnittstellen des CMS Produkts mehr Validierung und Konsistenzprüfungen bieten, die dabei helfen, Fehler in den gelieferten Daten aufzuspüren und die referentielle Integrität sicherzustellen. Oftmals lehnen Hersteller sogar die Verantwortung oder Support ab, wenn für den Import nicht die Schnittstellen des CMS Produkts verwendet werden, da eben genau diese Datenqualität nach den Regeln des Herstellers nicht sichergestellt ist.

Die Entscheidung für die zu verwendenden Schnittstellen muss für jede Lösung individuell getroffen werden. Die Schnittstellen des jeweiligen CMS-Produkts sind jedoch zu bevorzugen. Nur in begründeten Fällen sollte man davon abweichen.

Weitere Artikel dieser Blog-Serie

Länderzuordnung bei der Google-Suche: Geotargeting

In Projekten immer wieder gefragt: Wie entscheidet Google bei der Einschränkung der Suche nach Land ob ein Inhalt in der Trefferliste erscheint? Hier vorab ein Beispiel:

i) Suche nach „facebook blogger star“ auf www.google.de (ohne Einschränkung)

2655-facebook-blogger-star-DEohne.jpg

ii) Suche nach „facebook blogger star“ auf www.google.de (Einschränkung: Seiten aus Deutschland)

2656-facebook-blogger-star-DEmit.jpg

iii) Suche nach „facebook blogger star“ auf www.google.ch (ohne Einschränkung)

2657-facebook-blogger-star-CHohne.jpg

iv) Suche nach „facebook blogger star“ auf www.google.ch (Einschränkung: Seiten aus der Schweiz)

2658-facebook-blogger-star-CHmit.jpg

Hier meine Interpretation dazu, wie Google die Zuordnung erledigt:

– Macht der User keine Einschränkung, so zeigt Google die Treffer abhängig von der geschätzten Relevanz, unabhängig davon auf welcher Länderdomäne von Google gesucht wird. Hier gelten die „normalen“ Optimierungsregeln (unser Archiv mit SEO- und SEM-Tipps).

– Macht der User einer Einschränkung auf ein Land, so werden die Treffer (resp. die durch Google erschlossene Kollektion) genau einem Land zugeordnet. Dafür wird nicht der reale Traffic genutzt (denn wir hätten mehr Besucher aus Deutschland als aus der Schweiz) aber eine Heuristik welche u.a. den Domänennamen und den Standort des Server signifikant in die Gewichtung einfliessen lässt.

Und nun zum Titel es Posts: Die explizite Zuordnung eines Angebotes zu einem Länderfilter bei der Google-Suche. Der Kern der Information stammt dabei aus einem Help-Artikel bei Google.

1) Es gibt nur zwei Möglichkeiten die Länderzuordnung zu machen entweder für eine ganze Domäne oder für einen vollständigen Teilbaum der URL-Struktur (der Informationsarchitektur). Das Länderkonzept muss dies vorgehen.

a. Möglichkeit „Domäne“

2661-Sika-Laender.jpg

PS: Eine andere (schönere) Variante wären eigene Länderdomänen wie www.sika.de oder www.sika.fr doch diese müssen vorhanden sein und erzeugen zusätzliche Kosten.

b. Möglichkeit „vollständiger Teilbaum“

2660-Phonak-Laender.jpg

2) Je nach Variante muss nun jede Domäne resp. jeder Teilbaum in den Webmaster-Tools von Google als eigene Site angelegt werden

3) In den Webmaster-Tools kann nun die Zuordnung zu (nur) einem Land gemacht werden

2659-Webmaster_Tools-Geotargeting.jpg

Google im eigenen Server-Raum

Ich bin gerade auf ein witziges (Amateur-)Werbevideo von Google gestossen. Eine Hauptrolle darin spielt eine imposante Ansammlung von 34 GSA GB-9009 (die aber offensichtlich nicht laufen, sonst wär’s wohl nicht so ruhig im Video).

2350-google-thumb-500x281-2349.png

Eine Box kann 30 Millionen Dokumente indexieren, mal 34 gibt etwas mehr als eine Milliarde. Das ist in etwa sowiel, wie google.com im Jahr 2000 im Index hatte. Das ist zwar schon 10 Jahre her, aber wenn man bedenkt, dass man dafür heute keine Schar Informatiker mehr braucht und das relativ einfach im Keller installieren kann, finde ich das schon noch ziemlich beeindruckend.

Teile einer Seite aus dem Google-Index fernhalten

Drüben auf dem Liip-Blog fragt Chregu nach, wie Teile einer Webseite aus dem Google-Index ferngehalten werden sollen. Auf einer Community-Seite sollen/werden Usernamen angezeigt, die nicht über den Google-Index gefunden werden sollen. Der Rest der Seite aber schon. Als Vorschläge bietet Chregu die folgenden an:

i) Cloaking
ii) Usernamen als Bilder
iii) Usernamen via JavaScript (nach dem Pageload) reingeschrieben
iv) eine Mischung von ii und iii

Meine Gedanken.

1) Nur Google oder alle Suchmaschinen

Sollen die Usernamen aus allen Suchmaschinen-Indices ferngehalten werden? Wenn ja, so kommen nur die Bilder also ii) in Frage.

Dies, da sich weniger nette Crawler als Google mit unterschiedlichsten User Agents melden. Mit den Ziel deren Ausbeute so gross wie möglich zu halten, wird JavaScript zunehmen auch ausgeführt (so auch bei Google). Bei JavaScript könnte es damit auf ein „Wettrüsten“ rauslaufen. Ausserdem kenne ich (noch) keine öffentliche / freundlichen Suchmaschine, die OCR macht und blinde Nutzer haben JavaScript NICHT deaktiviert.

2) Cloaking

Cloaking — die Auslieferung einer unterschiedlichen Seite in Abhängigkeit des User Agents — ist grundsätzlich möglich und wir (wurde? Urban?) auch von search.ch genutzt. Für Google ist das eine mögliche Lösung und wird dort auch toleriert (auch wenn in der Tendenz „bad practice“). Aber für alle Suchmaschinen ist dies nicht 100% zuverlässig (da teilweise mit dem User Agent gespielt wird).

3) googleoff/googleon Tags

Ich kenne da noch ein paar Tags die es erlauben, Seiteninhalte von der Indexierung durch eine Google Search Appliance auszuschliessen. Dies werden aber auch von Google public (ohne Garantie der Dauerhaftigkeit) unterstützt. Die folgenden Tags (als HTML Kommentar eingepackt) erlauben es, Seitenteile von der Indexierung auszuschliessen.

3a) index Tag

Der mit googleon/off: index eingeschlossene Text wird nicht indexiert. In dem Fall landen Liip und Agile im Index, Chregu aber nicht.

 Liip <!--googleoff: index--> Chregu <!--googleon: index--> Agile

3b) anchor Tag

Der durch googleon/off: anchor eingeschlossene Textanker wird der Zielseite nicht als Suchbegriff angerechnet. Der Link auf http://blog.namics.com würde bei einer Suche nicht mit Liip assoziert.

 <!--googleoff: anchor--> <a href=http://blog.namics.com> Liip </a> <!--googleon: anchor-->

3c) snippet Tag

Der googleon/off: snippet eingeschlossene Text wird nicht zur Erzeugung des Trefferzitats genutzt.

 <!--googleoff: snippet--> Ich bin nicht zitatwürdig <!--googleon: snippet-->

3d) all Tag

Und googleon/off: all schliesst alle der drei oben genannten Ausschlüsse index, anchor und snippet ein.

 <!--googleoff: all--> Ich nicht <!--googleon: all>

Einen schönen Abend, viel Spass beim Ausschliessen ;-) und die Diskussion wegen dem Zugang für Menschen mit Behinderungen braucht ein bisschen mehr Zeit.

Update
– In einem Kommentar des Liip-Blogs hat es einen Link auf die Yahoo-Variante der Content-Kennzeichnung mit Class-Attributen.
– Zudem der (für freundliche Spider funktionierende) Vorschlag von Hannes, die Namen als iFrames undeiner für Suchmaschinen „gesperrten“ Domäne einzubinden.

One-Page-App mit viel Javascript

Die Performance im Frontend (View) ist wichtig. Bei einer Reaktionszeit von einer Sekunde hat der User noch das Gefühl, die Website reagiere unmittelbar. Die Aufmerksamkeit des Users sinkt mit der Sekunde, die dazu kommt.

Wie man die Performance bei AJAX-lastigen Website verbessern kann, zeige ich hier am Beispiel auf:

One-Page-App Beispiel

Beim Medela Locationfinder handelt es sich um eine one-page-app. One- oder Single-page-apps sind Webanwendungen, welche ohne Page Reloads (Seitenwechsel) auskommen und deren Anzeige nur mittels Javascript und DOM-Eingriffen verändert wird.

1594-single-page-app-locationfinder-thumb-500x214-1593.pngDie GUI des Locationfinders besteht aus drei Bereichen. Die Sucheingabe erfolgt über ein Formular mit Suchfeld und Filter (1.). Das Suchresultat wird als Google Map (3.) und einer Liste präsentiert (2.).

Keine Page Reloads

One-Page-Apps sind effizient, da Page Reloads durch asynchrone Sub-Requests (AJAX) ersetzt werden. Im Idealfall merkt der User gar nichts von den AJAX Abfragen zwischen View und Controller. Bei solchen Abfragen kann es jedoch schnell zu Performance Engpässen kommen, was vor allem bei älteren Browsern (z.B. IE6) zu Problemen führen kann.
Die Kommunikation kann optimiert werden, in dem das richtige Datenformat gewählt und die Menge der Daten reduziert wird. Bei AJAX Requests ist JSON das bevorzugte Format. JSON hat zwei Vorteile gegenüber XML:

  1. Es ist schlanker und
  2. lässt sich von Javascript schneller verarbeiten.

Rails kann zaubern

Ruby On Rails stellt Methoden für die Umwandlung von Model in JSON (to_json) und XML (to_xml) zur Verfügung. Dies funktioniert auch bei Assoziationen oder ganzen Objektgraphen.

Loading development environment (Rails 2.3.4)
>> l = Location.last
=> #<Location id: 1, name: "Apotheke im...

Vergleicht man die Menge der Daten bei der Ausgabe von JSON mit XML, so kann man den Unterschied erkennen. Nur 45% macht JSON von XML aus!

>> l.to_xml().size
=> 1814
>> l.to_json().size
=> 843

Der Vergleich bei 500 Suchtreffern (5 Suchen à 100 Treffern):
XML: 885.74 KB (1814 * 500 / 1024)
JSON: 411.62 KB (843 * 500 / 1024)

JSON reduziert den Datenverkehr um fast ein halbes MB und das bei nur fünf Suchen!

Die Zauberformel

Die Serialisierung des Models im Controller nach dem Builder Pattern ist mit Ruby On Rails einfach und schnell realisiert. Neben to_xml und to_json gibt es Umwandlungs-Methoden wie to_yaml, to_atom, to_feed, to_rss u.v.m, für die teilweise auch ein Plugin notwendig ist.

Fazit

Die View wird durch JSON im Zusammenhang mit AJAX schneller. Diesen Performance-Boost spürt der User direkt und steigert die Qualität der Software. Als Entwickler hat man mehr Spass an der Arbeit und kommt mit wenig Aufwand zu besseren Resultaten.

Write less, code more.

Wie Panda Bären helfen Interessantes zu entdecken

Das Problem kennt jeder, der schon mal für eine Präsentation ein besonderes Bild gesucht hat. Zuerstmal zu Google mit der Suche nach einem Stichwort – wer mehr Bildqualität braucht sucht vielleicht bei iStockphoto

Das Resultat sind Panda Bären. Viele. Aber leider setzen sich in beiden Fällen die Stereotypen (z.B. die Bilder mit den meisten Downloads) an die obersten Positionen.

Möglicherweise liegt es daran, dass ich Designer bin – jedenfalls würde ich in meiner Präsentation (und erst recht einem Layout) ungern den zigmal verwendeten «Default»-Panda nehmen.

Und jetzt wird’s mühsam und zeitraubend: man blättert also alle 493 Treffer durch und hofft auf den interessanten, aber bisher wenig verwendeten Panda. Oder gibt auf und schnappt sich doch den «yööö-wie-härzig» Top-Treffer.

An der Stelle zu Ling Ling und Hsing Hsing, die Pixelfreund als mystisch debile Flickr Pandas beschrieben hat. Das Prinzip der Bären wird auf code.flickr erklärt:

Ling Ling and Hsing Hsing both return photos they are currently interested in, both have slightly different tastes in photos depending on their mood…

Die Personifizierung der unterschiedlichen Rankings von Suchtreffern oder das Entdecken von Fotos finde ich ein geniales Prinzip. Dass die Kriterien der «Stimmung» wie ein Mysterium unklar bleiben macht es im Fall von Flickr sicher spannender – muss aber nicht sein.

Eine praktische Anwendung der Personifizierung könnte die gestrige Diskussion der UX Chuchi über Sinn und Alternativen zur Liste Projekte entdecken lösen.

Wir waren wohl mehrheitlich der Meinung, dass die technische Art der Sortierung und Auflistung mit der Anzeige von Ratings, Anzahl Besuche/Mitglieder etc. wenig zum entdecken einlädt. Der Vorschlag einer redaktionellen Aufbereitung und Bewertung von Projekte widerspricht jedoch der Philosophie von Amazee sich aus der Bewertung der Projekte herauszuhalten – und so mussten wir diesen Punkt ergebnislos übergehen.

Meine Idee auf Basis der mystischen Flickr Pandas

Drei bis vier fiktive Personen (wenn es besser funktioniert auch gerne Kuscheltiere ;-)) suchen die nach Ihren jeweiligen Kriterien interessantesten Projekte heraus.

Auf diese Art könnte Amazee ohne redaktionelle Aufbereitung und weiterhin – halbwegs – neutral die interessanten Projekte rauspicken und die Kriterien dazu etwas bedeckt halten.

Statt der stereotypen Liste von Resultaten (vgl. meine Bildersuche) durch Sortierung nach «Zuletzt aktualisiert», «Anzahl Spender» oder «Zuletzt erstellt» etc. und dies wiederum technisch einzuschränken auf eine ausgewählte Kategorie wie z.B. «Soziales & Gemeinnütziges» könnten interessante Projekte nach oben kommen obwohl sie zwar vor längerer Zeit erstellt und trotzdem keine Besucher haben – einfach, weil sie beispielsweise thematisch sehr aktuell sind.

Bei Flickr sieht das so aus