Wie erkennst du minderwertigen App Kampagnen Traffic?

Die Auswertung von Kampagnen gehört zum täglich Brot jedes Performance Marketing Managers. Die Kampagnen müssen stets optimiert werden und der ROAS sollte idealerweise kontinuierlich verbessert werden. Die Affiliate Manager und die App Marketing Manager haben zudem vermehrt mit der Qualität des Traffics zu kämpfen (mehr als ihre Online Performance Marketing Kollegen). Im App Marketing und vor allem im App Affiliate Marketing gibt es viele schwarze Schafe die minderwertigen Traffic anbieten diesen sollte man möglichst früh erkennen und diese Kampagnen stoppen. Auch die Kampagnen der anderen etablierten App Netzwerke wie Google Ads (UAC) oder Facebook Ads (App Ads) sollten kontinuierlich überwacht werden und die Installationen mit Engagement KPIs bewertet werden. Im folgenden Beitrag zeigen wir euch wie das geht.

Du brauchst ein gutes App Attribution Tracking Tool

Die Voraussetzung um App Kampagnen auswerten zu können ist ein einheitliches Attribution Tool welche alle Kampagnen und Kanäle übergreifend und unter gleichbleibenden Bedingungen misst. Dieses Tools werden auch Mobile Measurement Partner (MMP) genannt. Zu den bekanntesten Anbietern von MMPs gehören Adjust, Kochava oder AppsFlyer. Unser Favorit ist aus eigener Erfahrung Adjust, obwohl die anderen Anbieter ebenfalls gute Arbeit leisten und in bestimmten Aspekten ihre Stärken gegenüber Adjust haben.

Die Problematik der Traffic-Qualität im App Marketing

Wie bereits in den Artikeln App Affiliate Marketing und Incent Traffic beschrieben hat die App Marketing Branche ein Problem mit der Traffic Qualität. Dazu zählen

• Unbewusst eingekaufter Incent Traffic: Viele Anbieter mischen bewusst ihre nicht incentivierten CPI- oder CPA-Kampagnen mit günstigem Incent oder Soft-Incent Traffic, um eine höhere Marge zu erwirtschaften. Manche Anbieter wissen selbst nicht, dass sie incentivierten Traffic anbieten, da in der App-Affiliate-Branche sehr viel Rebrokering betrieben wird. Die Affiliate Netzwerke kaufen untereinander die Installationen ein, deshalb mischt sich zwangsläufig minderwertiger Traffic in der Distributionskette mit ein.
• Spam- und Bot-Traffic: neben dem incentivierten Traffic gibt es einige Anbieter, die bewusst betrügen und durch Bots generierten Traffic als echten Traffic anbieten. Die Bots simulieren sogar ein in-App-Engagement um unentdeckt zu bleiben.
• Ansprache wenig kaufbereiter Zielgruppen: Auch wenn die Netzwerke keine Spam, oder Incent-Traffic-Probleme haben so kann es sein, dass man die falsche Zielgruppe anspricht. Diese User Installieren die App, sie sind aber nicht bereit in-App Käufe zu tätigen. Diese Zielgruppen solltest du identifizieren und das Media Budget umverteilen.

Die Lösungsansätze

Nachdem die App installiert wurde und das erste Mal geöffnet wurde wird das Standard-Event “App Geöffnet” gefeuert. Ab hier können wir die in-App Customer Journey des Users tracken. Es sind standardmäßig folgende in-App Events verfügbar, die kein zusätzliches Setup benötigen:

• Sessions: Anzahl der Besucher-Sessions
• DAU (Daily Active Users): ist die Anzahl der aktiven Nutzer an einem Tag.
• WAU (Weekly Active Users): ist die Anzahl der aktiven Nutzer in einer Woche.
• MAU (Monthly Active Users): ist die Anzahl der aktiven Nutzer in einem Monat.
• Reattribution: Ist die Anzahl der Installationen bzw. der App-geöffnet-Events innerhalb eines Zeitraums, die durch neue Kampagnen (z. B. Retargeting) wieder entstanden sind. 

