Android 13 sur votre stratégie CRM Mobile : ce qu’il faut retenir et mettre en place

Événement dans notre écosystème CRM Mobile : avec la sortie Android 13 le 15 août dernier, Android s’est enfin mis au niveau d’Apple iOS en termes de gestion du consentement des notifications push.

Pour tout responsable CRM Mobile, cela n’est pas sans conséquence sur l’évolution de leur base Opt-In Push, et surtout sur la manière de l’animer.

Pas de panique ! On vous détaille toutes les implications métier de cet “Android 13 effect” et on vous partage les bonnes pratiques pour saisir les opportunités - car il y en a - de ces nouvelles règles du jeu.

Suivez-nous !

Android 13 : des effets qui varient selon le segment de votre base opt-in

Pour comprendre les premiers changements de façon pragmatique, on vous propose une grille de lecture qui se calque sur les trois segments de la base d’opt-in :

• Effet n°1 : Nouveaux utilisateurs
• Effet n°2 : Utilisateurs existants
• Effet n°3 : Utilisateurs inactifs

Effet n°1 : sur les nouveaux utilisateurs

C’est le cas le plus important, avec l’arrivée d’une demande d’autorisation (ou d’opt-in) pour chaque application qui souhaite afficher des notifications à un utilisateur.

En somme, à partir d’Android 13, tous les nouveaux utilisateurs auront les notifications désactivées par défaut (ils sont “opt-out”). En effet, Google adopte un mécanisme connu et bien maîtrisé depuis des années par les marketers sur iOS.

C’est cependant un changement majeur sur Android, à double titre :

• Premièrement pour les utilisateurs qui découvrent une nouvelle demande d’autorisation système.
• Deuxièmement, et c’est une surprise pour les marketers, qui découvrent que leurs base ne sera plus ciblable à 100% à partir d’Android 13.

Est-ce vraiment une surprise ? Pas vraiment, et ce pour deux raisons :

1. Android était la dernière plateforme à ne pas demander de permission pour les notifications push à l’inverse de ce qui existait sur iOS ou pour le push Web.
2. Depuis Android 11, Google sensibilise les utilisateurs sur les droits accordés aux applications et les données que ces applications collectent. Les notifications étaient le dernier aspect qui n’avait pas encore été traité par Google.

Que peut-on dire de cette nouvelle demande ?

• Elle n’est affichable qu’une seule fois.
• Son aspect n’est pas personnalisable.
• Son déclenchement est en revanche scénarisable et Google préconise d’intégrer la demande au sein d’un onboarding qui la contextualise.

Heureusement, vos utilisateurs existants n’auront pas à redonner à votre app le droit de leur afficher des notifications. Google a en effet prévu ce scénario, notamment pour le second cas qui suit.

Effet n°2 : sur les utilisateurs existants

Pour les utilisateurs existants qui mettent à jour vers Android 13, bonne nouvelle : les applications installées avant mise à jour conservent le droit d’afficher des notifications.

Une suggestion système sera tout de même affichée après la mise à jour. Elle permettra simplement aux utilisateurs de consulter leurs choix d’opt-in push actuels et, éventuellement, de les revoir.

Effet n°3 : sur les utilisateurs inactifs

Depuis Android 11, Android réinitialise automatiquement les permissions des applications après une longue période d’inactivité, notamment pour la géolocalisation.

À partir d’Android 13, les notifications seront aussi concernées par cette réinitialisation automatique.

À partir de combien de temps d’inactivité les permissions sont-elles réinitialisées ? Impossible à dire. Les règles exactes sont à date, et le resteront certainement, du côté de Google.

Android 13, c’est désormais une nouvelle demande d’autorisation obligatoire

Le premier effet visible d’Android 13, c’est évidemment l’apparition de cette nouvelle demande d’autorisation.

Pour les apps optimisées pour Android 13, le déclenchement de la demande est scénarisable.

Pour les apps qui ne sont pas encore optimisées pour Android 13, votre app peut déjà afficher la demande d’opt-in push. Seul inconvénient : vous ne pouvez pas contrôler le moment où cette demande apparaît.

Cette demande d’autorisation s’opère dans deux cas de figure, qui dépendent entièrement des choix techniques faits par vos développeurs :

1. La demande est immédiatement affichée dès l’ouverture de l’application.
2. L’affichage de la demande est différé Elle est déclenchée après la première session. Il s’agit de la majorité des cas.

Développons brièvement ces deux cas :

Cas n°1 : l’affichage de la demande est immédiat

Et ce dès la première session, au moment où l’application déclare au système les types de notifications à gérer. C’est le moment où elle enregistre les “channels”.

Principal avantage : la demande est affichée dès la première session, ce qui vous autorise à recontacter les utilisateurs inactifs par la suite.

Principal inconvénient : la demande peut-être affichée au-dessus d’un écran de connexion à un compte, de la modale de consentement RGPD… sans plus de contexte, ce qui n’est pas optimal.

Cas n°2: l’affichage de la demande est différé

