Wo bleibt (der) ROI in Social Media?

Im Rahmen der Unternehmerwissen Seminarreihe habe ich vergangene Woche einen Workshop zum Einsatz von Twitter für Unternehmen gesprochen. Wie immer bei Social Media Workshops hat dabei die Frage nach dem ROI nicht lange auf sich warten lassen. Dazu habe ich mir ein paar Gedanken gemacht, die in leicht abgewandelter Form auch auf Unternehmerwissen zur Verfügung stehen.

Vermutlich jeden Unternehmer interessiert: Was erhalte ich für meine Ausgaben oder wie hoch ist die Kapitalverzinsung bei einer Investition? In Social Media ist das nicht viel anders. Kaum eine Frage polarisiert so stark wie jene nach dem Return on Investment. Oder kurz gesagt: Was bringt es und wie viel kostet Social Media Marketing? Eine Frage, die leider nicht so eindeutig beantwortet, wie gestellt werden kann.

Der Return on Investment beschreibt prinzipiell das Verhältnis zwischen Werbekosten und Gewinn und stellt eine Rechnung dar, die sich in Zeiten der Informationsgesellschaft nicht mehr so einfach aufschlüsseln lässt. Oder lassen sich Loyalität, Vertrauen und Begeisterung 1:1 in Kaufabschlüssen berechnen? Der ROI ist ein veraltetes Modell, da sich die Parameter verändert haben. Keine Frage: Erfolgsmessung ist wichtig, aber klassische Modelle stoßen hierbei an ihre Grenzen. Viele Faktoren schwingen in der Metaebene mit und lassen sich nicht in eine klassische Kosten-Nutzen-Rechnung umwandeln.

Crossmediale Customer Journey

Der Einsatz von Social Media ist ein weiterer Kanal im Cross-Media-Mix. Die Zeiten, in denen klassische Werbung, PR, Facebook Marketing, Blogger Relations, Print- und TV-Kampagnen einzeln gemessen werden sind vorbei. Social Media Marketing ist nicht mehr länger eine Spielerei, sondern hat sich professionalisiert.

Die Customer Journey aus Unternehmenssicht beschreibt, welche Berührungspunkte ein Konsument mit dem jeweiligen Unternehmen, über alle Medienkanäle hinweg, hat. Diese so genannten Touchpoints reichen von klassischer TV- oder Printwerbung, über Affiliate Marketing, dem Newlsetter, die Website bis hin zu Social Media Kanälen.

Idealerweise werden alle sich bietenden Kanäle miteinander vernetzt und übergeordneten Unternehmenszielen untergeordnet. Und zwar mit Mehrwert. Und Mehrwert bedeutet in diesem Fall nicht den ROI des eigenen Unternehmens zu steigern, sondern für den User relevante Inhalte zu liefern, sich bewusst mit ihm auseinanderzusetzen und Interesse zu erzeugen.

Ziele in Social Media

Wichtig im Vorfeld sind dafür allerdings konkrete Zielsetzungen und die Frage: Was soll überhaupt gemessen werden? Einige Bereiche dafür wären: Steigerung der Markenbekanntheit, Optimierung des Suchmaschinenranking, Umsatzsteigerung, Marktforschung, Öffentlichkeitsarbeit, Ausbau der Kundenloyalität, Produktfeedback, Newsletteranmeldungen, Aufbau von Blogger Relations oder Steigerung des Website-Traffics.

Key Performance Indicator die wirklich zählen

So traurig die Wahrheit auch ist. Einheitliche Kennzahlen, Key Performance Indicators genannt, die über Erfolg oder Misserfolg in Social Media entscheiden, gibt es nicht. Vielmehr gilt es quantitative und qualitative Faktoren gemeinsam mit Zielgruppenanalysen und bisherigen Unternehmenskennzahlen in Relation zu setzen, um auf Basis dessen, Zielsetzungen sowie Massnahmen zu deren Erreichung zu definieren. Jedes Unternehmen hat andere Zielsetzungen und individuelle Kennzahlen, die gemessen werden. Follower, Shares, Likes, Retweets und Mentions sind leicht zu ermitteln. Wirklich aussagekräftig sind diese aber nicht. Wie definiert man also so genannte Key Performance Indicators?