Bereits mit diesen Events könnt ihr die Installationen auswerten. Wenn ihr noch mehr Erkenntnisse sammeln wollt, dann müsst ihr individuelle Events in der App verbauen. Welche events das sein sollen hängt stark davon wie eure App konzipiert ist und welche Features sie aufweist. Folgende Events könntest du neben deinen individuellen einbauen:

• User hat sich registriert
• User hat ein Free Feature genutzt
• User hat einen In-App Kauf getätigt
• User hat XYZ gemacht

Das setzen der in-App Events ist eine sehr individuelle Sache und bedarf eines durchdachten Tracking-Konzepts. Bei allen technischen Möglichkeiten darf man nicht vergessen, dass ein Attribution Tracking Tool für die Auswertung der Kampagnen gedacht ist und nicht um die Nutzer-Journey in der App abzubilden. Das heißt  – man sollte nur die wichtigsten Ereignisse in der App Tracken. Sprich, alle Events durch welche sich Rückschlüsse auf die Traffic-Qualität und die Kampagnen-Performance ziehen lassen.

Am Ende des Tages wollen wir wissen was die User, die durch die Kampagne X akquirert wurden, in der App getan haben und wie oft. Diese Daten wollen wir mit den Daten der Nutzer der Kampagne Y vergleichen. Für einen Vergleich zweier unterschiedlicher Netzwerke oder Kampagnen ist es beispielsweise besser die Anzahl der Tarifabschlüsse in einer fiktiven App zu vergleichen als die Klicks auf einzelne Buttons in der App. Für granulare Auswertungen des Nutzerverhaltens in der App sollte ein In-App Analytics Tool wie zum Beispiel Firebase Analytics (ehemals Google Analytics for Apps) eingesetzt werden. Dort können dann auch detaillierte Auswertungen vorgenommen werden zum Beispiel wo Nutzer in der App abspringen oder welche Events sie im Detail in ihrer User-Journey durchführen.

Beispiele für die Bewertung der Traffic-Qualität einer App Kampagne

Kampagne X: 1 € CPI – 900 Installationen –  950 Sitzungen – 4 Registrierungen

Kampagne Y: 2 € CPI – 800 Installationen –  2400 Sitzungen – 400 Registrierungen

Dieses stark vereinfachte Beispiel soll zeigen, dass es bei der Bewertung von Kampagnen nicht nur auf die Kosten für eine Installation ankommt. Es ist wichtig auch die Folge-Events zu betrachten. Die fiktive Kampagne X hat sehr günstige Installationen jedoch haben sich von den 900 Ntuzern die die App installiert haben nur 4 Nutzer registriert. Das ergibt eine Conversionrate von Installation zu Registrierung von nur 0,4%. Die beispielhafte Kampagne Y hat einen deutlich doppelt so teuren CPI generiert jedoch deutlich mehr Registrierungen pro Installation. Die Kampagne erreicht eine Conversionrate von 50% was eine drastische Verbesserung gegenüber Kampagne X ist. Eine solche Analyse sollte unter Einbeziehung weiterer Engagement-KPI regelmäßig erfolgen um die laufenden Kampagnen zu optimieren. Kampagnen mit einem niedrigen Engagement sollten abgestellt werden bzw. im Budget eingeschränkt werdem. 

Beispiel für die Wirtschaftlichkeit einer Install-Kampagne

Kampagne X: 900 Installationen zu 3 € CPI – 40 Registrierungen (65 € CPR), 6 Käufe (450 € CPS)

Kampagne Y: 400 Installationen zu 6 € CPI – 20 Registrierungen (120 € CPR), 12 Käufe (200 € CPS)

Kampagne Z: 160 Installationen zu 9 € CPI – 50 Registrierungen (25 € CPR), 25 Käufe (55 € CPS)

