U bent hier

De Mobiele wereld meetbaar maken met Google App Analytics

Het digitale landschap is in de laatste 2 jaren veel veranderd. Wanneer we in 2013 mensen hadden gevraagd naar hun meest gebruikte apparaat om te internetten had 74% gezegd dat het een laptop of een desktop is.
In 2015 op dezelfde vraag komt er een heel ander antwoord. Nu gebruikt nog maar 48% van de mensen een laptop of een desktop. De overige 52% is via een smartphone of een tablet.

Alleen voor het meten met Google Analytics hebben we hierdoor een probleem. Maar 16% van het gebruik van een smartphone is in een browser t.o.v. 86% in apps.
We kunnen dus nu 14% van het gebruik meten, maar hoe meten we de overige 84%. Dat is het onderdeel wat we vandaag bespreken.

Op zichzelf zijn smartphones een onderdeel van een digitale marketing strategie en gebruiken we een website en het internet om uitleg over de app te geven en gebruikers in te laten loggen. Maar hoe kunnen we dit meten?

 

Velen van ons zullen dan in de eerste plaats direct aan Google Analytics denken, maar hoe gaat dit te werk? Want het importeren van Analytics.js in een app zal niet zomaar gaan en veel overbodige informatie teruggeven.

Leer code te begrijpen en de verschillen in Operating Systems

Dus wanneer we geen Analtyics.js kunnen gebruiken, wat kunnen we wel gebruiken?
Voor iOS kunnen we ObjectiveC en Swift Code SDK's gebruiken. Voor het Android platform kunnen we een Java SDK gebruiken.

Objective C en Swift zijn de programeertalen van Apple en Java wordt door Google in Android gebruikt.

We beginnen met de GA Framework integratie:

  • iOS: Via App Delegate wordt de Tracking ingeladen
  • Android: De tracking wordt via de Manifest.xml ingeladen

Elk scherm moet daarnaast een instatantie hebben van de Google Analytics.

  • Elk scherm moet benoemd worden in de code, er is geen URL waar je aan vast kan houden.
  • Dit is voor Android en iOS hetzelfde

Belangrijke acties van de gebruikers worden Events genoemd, dit kan een bepaalde knop zijn maar ook handeling of scherm.

De e-commerce functie binnen apps worden op verschillende mogelijkheden gebruikt. Ten eerste wordt deze via functies aangeroepen. Daarnaast kan deze tracking gebruikt worden voor:

  • Transacties om fysieke goederen te kopen
  • In-App purchases of aankopen van digitale goederen.

Tussen deze zit een verschil in gebruik voor de ontwikkelaar en ook bijvoorbeeld hoeveel men moet afstaan aan Apple of Google.
In het kort: Fysieke goederen: Niks afstaan, Digitale goederen wordt er een comissie voor verrekend.

 How to deal with data dispatch

Data wordt niet direct verstuurd maar elke X minuten. Dit komt doordat een app niet altijd toegang tot hebben tot het internet.

Er zijn een aantal punten die we in het achterhoof moeten houden:

  1. Alle data is opgeslagen in App
  2. Data moet binnen 4 uur binnenkomen na het verlopen van een dag om het binnen de dagperiode te laten registreren.
  3. Standaard wordt de data elke 2 minuten voor iOS en elke 30 minuten voor Android doorgestuurd.
    1. Binnen Android wordt het een onderdeel van Google Play
    2. Indien een App offline is, wordt de data doorgestuurd op het moment dat de app online komt. Indien het langer duurt dan de 4 uur na de dag, wordt de data op een andere datum erin geschoten.

The setup and best practices

Een aantal basis best practices voor GA om geen rotzooi van je Analytics installatie te maken:

  • Elke App een eigen property
  • Elk Operating system eigen property
  • Grote verschillen tussen apps ook in verschillende properties zetten (bijvoorbeeld Pro en light versies)

Cross device tracking en het verschil tussen UsersID en Advertisers ID.

Wanneer je over Cross device hebt en Advertisers ID is het belangrijk om een aantal punen apart te zetten.
Ten eerste, wat is een Advertisers ID en wat is een UserID? Ten tweede voor wat kan je ze gebruiken en ten laatste wat is het effect op de gebruiker.

 