Quantitative Messung

In diese Kategorie fallen die Zahl der Fans / Follower sowie die Anzahl der von Usern bereit gestellten Informationen. Kurz: Wie sieht die Beschäftigung mit der Marke oder dem Unternehmen aus? Doch diese Zahlen können trüben. Hohe Fan- bzw. Followerzahlen sagen nicht eindeutig etwas darüber aus, ob diese in irgendeiner Form für das Unternehmen relevant sind.

Qualitative Messung

Wichtiger ist es, das Interaktionslevel und den allgemeinen Tenor zu beobachten. Gibt es hauptsächlich positive oder negative Kommentare, sind Meinungsbildner unter den Fans / Follower, werden die unternehmensrelevanten Inhalte aufgegriffen, gibt es Supportanfragen, die auf Mängel hinweisen? Hat sich das Verhältnis von positiven zu negativen Kommentaren verbessert? Bei laufenden Kampagnen kann dadurch leicht die Strategie noch angepasst werden. Eine loyale Fanbasis verteidigt Sie dann auch im Krisenfall.

EINIGE BEKANNTE KEY PERFORMANCE INDICATORS

  • Share of Voice = Gesamt-Erwähnungen der Marke / Gesamterwähnungen der Branche (Marke + Mitberwerber A, B, C…) Wie oft wird die Marke / das Unternehmen im Vergleich zum Mitbewerb erwähnt?
  • Sentiment Ratio = Positiv: Negativ: Neutrale Erwähnungen zur Marke / Alle Markenerwähnungen Wie oft wird eine Marke / Unternehmen / Produkt in einem bestimmten Zeitraum in Social Media erwähnt?
  • Conversation Reach = Reichweite der Beiträge in Kontext zu einem bestimmten Thema / Stichwort Dadurch lässt sich die Entwicklung eines Bestimmten Themas in Sozialen Medien messen.
  • Active Advocates = Anzahl der User, die innerhalb eines bestimmten Zeitraums einen positiven Beitrag kommuniziert haben / Gesamtzahl der User Lässt sich sehr gut einsetzen, um die Kampagnenwirksamkeit zu testen und geht der Frage nach, welche User in einem bestimmten Zeitraum über ein Thema positiv gesprochen haben.
  • Issue Resolution Time = Benötigte Gesamtzeit bei Anfragen / Gesamtzahl an Service-Anfragen Diese Kennzahl misst die Reaktionszeit auf Useranfragen und gilt als Indikator für die Effizienz des Kundenservice.
  • Topic Trends = Anzahl der Erwähnungen eines bestimmten Themas / Erwähnungen aller Themen Durch die Berechnung der Topic Trends lassen sich einfach Trends ablesen.

Blick über den Tellerrand

Sind qualitative und quantitative Zahlen im Social Media Marketing erstmal ermittelt, fängt die eigentliche Arbeit an und die zentrale Frage lautet: In welchem Verhältnis stehen diese Zahlen zu allgemeinen Unternehmenszielen. Und diese sind bekanntlich sehr unterschiedlich: Ein Elektronikhersteller wird in Absatzzahlen und ein Beherbergungsbetrieb in Nächtigungszahlen und Konsumationen messen. Mittels Web-Analysetools (wie z.B. Google Analytics) lässt sich sehr gut feststellen, wieviele User über Soziale Medien auf die Website finden und ob es sich dabei um einmalige oder wiederkehrende Besucher handelt. Kaufabschlüsse jeglicher Art können mitgetrackt und die Wirkung von Kampagnen analysiert werden.

Über Nacht passiert allerdings nicht viel. Social Media Relations dienen zum Aufbau einer langfristigen Reputation, der Gewinnung von Leads und der Conversion-Steigerung. Kurzzeitiger Aktionismus ‑ wenn er denn gut umgesetzt ist ‑ kann die Absatzzahlen für den Moment steigern, ist aber langfristig zu eindimensional gedacht. Nehmen wir das Beispiel Twitter. Im Vergleich zu Facebook gibt es nur begrenzt die Möglichkeit zur Integration von diversen Gewinnspielaktionen. Im Gegensatz zu Facebook Ads muss man für Promoted Tweets auch sehr tief in die Tasche greifen. Dafür eignet sich Twitter aber hervorragend als Servicekanal für Kundenanfragen, oder für die Umsetzung von crossmedialen Kampagnen bzw. ist ein Kommunikationsmedium, bei dem man in direkten Kontakt mit dem User treten kann.