Dieses ebenfalls vereinfachte Darstellung zeigt, dass die Kampagne X trotz des günstigsten CPI den teuersten CPC hervorruft. Die Kampagne Z wiederum hat den teuersten CPI, allerdings durch die relativ vielen Käufe einen günstigsten Cost per Sale. Leider ist das Volumen dieser Kampagne sehr niedrig und müsste trotz der hohen Installationskosten erhöht werden. Falls es nicht möglich sein, das Volumen der fiktiven Kampagne Z zu erhöhen, sollte das Budget der Kampagne X auf die beispielhaften Kampagnen Z und Y aufgeteilt werden, um den ROAS zu maximieren.

Kohorten-Analyse

In den meisten Analyse-Tools betrachtet man die Kampagnen in der Standardansicht und unter einer zeitlichen Segmentierung (z. B. die letzten 30 Tage). Bei solch einer Ansicht lassen sich die obigen Beispiele nur dann aussagekräftig vergleichen wenn die Kampagnen die zum gleichen Zeitpunkt gestartet sind. Der Grund liegt in der Länge der in-App Conversion Funnel. Die Post Install Events werden immer der Ursprung-Kampagne zugerechnet, auch wenn diese schon abgeschaltet ist. Wenn die Conversion Funnel bis zum Sale länger sind als 30 Tage eine der Kampagnen aber ausgestellt wird oder ihr Mediabudget extrem reduziert dann ergeben sich nicht vergleichbare CPS-Werte im gewählten Betrachtungszeitraum. 

Diesen Missstand kann man umgehen indem man eine Kohorte eines Zeitraums bildet. Dabei werden nur die Post Install Events miteinander verglichen deren Installationen im gleichen Zeitraum liegen. Das ist bei Analysen extrem wichtig  und wird meiner Erfahrung nach viel zu selten gemacht.

Am besten lässt sich die Problematik an einem konkreten Beispiel erklären. Die folgende Tabelle zeigt einen Kanalvergleich wichtiger Metriken einer fiktiven App über den Betrachtungszeitraum von einem Monat.

Ich erlebe oft das auf Basis dieser Daten weitere KPIs berechnet werden wie der Cost per Registration (CPR). Das ist problematisch, da sich hier schnell ein falsches Bild abzeichnet. In unserer Beispiel-App findet die Registrierung zu einem beliebigen Zeitpunkt statt. Das heißt der Nutzer muss sich nicht sofort registrieren sondern kann die App auch ohne Registrierung in begrenztem Umfang nutzen. Dadurch finden viele Registrierungen erst einige Tage oder Wochen nach der ursprünglichen Installation statt. Dieser Umstand birgt ein großes Problem bei der Berechnung von Metriken wie der Conversionrate von Installation zu Registrierung. In Der Tabelle sehen wir, dass wir in dem Monat 2500 Installationen über Google UAC Kampagnen generiert haben. Im gleichen Zeitraum hat unser Analytics-Tool 1200 Registrierungen über diesen Kanal erfasst. Eine naive Berechnung der Conversionrate ergibt in diesem Fall eine Rate von 48%.

Wo liegt in dieser Berechnung der Fehler? Wir haben festgehalten, dass die Registrierungen in unserer Beispiel-App auch noch Wochen nach der ersten Installation stattfinden können. Die Tabelle betrachtet jedoch einen festen Zeitraum von nur einem Monat. In unserer Berechnung betrachten wir also nicht, dass ein Teil der Registrierungen welche in diesem Monat erfasst wurden, durch Installationen vergangener Monate erzeugt wurde. Die 2500 Installationen wurden definitiv im betrachteten Zeitraum generiert, das Post-Install Event Registrierung jedoch nicht. Dadurch kommt es zu einer Nichtübereinstimmung der Betrachtungszeiträume.

Dieses Problem kann durch die Kohortenanalyse gelöst werden. Im konkreten Beispiel würden wir eine Nutzerkohorte anhand des Installationszeitraums bilden. Wir betrachten also nur Nutzer welche die App im Zeitraum des betrachteten Monats installiert haben. Im Rahmen der Kohortenanalyse wird jetzt auf Basis dieser Kohorte betrachtet, welche Events diese spezifische Gruppe von Nutzern ausgeführt hat. Die folgende Tabelle zeigt die Anzahl der Registrierungen einer Nutzerkohorte eines bestimmten Monats über einen Zeitraum von 3 Monaten.