Verschil tussen Advertisers ID en User ID:

Een Advertisers ID: Unieke ID van de App / Device. Deze wordt automatisch aangemaakt, hetzelfde als een usersID in de browser. Het verschil alleen is dat de UsersID is per device en niet per browser.

  • Advertisers ID kan gebruikt worden voor bijvoorbeeld remarketing, Demographics & Interest reports
  • Hieraan is geen persoonlijke informatie gekoppeld en kan ook hiervoor niet worden gebruikt.
  • Binnen iOS wordt dit over het gehele systeem gebruikt door de AdSupport Binary en kan gereset worden door de gebruiker.

Users ID worden apart bijgehouden en kunnen pas worden gebruikt op het moment dat een gebruiker is ingelogd. Het principe is het zelfde als een standaard Cross device tracking optimalisatie en de data van de Apps kan worden bijgehouden samen met de ingelogde website bezoekers.

 

Alle mogelijkheden van Cross Device tracking zijn hierop van toepassing, er wordt binnen deze view alleen gebruikt gemaakt van de ingelogde gebruiker.

Privacy

Let op, omdat je hier informatie aan het bijhouden bent van een gebruiker en je het meest persoonlijke device gebruikt, is het heel belangrijk om de gebruiker van alle persoonlijke informatie op de hoogte te stellen.

Voor een gebruiker is het moelijker om zijn gegevens te verwijderen van een smartphone dan van een browser.

Daarnaast met de mogelijkheden van een iCloud Sync of een Android Sync is het mogelijk om alle data over te brengen naar een andere device. Ook inlognamen en wachtwoorden.

Klant data voorbeelden

Wanneer je dus de bovenstaande informatie hebt, hoe kan je deze gebruiken in je Analytics?

Naast de standaard gegevens die je kan gebruiken zijn klanten gegevens die het extra krachtig maken. Dit is naast de standaard Analytics tracking kan je met datalayers en custom dimensions de App marketing veel verder trekken.

Een aantal voorbeelden die wij gebruikt hebben voor klanten zijn:

  • Leeftijd opgegeven zoals in het CMS
  • Eerste kanaal van aanmelding
  • Totale waarde van de klant in geval van een crash van App
  • Datum van opzoeking van route en realistisch fietsen van route
  • Voorkeuren van de klant binnen type fietsroutes.

 

Met deze onderdelen die je als een aparte dimensies binnen de Analytics schiet krijg je een beeld voor wat je app gebruikt wordt door de klant en kan je de app hiervoor ontwikkelen.

Het bijhouden van crashes.

Een app werkt niet altijd 100% en het kan zelfs in de beste app gebeuren dat er iets misgaat. Hierdoor krijg je een crash te verwerken en zal de gebruiker opnieuw de app op moeten starten, met de vele kenbare frustraties tot gevolg.

Maar hoe kunnen we nu omgaan met deze crashes? Dit kunnen we heel goed volgen in de analytics.

  • Crashes worden opgeslagen in CoreData, volgende keer datapp wordt geinitialiseerd wordt doorgestuurd naar Google Analytics. Let op, het is dus wel belangrijk dat A, er is de volgende keer een internet verbinding en B, de app wordt opnieuw gebruikt
  • Er is een verschil tussen een fatale crash en een niet fatale exception, dit is meetbaar in Analytics. Een fatale crash heeft tot gevolgd dat een App stopt en de gebruiker terug naar het hoofdmenu wordt gebracht. Een niet fatale exception is wanneer de app bruikbaar blijft, misschien niet 100% functioneerbaar maar wel bruikbaar.
  • Aan deze informatie kunnen we ook een segmenten en dimensies te kopellen, bijvoorbeeld om gebruikers gegevens hieraan te koppelen. Ik heb een aantal voorbeelden hieronder gezet:

Mobile Campaign tagging: How and why

Mobile campagne tagging is niet zo eenvoudig als op de website. Voor dat je begint hebt je de volgende onderdelen nodig:

 