Abschließend kann man also sagen: Ergebnisse lassen sich messen, eine pauschale Zauberformel gibt es allerdings nicht. Handfeste Analysen sind individuell. Klassische Werbewirkungsrechnungen verlieren bei der Vielschichtigkeit in Social Media an Wirkung. Im Zentrum stehen nachhaltige Interaktionen, die auf Basis vordefinierter Zielsetzungen, auch messbar sind.

Barracuda, Octopus und Aegir – Teil 2

Nach Ablauf der Weihnachtspause machen wir unsere Drohung wahr und beginnen mit dem Bau des eigenen Aquariums. In diesem Teil beschäftigen wir uns mit dem Einrichten der virtuellen Maschine, Ubuntu Server und der Grundinstallation von Barracuda und einer Octopus Instanz.

Alle Schritte wurden unter Mac OS 10.8 durchgeführt und getestet. Der Einfluss des Host-Systems ist allerdings relativ gering, das Tutorial sollte mit leichten Adaptionen auch in anderen Betriebssystemen anwendbar sein.

Virtuelle Maschine

Zuerst brauchen wir eine virtuelle Maschine mit Ubuntu Precise Server als Betriebsystem. Dazu laden wir als erstes das Image Ubuntu Server 12.04.1 LTS und eine Virtualisierungssoftware. Ich benutze Parallels Desktop für Mac, im Prinzip müsste aber alles auch mit VirtualBox oder VMWare funktionieren.

Dann erstellt man eine virtuelle Maschine und installiert das Betriebssystem. Die meisten, die dieses Tutorial in Angriff nehmen, haben so etwas höchstwahrscheinlich schon gemacht, deswegen werden wir nicht jeden Schritt einzeln durchexerzieren. Im Zweifelsfall finden sich auch genug Anleitungen dazu im Netz. Man sollte nur ein paar wichtige Eckpunkte beachten:

  • Das Betriebssystem sollte auf Englisch installiert werden. Sonst kann es zu einigen interessanten Fehlern kommen, da das Barracuda Skript sich teilweise darauf verlässt.
  • Die Netzwerkeinstellungen sollten so gewählt werden, dass unsere Maschine eine fixe IP Adresse bekommt. Das kann je nach Virtualisierungssoftware auf verschiedenen Wegen erreicht werden. In Parallels reichen dafür die Standardeinstellungen. Zwar arbeiten die auch über DHCP, Parallels verteilt an eine Maschine aber immer dieselbe Adresse.
  • Wir brauchen keinerlei Zusatzpakete, das System sollte völlig nackt sein. Einzig OpenSSH ist zu Beginn praktisch, wenn man die ersten Schritte nicht in der wenig handlichen Default-Shell durchführen will.
  • Sämtliche GUI-Pakete können auch eingespart werden. Zwar funktioniert Barracuda auch mit ihnen, sie kosten im Betrieb aber Arbeitsspeicher und sind nicht wirklich notwendig.
  • Parallels bietet für Ubuntu eine „Express-Installation“ an. Wir lassen uns nicht darauf ein, sondern machen lieber alles selbst. Damit die bisher genannten Punkte auch sicher eingehalten werden.

Nach durchführen des Installationsprozesses sollte man im Idealfall den Login-Prompt vor sich haben, den man mit den zuvor gewählten Daten füttert. Ubuntu erlaubt standardmäßig keinen root-Login. Stattdessen hat unser, bei der Installation erstellter, Account sudo Rechte. Wir geben also einfach sudo su in die Kommandozeile ein, antworten mit dem selben Passwort wie beim Login, und schon sind wir in der root-Shell, in der wir ab nun weiterarbeiten.

DNS Setup

Aegir kennt keine Unterverzeichnisse mehr. Jede Site braucht eine eigene Domain. Im Prinzip könnten wir jedes mal einen Eintrag in /etc/hosts vornehmen, bei vielen Seiten wird das aber umständlich, also brauchen wir eine bessere Lösung.