Wir sehen in der Tabelle dass nur 600 der ursprünglichen 2500 installierenden Nutzer sich im ersten Monat registriert haben. Auch in den zwei folgenden Monaten sehen wir insgesamt nur 65 weitere Registrierungen. Das heißt also, dass ein großer Teil der Registrierungen welche wir in der ersten Betrachtung sahen, durch Nutzer durchgeführt wurde, welche die App vor unserem Betrachtungszeitraum installiert haben. Wir haben initial die Conversionrate anhand aller Registrierungen berechnet – das bietet jedoch viel Raum für fehlerhafte Betrachtungen der Conversionrate. Wenn wir davon ausgehen, dass die meisten Nutzer, welche die App installiert haben, sich innerhalb von 3 Monaten registrieren, können wir die Conversionrate auf Basis der Events der ersten 3 Monate berechnen. In unsere Tabelle sehen wir also, dass durch diese 2500 Installationen in den ersten 3 Monaten nur 465 Registrierungen zustande kamen. Mit diesem neuen Ansatz der Berechnung ergibt sich eine Conversionrate von 18,6% und nicht 45%.

Die Berechnung zusätzlicher Metriken wie dem Cost per Action oder der Conversionrate weicht umso mehr ab, je stärker die Abweichungen bei der Berechnungsbasis sind. Wenn in den Vormonaten der Berechnung mit mehr Mediabudget sehr viele Installationen generiert wurden und im Berechnungsmonat aufgrund eines geringeren Budgets nur weniger Nutzer die App installiert haben, wird die Diskrepanz bei der Berechnung Post-Install Metriken umso größer.

Da bei der Bewertung der Qualität der Nutzer ein starker Fokus auf die Durchführung von Post-Install-Events liegt, ist die Kohortenanalyse ein gutes Werkzeug um diese Events auch realistisch zu bewerten. Es ist nicht immer notwendig sich Nutzerkohorten anzusehen. Wenn die Datenbasis (in diesem Fall der Zeitraum der Installationen) gleichmäßig verteilt ist, können Conversionraten und Kosten pro Event auch ohne Kohorten berechnet und sinnvoll ausgewertet werden. Für Kampagnen mit abweichenden Budgets aber auch bei gravierenden Abweichungen in der User-Journey innerhalb der App, sollte unbedingt eine einzelne Kohorte für die Berechnung der Post-Install Metriken genutzt werden.

Umgang mit schlechtem Traffic

Sobald vergleichsweise schlechte Traffic-Quellen identifiziert wurden, muss entschieden werden wie man mit diesem Traffic umgeht. Nur weil bestimmte Kanäle schlechter performen als andere, können diese weiterhin profitabel für das eigene Geschäft sein. Es gibt viele Gründe dafür, dass sich Traffic aus unterschiedlichen Quellen anders verhält. Der nächste Schritt sollte sein herauszufinden warum der Traffic einer Kampagne X schlechter ist als eine Kampagne Y. Bei der Nutzung von Affiliates und Publisher-Netzwerken sollte zudem in Betracht gezogen werden, dass es sich bei sehr schlecht performendem Traffic auch um App-Fraud in Form von Bots handeln kann. Sollte solch eine Vermutung aufkommen, ist es umgehend zu empfehlen sich mit dem jeweiligen Affiliate oder Publisher auseinanderzusetzen und das Thema direkt anzusprechen. Im Zweifelsfall sollte fragwürdiger Traffic möglichst pausiert werden, da er langfristig unabsehbare negative Seiteneffeke auf die eigene App haben kann. So können durch viele schlechte Installationen auch sehr viele Deinstallationen entstehen. Deinstallationen können für den Apple App Store aber auch den Google Play Store ein stark negatives Signal sein, welches sich negativ auf das App Ranking im jweiligen Store auswirken kann.

Bildmaterial: Designed by slidesgo / Freepik