L’application ne va pas enregistrer les notifications auprès du système dès la première ouverture. Cela n'entraînera donc pas l’affichage de la nouvelle demande d’autorisation push.

Elle ne le fera qu’à réception de la première notification, en arrière plan. Le premier push envoyé à l’application ne sera jamais affiché, car l’app n’en a pas encore le droit. Ce n’est qu’à l’ouverture suivante que la demande d’autorisation push sera affichée.

Ici, deux inconvénients majeurs :

1. Les utilisateurs ne seront joignables que s' ils réouvrent l’application, ce qui n’est pas garanti.
2. Vos parcours d’onboarding, non reçus, n’auront aucun effet si l’utilisateur ne revient pas dans l’app pour activer les notifications.

Ici, il y a besoin d’un effort conjoint de nos équipes Solutions Engineers et de vos équipes techniques pour mettre à jour votre app et bien gérer le moment où la demande est déclenchée.

En somme, comme on va le voir plus tard dans l’article, il est indispensable d’optimiser votre app pour contrôler l’expérience d’opt-in propre à Android 13. C’est la seule manière de mettre toutes les chances de votre côté pour collecter un opt-in push auprès de vos utilisateurs.

Les nouvelles règles du jeu Post-Android 13 : savoir animer une base opt-in réduite, mais bien plus qualifiée

Pour comprendre l’impact d’Android 13 sur les stratégies CRM Mobile, reprenons notre grille de lecture des différents segments de la base opt-in.

Nouveaux utilisateurs : Le taux d’opt-in sur Android va probablement s’aligner sur celui d’iOS (aux alentours de 50%). Ici, l’enjeu sera double : limiter la baisse des opt-in et saisir l’opportunité d’avoir une audience plus qualifiée

Utilisateurs actifs : La base d’opt-in existante sera seulement préservée pour les utilisateurs actifs. C’est une opportunité pour s’adresser à une base d’utilisateurs engagés, et d’améliorer les parcours de réengagement et de réactivation pour maintenir les utilisateurs actifs.

Utilisateurs inactifs : On a tout intérêt à combiner les différents canaux in-app et hors app (push, web, email) dans des parcours multi-canaux les plus personnalisés possible afin de s’assurer de joindre efficacement les inactifs pour les réengager.

Prenez les devants, adaptez-vous à Android 13 pour en faire votre avantage concurrentiel

Vous l’aurez compris à ce stade de l’article : l’impact d’Android 13 est conséquent, et il comporte des risques pour vos performances CRM si vous n’adoptez les bons dès maintenant.

Ces bonnes pratiques ne vont pas juste minimiser les risques d’Android 13, elles vont transformer cette mise à jour en avantage compétitif pour votre stratégie mobile, l’enjeu est de vous y mettre dès à présent.

Android 13 est déjà sorti, depuis le 15 août dernier. Du côté d’Android 12, seulement 13,5% des appareils ont la mise à jour. Cela peut paraître peu.

En revanche, si on se base sur le rythme de déploiement des versions précédentes, on peut estimer qu’on aura au moins 200M d'appareils actifs sur Android 13 dans les 6 prochains mois.

Pour vous donner une idée un peu plus précise des évolutions de notre écosystème vers Android 13, on vous partage rapidement ce planning prévisionnel des différentes sorties, qui sont extraites de cet article d’Android Authority.

Se préparer et s’adapter à Android 13, au niveau technique et dans vos tactiques CRM

Alors qu’est cela veut dire concrètement, être prêt pour Android 13 ? Cela signifie une double mise à jour :

D’une part une mise à jour technique de votre App et du SDK de Batch, et d’autre part de mettre en place des nouvelles tactiques CRM dans votre parcours client / utilisateur :

• Tactique n°1 : Inclure l’opt-in push dans votre séquence d’onboarding dans l’application
• Tactique n°2 : Re-demande d’opt-in via les campagnes In-App de Batch

Tactique CRM n°1 : Inclure l’opt-in push dans votre séquence d’onboarding. Il s’agit d’une pratique sur laquelle nous conseillons aussi nos clients.

Elle est largement répandue sur iOS : pour beaucoup d’entre vous, vos développeurs n’auront qu’à reprendre sur Android les parcours qu’ils ont déjà conçus pour iOS.

Quelques exemples dans différentes verticales. Les clés du succès :

1. Démontrer la valeur de la notification (ex : rappel des détails de votre voyage, information en temps réel comme le fait SNCF Connect).
2. Choisir un timing pertinent pour l’utilisateur (à l’onboarding ou après un événement significatif - comme la connexion à un compte, comme le fait Showroom Privé).
3. Rassurer l’utilisateur sur ce qu’il va recevoir pour qu’il se projette, avec des exemples (comme le fait Radio France).

Pour approfondir cette tactique CRM d’onboarding, on vous invite à parcourir notre guide détaillé de notre Help Center.

Tactique CRM n°2 : Utilisez les messages In-App pour convaincre les utilisateurs qui ne sont pas encore opt-in d’activer les notifications.

