Archiv

Smartphone
Neue Werbungskonzepte für Apps

Zahlreiche Apps sind erst einmal kostenlos. Doch häufig muss dafür spontan aufpoppende Werbung ertragen werden. Einige Softwarefirmen wollen aber vor allem eines nicht: dass die Nutzer durch Werbung vergrault werden. Deshalb setzt so manche IT-Schmiede auf alternative Werbekonzepte. IT-Journalist Jan Rähm erklärt die Hintergründe.

Jan Rähm im Gespräch mit Manfred Kloiber |
    Manfred Kloiber: Beliebteste Kategorie von Apps für diesen Markt sind übrigens die Casual Games, also die kleinen Spiele für Zwischendurch wie Tetris oder Bubbleshooter. Die In-App-Werbung treibt da zum Teil auch seltsame Blüten. Zum Beispiel, dass in Spielen für andere Spiele geworben wird. Ganz grundsätzlich gefragt: Muss Werbung immer störend sein?
    Jan Rähm: Nein, das muss auf keinen Fall sein. Werbung kann auch durchaus nützlich sein. Das zeigten hier vor Ort einige Anbieter. Zum Beispiel das Unternehmen Vungle. Dessen Spezialisierung sind Werbevideos für mobile Plattformen, vor allem für Spiele. Und diese Werbevideos entwickelt das Unternehmen so, dass alle Beteiligten etwas davon haben. Das hat mir der Kreativ-Chef Si Crowhurst anhand eines Handyspiels erklärt.
    "Sie spielen ein Spiel, sterben im Level und haben dann keine Leben mehr. Da können Sie entweder neue Leben kaufen oder Sie schauen halt ein 15 oder 30 Sekunden langes Werbevideo. Dafür gibt es dann ein Leben gratis. Schon können Sie genau dort weiterspielen, wo Sie vorher aufhören mussten."
    Rähm: Der Spieler bekommt also ein Leben und kann fröhlich weiter daddeln. Der Spieleentwickler bekommt eine kleine Vergütung. Der Werbende freut sich, dass sein Video gesehen wurde und Vungle freut sich über eine Provision. Das heißt, hier gewinnen irgendwie dann doch alle. Gesetzt den Fall, dass es bei wirklich kurzen Spots bleibt und die Hauptbeschäftigung des Spiels erhalten bleibt, klingt die Lösung also nicht ganz uninteressant für die Zukunft.
    Kloiber: Das Prinzip könnte man ja eigentlich auch "Aufmerksamkeit gegen Goodie" nennen. Richtig harte Informationen, so habe ich es jedenfalls verstanden, gibt es dann im zweiten Beispiel als Gegenleistung: Calldorado heißt das.
    Rähm: Genau. Calldorado ist aber kein eigenständiges Programm, sondern viel mehr ein sogenanntes Framework. Entwickler können die Möglichkeiten von Calldorado in ihre eigenen Apps integrieren. Und was genau Calldorado an Mehrwert bietet, erklärt Peter Jacobsen.
    "Calldorado bringt App-Entwicklern die Möglichkeit, eigene Telefonier-Apps mit Refinanzierungsmöglichkeit zu entwickeln. Der Vorteil für den Anwender: Immer wenn er einen Anruf mit unbekannter Nummer bekommt, zeigen wir, wer dran ist."
    Rähm: Sie müssen sich das so vorstellen, dass statt nur des Anrufernamens gleich noch dessen Kontaktdaten oder seine Web-Adresse eingeblendet wird. Und der Clou ist nun: Wenn Sie zum Beispiel in ihrer Autowerkstatt anrufen und niemand geht ran, zeigt ihnen eine App, die Calldorado integriert hat, alternative Werkstätten in der Umgebung an und außerdem noch unten eine kleine Werbung. Und das tut es dann auch, nachdem Sie einen Anruf beendet haben. Hier hier verteilt sich der Gewinn in monetärer Sich auf den App-Entwickler und eben Calldorado. Der Kunde bekommt eine Revers-Suche für Telefonnummern. Ich persönlich halte dieses Konzept für ein durchaus interessantes Modell. Aber auch hier gilt natürlich: So lange es mit den Werbeeinblendungen nicht übertrieben wird.
    Kloiber: Nur zum Verständnis: Wie kommt denn das Framework in meine Telefonanwendung auf meinem Handy?
    Rähm: Das funktioniert bisher ausschließlich mit Android-Geräten. Dort können die Benutzer die Telefonier-App durch eine andere Telefonier-App ersetzen. Und in diesen Ersatz wird das Framework integriert.
    Kloiber: Von den Frameworks hin zu den Programmiertrends. Kann man eigentlich sagen, dass es bei der App-Erstellung so etwas wie Trends gibt?
    Rähm: Die gibt es durchaus. Grundsätzlich gibt es aber erst einmal drei vorherrschende Arten, Anwendungen auf mobile Geräte zu bringen. Da sind einmal die nativen Anwendungen, die werden in einer Programmiersprache geschrieben, die für die Zielplattform passt. Das hat den Vorteil, dass diese Apps meist sehr performant sind, haben aber den Nachteil: Für jede Plattform muss die App neu geschrieben werden. Das spart man sich, wenn man auf Web-basierte Apps zurückgreift. Da ist nur die Hülle Plattform-spezifisch, der Inhalt basiert auf Web-Techniken wie der Seitenbeschreibungssprache HTML und der Skriptsprache php. Die Apps können Daten auf dem Gerät speichern und müssen auch nicht unbedingt über Webbrowser erreichbar sein. Als drittes könnten Entwickler noch reine Web-Apps schreiben, die der Nutzer dann eben im Browser aufruft. Die haben den großen Nachteil, dass der Entwickler nur bedingt steuern kann, wie seine Anwendung bei Kunden angezeigt wird, da das immer vom Browser abhängt. Welcher Weg nun häufiger gewählt würde, sei nicht klar zu sagen, meint Martin Mudge. Es gebe aber einen Trend.
    "Bei Spielen eignet es sich eher, sie als native App zu entwickeln. Bei Geschäftsanwendungen wird oft auf Web-basierte Apps zurückgegriffen, weil die Daten alle an einem zentralen Ort liegen. Da müssen dann die Geschäftsdaten nicht mühevoll synchron gehalten werden. Wir sehen aber aktuell, dass immer mehr reine Webanwendungen entwickelt werden."
    Rähm: Martin Mudge ist Gründer von BugFinders, einem Unternehmen, das sich auf das Testen von Apps spezialisiert hat. Er betont: Abseits von Trends sei die Fehlersuche einer der wichtigsten Arbeitsschritte bei der Entwicklung von Anwendungen. Auch dabei gibt es verschiedene Ansätze. Einer ist, dass schon vor der eigentlichen Entwicklung Fehlerszenarien und entsprechende Tests entworfen werden und dann wird daran entlang programmiert. Ein anderer Ansatz - beide schließen sich nicht aus und können auch parallel eingesetzt werden. Dieser zweite Ansatz beschreibt im Endeffekt, dass die App während ihrer Entwicklungsschritte immer wieder getestet wird. Ob es denn Fehler gebe, die besonders häufig zu finden sind, habe ich Martin Mudge gefragt.
    "Es gibt nicht den einen häufigsten Fehler. Interessanter sind sowieso die kuriosen Fehler. Zum Beispiel habe ich Fälle gehabt, in denen die Steuer auf verschiedenen Browsern verschiedenen berechnet wurde. Oder Fehler, die auf dem iPad Air 2 auftauchten, aber nicht auf dem iPad Air 1. Dabei sagt Apple, es gebe keinen Unterschied. Manchmal wundere ich mich, wie Entwickler diese Fehler entwickeln."