Voor iOS:

  1. Analytics integratie met Pagetracking en / of event tracking
  2. iOS campaign tracking enabled
  3. iOS App id set (link naar custom report voor Google Analytics)
  4. Identifier voor Advertiser wordt meegezonden

Op de volgende pagina heb je een link om de implementatie goed te controleren: https://developers.google.com/analytics/devguides/collection/ios/v3/campaigns

*Let op: *

  • Er wordt altijd om een Ad network gevraagd, deze kan je standaard op Others zetten.
  • Device ID macro is de Identifier voor Advertiser, standaard op %{idfa})

De totale stappen voor de tracking aan een url te koppelen zijn:

  • UA Code
  • Een Ad netwerk
  • Redirect URL (The iTunes Web URL)
  • App ID
  • Device ID Macro (Identifier for Advertisers)
  • Source, etc.

Voorbeeld: https://click.google-analytics.com/redirect?tid=UA-324109-49&url=https%3A%2F%2Fitunes.apple.com%2Fnl%2Fapp%2Fdrogisterij.net-mobiel%2Fid506652686&aid=com.drogisterijnet.drogisterijnet&idfa=%{idfa})&cs=GAUC&cm=link&cn=Presentation

 

Voor Android:

  1. Google Analytics SDK integratie.
  2. Google analytics receiver aan de AndroidManifest.xml bestand
  3. Referrer parameter aan de url´s toevoegen voor tracking.

Link om het controleren: https://developers.google.com/analytics/devguides/collection/android/v4/campaigns#google-play-url-builder

Let op:

  • App downloads via Adwords heeft automatische tagging via GCLID parameter
  • Het is belangrijjk om de Google Analytics receiver aan je AndroidManifest.xml te koppelen.
  • Daarnaast is het nodig om een referrer parameter mee te geven die een indicatie aan de Google Play Store geeft dat de tagging mee naar de app moet worden genomen. Hierdoor kan Google Analytics deze implementeren.

De totale stappen voor de tracking aan een url te koppelen zijn:

  • Ad Network
  • Package Name (From the Play Store)
  • Source, etc.

Voorbeeld: https://play.google.com/store/apps/details?id=net.drogisterij.bezorgservice&referrer=utmsource%3DGAUC%26utmmedium%3Dlink%26utm_campaign%3DPresentation

Customer lifetime + Voorbeelden

De customer lifetime value geeft precies aan wat het zegt. Wat is de waarde van de klant over de periode van 90 dagen binnen in de app. Hiermee kan je de waarde van de nieuwe gebruiker een beter beeld geven.
DIt in combinatie met de kosten import in Analytics kan je ook makkelijker de ROAS van je campagnes en App installs campagnes.

Daarnaast kan je ook zien waar de kruising zit tussen bijvoorbeeld het aantal transacties / opgrengst en de sessieduur / App weergeven per gebruiker.

Een nieuwe functie die hierin ook verborgen is, zijn het aantal dienstjaren van een gebruiker:

Het aantal gebruikers dat een bepaalde gebruikersleeftijd bij uw bedrijf heeft bereikt, berekend vanaf de datum van de eerste sessie tot de huidige datum, gemeten in dagen, weken of maanden.
Als de eerste sessie van een gebruiker bijvoorbeeld op 1 januari plaatsvond en het vandaag 28 januari is, dan is de gebruikersleeftijd van die gebruiker 28 dagen, 4 weken of 1 maand.

4 tips om direct mee te beginnen

  1. Leer een stukje code en volg de laatste ontwikkelingen van Android en iOS op de voet. Over het algemeen is er een jaarlijkse cyclus met nieuwe mogelijkheden die je kan gebruiken om te tracken.
  2. Gebruik cross device tracking om de gebruiker te tracken op App en website niveau.
  3. Gebruik geavanceerde segmenten en de Crashviews om snel je marketing op af te kunnen stemmen en informatie naar de ontwikkelaars te geven.
  4. Maak gebruik van App deep linking en de tracking die hieraan hoort.

Reactie toevoegen

You must have Javascript enabled to use this form.

Neem direct contact met ons op

You must have Javascript enabled to use this form.