Vous avez peut-être entendu dire qu'Apple apportait des modifications à ses règles de suivi des utilisateurs, qui auront une incidence sur l'utilisation des identifiants d'appareils dans iOS 14. Si vous n'utilisez pas le suivi à des fins publicitaires, ces nouvelles politiques ne vous concerneront pas. Et comme les données collectées par le service d'analyse de Brightcove sont anonymes et ne sont pas partagées entre les éditeurs, elles ne sont pas soumises aux nouvelles règles d'Apple.
Mais voyons ce qui change et ce que vous devez savoir en tant qu'éditeur d'applications.
QU'EST-CE QUE L'IDFA ?
L'IDFA est l'identifiant d'Apple pour les annonceurs, une chaîne d'identification unique qui identifie un appareil particulier. Il est utilisé de différentes manières, mais la plus courante est la prise en charge de la publicité personnalisée. Imaginons que j'aie ouvert l'application de ma chaîne de restaurants locale préférée, mais que je n'aie rien acheté. J'ouvre ensuite l'application de mon éditeur de presse local et commence à regarder une vidéo. Lorsque l'application va chercher un preroll publicitaire, elle transmet l'IDFA de mon appareil et la chaîne de restaurants peut choisir de payer un peu plus pour diffuser une publicité sur son dernier repas à prix réduit. Tout le monde y gagne : l'annonceur touche une personne plus susceptible d'effectuer un achat, l'éditeur est payé plus cher pour le preroll et je vois une publicité qui me concerne vraiment.
Mais ce même mécanisme peut devenir un peu effrayant. L'industrie a tendance à s'éloigner du partage de ce type de données sans plus de transparence, et la dernière initiative d'Apple est un moyen de promouvoir la protection de la vie privée par défaut.
QU'EST-CE QUI CHANGE ?
Avec iOS 14, si une application n'obtient pas la permission explicite de fournir l'IDFA de l'appareil sur lequel elle se trouve, elle n'obtiendra pas quelque chose d'unique. (Cette nouvelle politique entrera en vigueur au début de l'année 2021.) Cela n'entraînera pas d'échec, mais empêchera l'annonceur de voir qu'une demande de publicité provient d'un appareil auquel il souhaite vendre, ce qui rompt la chaîne de valeur.
Apple apporte une modification essentielle à cet égard, avec une nouvelle API permettant de demander l'autorisation de l'IDFA. Cette autorisation ne doit être demandée qu'une seule fois pour chaque application, et l'utilisateur peut la modifier à tout moment dans les réglages (de la même manière que l'autorisation de géolocalisation est désormais gérée). En tant qu'éditeur d'applications, vous devez expliquer à vos utilisateurs pourquoi vous leur demandez ces informations - la valeur de la personnalisation des publicités. Le simple fait d'afficher le dialogue du système lorsqu'un utilisateur ouvre l'application pour la première fois est un moyen sûr d'obtenir un grand nombre de désistements. (Surtout si vous demandez en même temps des autorisations de localisation).
Pour les clients utilisant le SDK iOS natif de Brightcove, nous avons ajouté la prise en charge de l'API opt-in/out au niveau du système d'exploitation, ainsi que le dernier SDK IMA de Google (v3.12.1). Sans l'intégration de cette API, toutes les requêtes pour l'IDFA sur iOS 14 - quelle que soit la préférence de l'utilisateur - auront une valeur de 0, comme si l'utilisateur s'était désengagé. Cette mise à jour permet aux développeurs d'accéder à l'IDFA dans la mesure du possible. Vous trouverez cette mise à jour dans la version 6.7.12 du SDK iOS que nous publierons en septembre, avec une compatibilité totale avec l'iOS 14.
QU'Y A-T-IL D'AUTRE ?
L'IDFA a été conçu pour la publicité personnalisée, mais il a également été utilisé à d'autres fins pour lesquelles Apple propose des alternatives.
Si un éditeur d'applications dispose d'un réseau d'applications mais n'identifie pas lui-même les utilisateurs (par exemple, par le biais d'un login), il peut accéder à un IDFV (Identifier for Vendors), qui est structuré comme un IDFA mais qui n'est unique que pour les applications de cet éditeur. Il ne peut donc pas être utilisé pour partager un identifiant entre un éditeur de nouvelles et le restaurant, mais il permet à un éditeur de suivre les habitudes de visionnage d'un utilisateur à travers les différentes applications de son propre réseau. (Il n'est pas nécessaire que l'utilisateur accepte de participer).
Un autre cas d'utilisation courant est l'attribution des installations d'applications - les IDFA sont utilisés pour identifier les renvois entre les applications qui pourraient être renvoyées dans l'App Store. Apple a fourni une nouvelle API StoreKit (SKAdNetwork) pour prendre en charge ce cas d'utilisation particulier qui ne nécessite pas non plus l'accord de l'utilisateur final.
LES ÉDITEURS DOIVENT-ILS S'INQUIÉTER ?
Personne ne le sait vraiment. Apple a fourni aux utilisateurs un moyen de se désengager de l'IDFA depuis iOS 7 en 2013, mais ce moyen est enfoui dans les réglages et n'a donc jamais été utilisé.
À l'autre extrême, Safari ayant rendu de plus en plus difficile l'utilisation de cookies tiers, les éditeurs ont constaté que la demande des annonceurs (et donc les revenus) avait chuté. La modification apportée par l'IDFA ne va pas aussi loin, de sorte que si vous envisagez de déployer une application native, vous pouvez encore la monétiser plus efficacement que vous ne pouvez le faire avec le web mobile sur iOS.
Il est probable qu'elle se situe quelque part entre les deux. Il sera certainement utile d'encourager les utilisateurs à s'inscrire et d'expliquer l'intérêt d'obtenir des publicités pertinentes. Par ailleurs, les éditeurs devraient chercher d'autres moyens d'exploiter leurs propres données de première ou de seconde partie afin de maximiser la valeur de leur inventaire.
