Mesurer son volume de porteurs d’application peut rapidement s’avérer complexe.
En effet, il existe différentes méthodes de comptabilisation entre les plateformes (iTunes Connect et Google play) et les SDK de tracking (Appsflyer, Adjust…) ce qui peut entrainer des écarts.
Les méthodes de comptabilisation de porteurs d’app par source
D’un côté iTunes Connect raisonne au user et plus particulièrement au nouvel ID Apple en terme d’installations. C’est-à-dire que chaque nouvel ID Apple sera comptabilisé comme une install mais une personne qui changera de téléphone (en conservant son ID Apple) ne sera pas recomptabilisée.
D’un autre côté, Google play prend en compte les installations en fonction du device. Les « nouveaux téléchargements » concernent les nouveaux devices uniquement tandis que « tous les téléchargements » prennent en compte les nouveaux devices ainsi que les réinstallations de plus de 30 jours.
Appsflyer (SDK d’attribution) raisonne également au device et prend en compte les nouveaux devices ainsi que les réinstallations de plus de 90 jours à partir de la date d’installation du SDK. Ce n’est pas le cas d’Adjust qui passe ces réinstallations en réattributions.
Les méthodes de comptabilisation n’étant donc pas les mêmes selon les plateformes, cela explique en grande partie les écarts de nombre de porteurs d’app entre toutes ces sources d’analyse.
Dès lors comment bien comptabiliser les installations quand on sait que Google Play raisonne au device et Apple à l’individu ? Comment connaître la volumétrie de porteurs d’application si votre SDK d’analytics n’est intégré que depuis 12 mois ?
Autant de questions importantes et décisives à prendre en compte pour votre business !
Plusieurs autres facteurs peuvent également justifier des décalages.
- Les SDK de tracking (Appsflyer, Adjust…) comptabilisent les téléchargements qui ont généré au moins une première ouverture là où Apple et Google comptabilisent l’ensemble des profils ayant téléchargé l’application sur leur device.
- La proportion de personnes qui changent de device augmente avec le temps creusant l’écart sachant qu’en moyenne un utilisateur change de device une fois tous les 18 mois
- De la même manière si un user décide de réinitialiser son IDFA ou GAID (numéro d’identification unique du terminal crypté) et ouvre à nouveau l’application, cela sera comptabilisé comme un nouveau téléchargement du côté des SDK de tracking à l’inverse d’iTunes Connect et Google Play qui ne le comptabiliserons pas une nouvelle fois.
- La fraude est un sujet qui n’est pas traité dans la comptabilisation des stores contrairement au SDK si l’outil anti-fraude est activé.
- La fenêtre d’attribution peut être différente entre le SDK de tracking et les plateformes d’où la nécessité de la faire coïncider entre les deux.
- L’attribution au last click est différente en fonction des sources. Il peut arriver qu’un utilisateur clique sur une publicité Apple par exemple suite à laquelle il installera l’application mais ne l’ouvrira pas tout de suite. Puis cet utilisateur va cliquer sur une publicité différente et finalement ouvrir l’application. Dans ce cas le SDK attribuera l’installation au dernier clic alors qu’Apple revendiquera l’installation.
- Le LAT (Limited ad tracking) ou SPL, c’est à dire les utilisateurs ayant activé le suivi publicitaire limité, ne sont pas comptabilisés par les SDK. Pour donner un ordre d’idée, il est estimé qu’au moins 12% des utilisateurs iOS ont le LAT d’activé sur leurs périphériques.
Pourquoi les actions medias renforcent la perturbation du modèle ?
Le media contribue à générer des installations mais également des réinstallations d’app. Par exemple via les méthodes Lookalike sur Facebook qui sont basées sur les users. Dans ce cas il y a une forte probabilité que le ciblage identifie des porteurs de l’app inactifs depuis longtemps et/ou ayant désinstallé l’application. C’est le même principe sur Apple ; 30% à 60% des installations générées via Apple Search Ads sont des réinstallations d’un user ayant changé de device et /ou supprimé l’app selon Apple.
Comment piloter au mieux les campagnes et minimiser ces écarts ?
Les nombreux facteurs et variables évoqués, combinés ensemble créent des écarts importants.
En effet, les méthodes de calculs sont si différentes d’une plateforme à une autre qu’il est insensé de les comparer. Nous recommandons donc plutôt d’utiliser ces deux systèmes à des fins différentes.
Ainsi, il faut adapter la méthode de comptabilisation en fonction du type de besoin.
Le pilotage media et opérationnel, doit être suivi sur le SDK de tracking qui permet de piloter au quotidien les investissements. En parallèle, il est important de se prémunir de l’outil anti-fraude proposé directement par le SDK d’attribution pour une gestion affinée de la fraude et une restitution précise de la data.
Pour la partie reporting interne et suivi de l’évolution des apps dans la durée, il est préférable de choisir une source de données stable dans le temps, homogène et qui reste comparable entre les OS.
Notre recommandation est alors de choisir entre le SDK, Google Analytics – ou équivalent – ou une solution de push.
Une fois cette source déterminée, il faut dès lors ne plus comparer les données entre elles.
Pourquoi faire appel à Ad4Screen ?
Nos experts Ad4screen mettent à votre service leur expertise sur le sujet et sont directement en relation avec les plateformes et SDK de tracking afin de minimiser le taux de déperdition. Nous mettons en place des ajustements, au sein des campagnes elles-mêmes et sur les différentes plateformes pour minimiser ces écarts. Le but étant d’assurer le meilleur suivi possible des performances et répondre aux mieux aux objectifs fixés.