Option 1: xip.io

xip.io ist ein kostenloser Service der klugen Köpfe hinter 37 Signals. Das Prinzip ist einfach. Ein spezieller DNS-Server fängt alle Anfragen auf xip.io, und löst sie auf eine IP-Adresse in der Subdomain auf. Zum Beispiel:

  • 192.168.1.10.xip.io zeigt auf 192.168.1.10
  • mydevsite.192.168.1.10.xip.io zeigt ebenso auf 192.168.1.10

Das wäre eine Lösung ohne jeglichen Aufwand. Nachteile sind aber vor allem die etwas unhandlich langen Domains, und die Tatsache, dass man Internetzugang braucht, um die Virtuelle Maschine zu erreichen. Das kann nervig sein, wenn man von unterwegs arbeitet.

Option 2: dnsmasq

Viel praktischer wäre es doch, wenn wir eine Top Level Domain hätten, die immer auf unseren Testserver zeigt. Und damit alles schön in einem Paket ist, sollte dieser auch gleich als DNS-Server agieren. Barracuda liefert eigentlich eine Integration für bind9 mit, das ist für unseren Anwendungsfall aber zu komplex. Stattdessen installieren wir dnsmasq:

apt-get install dnsmasq

Und editieren die mit dem Editor unserer Wahl – also vi – die folgenden Dateien

/ETC/DHCP/DHCLIENT.CONF:

Hier suchen wir die Zeile prepend domain-name-servers 127.0.0.1; und stellen sicher dass sie nicht auskommentiert ist, beziehungsweise fügen sie bei Zeile 20, nach supersede domain-name "fugue.com home.vix.com"; ein. Damit befehlen wir der Netzwerkkonfiguration unseren internen DNS-Server standardmäßig mit abzufragen.

/ETC/DNSMASQ.CONF

Hier konfigurieren wir dnsmasq selbst. Und zwar machen wir einen fixen Adresseintrag. In Zeile 62 sollten wir ein Beispiel dazu finden:

#address=/double-click.net/127.0.0.1

Diese kopieren wir und ändern sie, sodass die Top-Level Domain .bcd (kurz für „Barracuda“) auf unsere statische Adresse (in meinem Fall 10.211.55.12) zeigt.

address=/bcd/10.211.55.12

Achtung: Statt bcd kann man natürlich jede andere erfundene Top-Level Domain verwenden. Beliebte Kandidaten wie .local oder .private werden jedoch von OSX für interne Services wie zum Beispiel Bonjour schon verwendet. Das kann da zu interessanten Problemen führen und sollte deshalb vermieden werden.

Nach einem Neustart von dnsmasq …

/etc/init.d/dnsmasq restart

… sollte das ausführen von dig irgendwas.bcd unter anderem folgende Answer Section zurückliefen:

;; ANSWER SECTION:
irgendwas.bcd.      0   IN  A   10.211.55.12

Das bedeutet der DNS-Server läuft und ist zumindest innerhalb der Virtuellen Maschine erreichbar. Wir brauchen ihn aber auch noch von aussen. Dazu gehen wir in eine Shell im Hostsystem und suchen wiederum:

dig irgendwas.bcd @10.211.55.12

Das sollte wieder in derselben Answer Section resultieren. Wir wissen also, dass der DNS Server auch von aussen erreichbar ist, jetzt müssen wir nur mehr sicherstellen, dass das System unseren neuen DNS Server auch verwendet. Unter OSX geschieht das in den Einstellungen zum gerade aktiven Netzwerkadapter im Reiter DNS.

Die Lösung ist leider nicht optimal, da man die Default-Einstellungen überschreiben, und das ganze – sollte man mehrere verschiedene Adapter und Umgebungen verwenden – auch noch mehrfach eintragen muss. Problematisch wird es bei Netzwerken mit eigenen DNS Servern, die dann plötzlich nicht mehr funktionieren. Sollte jemand eine elegantere Variante kennen, würde ich mich über Hinweise freuen!

Manchmal werden die neuen DNS Einträge nicht sofort berücksichtigt, beziehungsweise nach Fehlern nicht aktualisiert. Unter OSX leert man den DNS-Cache mit folgendem Kommando:

sudo dscacheutil -flushcache

Oft reicht das nicht aus, da DNS-Abfragen durch mDNSResponder – ein Teil von Bonjour – laufen, und der cached sie auch noch zusätzlich. In diesem Fall liefert dig zwar das richtige Ergebnis, ping behauptet aber trotzdem den Host nicht zu kennen. Um das Problem zu lösen schießt man den verantwortlichen Prozess ab, damit er beim nächsten Aufruf neu gestartet wird. Nicht schön, aber wer so viel Verwirrung stiftet hat es verdient.

sudo killall -HUP mDNSResponder

Edit: Die Hinweise sind eingelangt. Es gibt eine (relativ) einfache und elegante Lösung unter OSX. Und zwar legt man im Ordner /etc eine Unterordner resolver an, und erstellt dort eine Datei namens bcd (ohne Endung) mit folgendem Inhalt:

nameserver 10.211.55.12

Dadurch wird ein neuer DNS Resolver registriert und für alle Domains die auf bcd enden verwendet, ohne in die normale Netzwerkkonfiguration einzugreifen.

Barracuda und Octopus

An diesem Punkt haben wir eine Virtuelle Maschine die auf die Domains mit der Endung .bcd horcht. Wir sind also bereit Barracuda selbst einzurichten.

Die offizielle Anleitung rät den das Meta-Kommando boa zu verwenden, welches fertige Konfigurationen für local und public Server bereitstellt. Beide funktionieren in unserem Setup jedoch nicht so richtig, deswegen gehen wir den etwas längeren Weg und konfigurieren selbst.

Als erstes laden wir in unserer virtuellen Maschine als root User die beiden Installationsskripte:

wget -q -U iCab http://files.aegir.cc/BARRACUDA.sh.txt
wget -q -U iCab http://files.aegir.cc/OCTOPUS.sh.txt

Installation von Barracuda

Dann installieren wir die benötigte Software und die Master-Instanz. Dazu editieren wir die gerade geladene Datei BARRACUDA.sh.txt. Dort finden sich eine Menge Optionen und alle sind sehr ausführlich dokumentiert. Man sollte sie zumindest kurz überfliegen, dann erklärt sich vieles von selbst. Folgende Punkte sind zu beachten:

  • _MY_EMAIL: Den richtigen Wert hierfür zu finden überlasse ich dem Hausverstand.
  • _EASY_LOCALHOST und _EASY_PUBLIC müssen auf NO gesetzt werden.
  • Sollte man nicht vorhaben Drupal 5 zu unterstützen, ist für _PHP_FPM_VERSION und _PHP_CLI_VERSION der Wert 5.3 im Hinblick auf Drupal 8 Support empfehlenswert.
  • _XTRAS_LIST: Für unsere Setup sind CSF (Firewall) und PDS (DNS-Cache) nicht notwendig, und stellen nur potentielle Fehlerquellen dar – also raus damit. Dafür nehmen wir CSS (Compass Tools) und SLR (Tomcat + Solr) mit auf.
  • Im Idealfall erkennt das Skript die Domain und IP-Adresse automatisch. Sollte man Fehlermeldungen bezüglich FQDN und Adressauflösungen bekommen, so kann man _MY_OWNIP_MY_HOSTN und _MY_FRONT mit den entsprechenden Werten befüllen und eventuell _DNS_SETUP_TEST auf NO setzen.

Nachdem man die Datei bearbeitet und mehrfach kontrolliert hat, führt man das Script mit bash BARRACUDA.sh.txt aus und holt sich einen Kaffee oder ein alternatives Heißgetränk mit dem man die nächsten Minuten überbrücken kann.
Sofern der Prozess nicht aufgrund irgendwelcher Fehler abgebrochen wurde, wirft das System einen einmalig verwendbaren Login-Link aus. Diesen findet man jederzeit auch in der Datei /var/aegir/install.log. Wir benutzen den Link, und setzen auch ein Admin-Passwort, weiter werden wir die Master Instanz aber gar nicht verwenden.

Die Octopus Instanz