Cette campagne In-App fait partie du “starter kit” que Batch propose à ses clients sur iOS. A titre d’exemple, on vous partage ici ces campagnes de notre client 24S, qui est arrivé début 2022 à ré-engager plus de 20% de son audience opt-out via ces campagnes.

Pour approfondir cette tactique CRM de ré-optin In-App, on vous invite à parcourir notre guide détaillé de notre Help Center.

Mise à jour Android 13 : Batch est bien évidemment avec ses clients

Côté Batch, cela fait depuis plusieurs mois que nos équipes sont prêtes à accompagner nos clients dans leur adaptation - technique et CRM - à Android 13.

Depuis avril dernier, nos équipes Tech/Produit ont sorti une version du SDK de Batch avec un support initial de la demande d’opt-in push Android 13. Puis en août et en septembre, que ce soit au niveau du SDK, des fonctionnalités et de la documentation pour vous accompagner dans la transition vers Android 13.

On espère que cet article vous aura aidé à mieux comprendre les nouvelles règles du jeu d’Android, d’en identifier les enjeux prioritaires pour votre stratégie CRM Mobile pour en adopter les meilleures tactiques.

Android 13 : les questions les plus fréquentes

Au bout de combien de jours les utilisateurs sont-ils considérés comme inactifs ?

“Plusieurs mois” selon la documentation de Google qui ne précise pas le délai exact avant remise à zéro des permissions accordées à l’app (voir documentation).

Une fois que la permission de notification a été révoquée, sera-t-il possible de représenter la pop-in de demande d'autorisation ?

Non. Selon la même documentation de Google, la remise à zéro automatique des permissions accordées à l’app équivaut à un refus.

Ce cas de figure a déjà été anticipé par nos équipes. Vous pouvez dès à présent créer une campagne de message In-App qui ciblera les utilisateurs pour qui les notifications sont désactivées (voir documentation). Au clic sur le bouton du message In-App, Batch détectera automatiquement la situation dans laquelle se trouve l’utilisateur :

• Demande non affichée: la demande sera déclenchée au clic sur le bouton du message In-App.
• Demande déjà affichée ou révoquée par le système : l’utilisateur sera redirigé sur la fiche de votre app vers les paramètres système pour activer les notifications.

Batch détecte-t-il le passage en inactif pour relance en push in-app ?

Oui, le statut d’opt-in modifié sera détecté dès l’ouverture de l’application. L’utilisateur pourra alors voir le message In-App dans son parcours pour réactiver les notifications après plusieurs mois d’inactivité.

Ceux qui sont déjà opt-in sur notre App devront-ils s'optimiser de nouveau s'ils passent sur Android 13 ?

Non, cela ne sera pas nécessaire. Android octroie la permission d’afficher des notifications aux applications déjà installées sur l’appareil de l’utilisateur avant mise à jour vers Android 13. Après la mise à jour, votre application ne devra pas “redemander” l’autorisation d’envoyer des notifications.

L'impact sur ces utilisateurs inactifs va-t-il vous amener à revoir l'algorithme de votre smart segment "DORMANT" ?

L’objectif des Smart Segments est de permettre à tout marketer de comprendre en un clin d'œil comment son audience est répartie par grands segments d’activité utilisateur et de créer simplement des campagnes segmentées. Cette fonctionnalité de segmentation se base uniquement sur le comportement des utilisateurs. Elle est utilisable pour tous les canaux de communication qu’offre Batch (notifications push et message In-App) et n’est donc pas corrélée à un état d’opt-in.

Je n’ai pas compris pourquoi il fallait mettre à jour le SDK. Si j’ajoute la question d’optin / optout dans mon onboarding, pourquoi mettre à jour le SDK ?

Parce que pouvoir supporter complètement Android 13 et scénariser le déclenchement de la demande d’autorisation push, il faut absolument deux mises à jour :

1. Configurer votre projet Android pour prendre en charge les nouveautés d’Android. Pour vos développeurs, cela correspond à “targeter l’API 33”.
2. Mettre à jour le SDK de Batch vers la version 1.19.2. Cette version ajoute une action ou “méthode” que vos développeurs pourront appeler dans le code de votre app pour déclencher la demande d’autorisation push au moment souhaité.

Ces deux modifications sont simples à réaliser et peuvent être faites dans la même mise à jour à déployer sur le PlayStore.

Est-ce que comme pour le système iOS, nous n’avons droit qu’à une seule chance pour afficher la permission système Android ?

Oui, Android reprend le même mécanisme de demande d’autorisation push qui existe sur iOS. Les mêmes mécanismes existants et peut être déjà appliqués dans votre app iOS pourront être réutilisés à savoir :

• Mettre en place un écran de pré-demande pour présenter la demande système dans le cadre de votre onboarding par exemple.
• Mettre en place une campagne In-App de re-optimisation à destination des utilisateurs qui auraient refusé les notifications ou dont la permission aurait été remise à zéro par le système après plusieurs mois d’inactivité.