Im zweiten Schritt der Installation erstellen wir eine Octopus Instanz für unser Development-System in der wir dann arbeiten. Theoretisch wäre es möglich auch mehrere zu generieren, das macht in unserem Fall allerdings nur begrenzt Sinn.

Die Datei OCTOPUS.sh.txt ist im BARRACUDA.sh.txt im großen und ganzen recht ähnlich:

  • Wir setzen _USER auf einen handlichen Benutzernamen wie devdevelopment oder masterofdesaster. Der Einfachheit halber gehen wir in den weiteren Schritten von dev aus.
  • _MY_EMAIL und _CLIENT_EMAIL können dieselbe, wieder vom Hausverstand diktierte, Adresse enthalten.
  • PHP-Versionen und DNS-Setup konfiguriert man am besten analog zu BARRACUDA.sh.txt.
  • _PLATFORMS_LIST enthält eine Liste von Drupal-Distributionen die für diese Octopus-Instanz automatisch installiert und aktualisiert werden. Wer herumprobieren will und eine längere Installation in Kauf nimmt kann sich hier austoben. Man kann Distributionen aber natürlich auch später von Hand installieren.

Wir führen die Datei wieder mit bash OCTOPUS.sh.txt aus und trinken den zweiten Kaffe für heute. Wenn alles glatt geht bekommen wir wieder einen Login-Link, diesmal zu unserem richtigen Aegir-Interface. Dieser findet sich auch diesmal in einer Log-Datei: /data/disk/dev/log/install.log.

Die Installation versendet auch automatisch eine E-Mail mit weiteren Instruktionen an die in OCTOPUS.sh.txt notierten E-Mail Adressen. Sollte diese nicht ankommen findet man sie auch in /data/disk/dev/log/setupmail.txt. Für den nächsten Schritt wichtig sind vor allem die FTP-Zugangsdaten.

Die erste Plattform

Wenn bis zu diesem Punkt alles funktioniert hat stehen wir kurz davor endlich unsere erste Drupal Website zu installieren. Dazu melden wir uns anhand der FTP-Zugansdaten mithilfe eines beliebigen FTP-Clients an und navigieren ins Verzeichnis static. Dieses ist reserviert für eigene Plattformen, also Drupal-Distributionen, die Barracuda beim Update nicht anrührt. Dort erstellen wir ein Verzeichnis my-drupal und befüllen es mit der aktuellsten Drupal-Version.

Dann begeben wir uns wieder in das Aegir-Interface unserer Octopus-Instanz und erstellen mit Content Management » Create Content » Platform (oben in der Administrationsleiste) eine neue Plattform der wir den Namen My Drupal geben. Wichtig ist dass der angezeigte Pfad unter dem Plattform Namen auch dem im Dateisystem entspricht.

Nach dem Speichern dauert es ein wenig bis Aegir die Plattform verifiziert. Danach können wir mit dem Tab Add Site eine Neue Seite anlegen. Dieser geben wir eine beliebige Domain, die auf .bcd endet und wählen – verwirrender Weise – zuerst ein Installationsprofil und danach eine Plattform in der dieses verfügbar ist. In unserem Fall sollte das vorerst Standard und My Drupal sein. Hat man gleich mehrere Distributionen mit installiert sollten diese auch zur Auswahl stehen.

Nach dem Speichern braucht Aegir wiederum ein wenig um unsere neue Seite zu installieren, dann liefert uns das Admin Interface direkt den aktuellen Status der Seite und einen Link zum einmaligen Anmelden.

Die letzten Schritte können wir nun beliebig oft wiederholen, um weiter Plattformen, Distributionen und Seiten zu installieren. Innerhalb von my-drupal (und allen anderen Plattformen in static) können wir auch wie gewohnt Module und Themes hinzufügen.

Das war noch nicht alles!

Bisher haben wir eine tolle Übung in Sachen Server- und DNS Konfiguration absolviert, das Leben als Entwickler erleichtert es uns bisher aber noch nicht gewaltig. Im nächsten (und voraussichtlich letzten) Teil dieser Blogreihe gehe ich auf einige Tips, Tricks und Stolpersteine rund um den Entwicklungsprozess innerhalb von Barracuda und Aegir ein. Das Beste kommt also zum Schluss!