Qu’est-ce qui ne tourne pas rond avec l’In-App Purchase ?

Share on facebook
Share on linkedin
Share on twitter
Share on email
Dans cet article, nous vous faisons un retour d'expérience sur la mise en place de l'In-App Purchase et des Abonnements In-App en particulier. Forts de près de 10 ans d'expérience sur le sujet (on faisait partie des tous premiers), et après l'avoir implémenté pour des clients comme Eurosport, M6, Molotov, The Explorers, Les Inrocks, ou encore Les 24h du Mans, nous vous proposons un petit survol des difficultés qui vous attendent si vous souhaitez vous lancer !

Les abonnements In-App : le cauchemar du développeur

S’il y a bien un sujet qui met tout le monde d’accord, c’est le fait qu’intégrer les abonnements In-App sur mobile, est un véritable cauchemar ! Les messages de développeurs s’arrachant les cheveux sur les forums spécialisés fleurissent ici et là : non seulement gérer le cycle d’un abonné est complexe (particulièrement sur l’App Store), mais en plus le mode de fonctionnement est radicalement différent entre iOS et Android.

En plus d’un travail relativement fastidieux à faire côté App, il faut intégrer le backend avec l’App Store et le Play Store pour récupérer les modifications et annulations d’abonnements. Chaque store mobile propose sa propre documentation (assez indigeste et difficile à intégrer dans l’ensemble) mais évidemment, aucun n’explique comment mettre en place un système cross-plateforme, compatible avec les 2 stores. Ce travail s’apparente parfois à mettre des ronds dans des carrés et en conséquence, la stack technique mise en place pour gérer les abonnements aboutit à la création de silos indépendants… avec 2 des process spécifiques, des APIs spécifiques et un impact important sur l’expérience utilisateur, sur le cycle de vie des abonnés et sur la maintenance du système par l’équipe tech.

Pour complexifier encore le tout, il faut savoir que de nombreux use cases ne peuvent pas être testés en environnement de pré-production (appelé Sandbox chez Apple), ce qui oblige les développeurs à les développer à l’aveugle et à corriger le tir et les immanquables bugs résiduels, une fois le service lancé en production. C’est notamment le cas :

  • des résiliations manuelles par l’utilisateur (cancel)
  • des demandes de remboursement (refund)
  • des erreurs de facturation (unpaid / expired card)
  • des parcours utilisateurs de validation d’une augmentation de prix de l’abonnement (price increase consent)
  • des parcours de validation d’achat par les parents pour les mineurs (deferred payment)

Ajoutons à cela un fonctionnement erratique de l’environnement Sandbox d’Apple (un coup ça marche, un coup ça ne marche plus) et la coupe est pleine pour nos amis développeurs 🤯

D’expérience, implémenter correctement les abonnements In-App de bout en bout sur iOS et Android nécessite une charge d’au moins 10 jours par plateforme mobile et 30 côté backend. L’intégration prend ainsi 2 à 3 mois avant de sortir de terre. On parle ici d’une implémentation des fonctionnalités de base permettant l’encaissement, l’annulation et le renouvellement d’un abonnement. Sont laissés de côté dans cette implémentation initiale tous les développements permettant d’améliorer la rétention, telles que les notifications server-to-server.

Un calcul très simple permet d’évaluer combien cela vous coûterait si vous souhaitiez vous lancer dans ce nouveau business très lucratif :

7000 € chargés par développeur / mois pour 60 jours 
= 17 500 €

En vendant un abonnement 10€ / mois, auxquels il faut retrancher la TVA (20%) puis les 30% de frais de services, pris par Apple et Google pour distribuer votre service, et avec l’hypothèse que vos utilisateurs resteront 2 mois en moyenne, abonnés à votre service, il vous faudra donc convertir au minimum 1100 abonnés pour rentrer dans vos frais ! Et encore, nous prenons ici l’hypothèse très peu réaliste que l’acquisition des utilisateurs est 100% gratuite, ce qui n’est bien entendu pas le cas !

Gain par abonnement : 10€ - TVA (2€) - fees (2,4€) = 5,6€ / abonné / mois
17 500 euros / 5,6 * 2 mois en moyenne = ~1500 abonnés

En dehors de cet investissement important, la mise en place de cette fonctionnalité mobilise de nombreuses ressources (produit / marketing / juridique), qui vampirisent véritablement toute la roadmap de l’entreprise et sont autant de coût cachés.

Conséquence : les startups passent au final plus de temps à développer la brique qui leur permettra de vendre des abonnements, que les fonctionnalités incluses dans l’abonnement en tant que telles. Un comble !

Le pire étant qu’en 3 mois, n’est faite généralement que l’implémentation des fonctionnalités basiques :

  • ❌ pas notifications server-to-server pour mettre à jour le statut de l’abonnement en temps réel
  • ❌ pas de gestion des offres de rétention pour retenir les abonnés (subscription offers)
  • ❌ pas de fonctionnalités d’optimisations du funnel de souscription pour améliorer la conversion (a/b tests & lapsed users activation)

À l’issue du développement initial, les équipes se lancent rarement dans ces fonctionnalités additionnelles qui pourtant favorisent la conversion et la rétention.

Les startups matures ont souvent des équipes dédiées au paiement, preuve que le sujet n’est pas un développement one-shot mais bien un investissement constant bien supérieur aux 17 500€ initialement dépensés.

La complexité d’integration représente une véritable barrière à l’entrée…

Les startups, ont la caractéristique commune de devoir tester différents modèles de monétisation pour assurer leur viabilité sur le long terme. Il n’est ainsi par rare de voir des startups se lancer et rechercher leur product market fit, sans se préoccuper dans un premier temps de la façon dont elles généreront les revenus. L’abonnement, la publicité, l’achat ad-hoc sont autant de modèles qu’elles doivent d’explorer avec beaucoup d’agilité pour améliorer leur business model global, de manière itérative. Le temps et l’investissement nécessaires à la mise en place des abonnements In-App ne favorisent donc clairement pas leur adoption.

Quand on implémente des abonnements In-App (et qu’on se lance dans le développement d’une nouvelle application de manière générale), il est très difficile d’estimer le volume d’utilisateurs qui accepteront de payer. Le meilleur moyen est donc de tester. Dans nos expériences respectives, nous avons déjà rencontré :

  • des sociétés qui ne se lancent même pas sur cette voie, faute de certitudes sur ce que pourrait leur apporter le business model de l’abonnement, car l’investissement en temps, ressources et argent est trop conséquent.
  • des sociétés qui procrastinent pendant des mois (voire des années !) l’intégration des abonnements dans leur app, faute de disposer d’une fenêtre de 3 mois dans leur roadmap produit.
  • des sociétés qui choisissent de vendre leurs abonnements “web”, sans passer par les stores, ce qui est strictement interdit : elles jouent avec le feu et prennent donc le risque de se faire bannir si elles se font attraper par l’équipe de review d’Apple ou Google
  • des sociétés qui consentent à déclencher cet investissement conséquent…. pour un résultat parfois assez décevant derrière… faut de capacité à optimiser les revenus générés, notamment en raison de leur architecture en silos
  • des sociétés qui se lancent et transforment l’essai, souvent après avoir optimisé tous les aspects de leur parcours utilisateurs. Ces dernières sont celles qui investissent le plus de ressources, de temps et d’efforts sur le sujet.

Comme le dit le célèbre adage “Move Fast, Break Things!“, la voie de la réussite pour une startup passe pas des essais, des itérations, des échecs et des réussites. Pour arriver à la réussite, il faut souvent commencer par échouer… et plutôt rapidement si possible (“Fail fast!“). La mise en place de l’In-App Purchase est, compte tenu de ces éléments, en tous points incompatible avec ces bonnes pratiques.

Monter l’Everest… et s’arrêter au camp de base…

Admettons que vous décidiez de vous lancer dans un développement in-house de votre brique de gestion des abonnements in-app malgré nos mises en garde 😅. C’est bien entendu votre droit. D’après ce que nous avons observé sur nos différentes implémentations, la plupart des sociétés qui font le travail par elles-mêmes s’arrêtent en chemin.

Nous avons l’habitude de comparer l’implémentation des abonnements In-App à l’ascension de l’Everest…

D’abord, on trouve le camp de base, constitué de toutes les fonctionnalités qui permettent de souscrire à un abonnement. Les fonctionnalités de base, sans lesquelles il est tout simplement impossible de vendre un abonnement. L’estimation de 17 500 euros dont il était question plus haut ne concernent que ce premier étage.

Juste au-dessus du camp de base, il y a l’avant-poste : les fonctionnalités un peu plus avancées, permettant d’améliorer les processus client et de les rendre “temps réel” (grâce aux notifications server-to-server en provenance des stores) et sécurisés (en limitant le partage d’abonnements ou de comptes)

Cet avant-poste constitue d’après notre expérience le point le plus avancé atteint par 90% des solutions d’In-App Purchase “in-house“. D’après ce que nous avons observé en testant l’application myCanal même un groupe comme Canal+, qui dispose pourtant de moyens conséquents et pour lesquels l’abonnement In-App est un véritable axe de développement stratégique, n’avait pas implémenté les notifications temps réel début 2020, alors que celles-ci apportent beaucoup de possibilités d’optimisation des revenus. Loin de nous l’idée de montrer Canal+ du doigt, leur app est absolument superbe et leur partenariat avec Apple fait partie des plus aboutis dans le monde. Mais cela montre la réelle difficulté à poursuivre l’ascension quand l’oxygène se fait rare…

Rien de plus normal nous direz-vous : une fois l’avant-poste atteint, les abonnés commencent à affluer et la roadmap produit reprend ses droits. Il faut bien que les utilisateurs aient une raison de s’abonner et donc la priorité des développements est donc donnée aux features premium réservées aux abonnés. Et comme il faut faire le travail 2 fois (iOS et Android) ou même 3 fois (+ Web), personne ne se sent de se lancer dans ce défi…

Après 3 mois d’efforts, voilà donc le constat : vous étiez partis pour l’ascension de l’Everest, mais vous vous êtes arrêtés en route, faute d’oxygène… Le nouvel abonnement est désormais disponible dans votre app, mais le marketing est frustré : le funnel ne convertit pas autant que souhaité, l’acquisition des utilisateurs est coûteuse, l’average revenue per user (ARPU) en deçà des espérances… Vous avez du mal à évaluer combien chaque abonné vous rapporte. En fait, vous êtes même incapable d’évaluer combien l’ensemble des abonnés rapportent tout court : Google et Apple fournissent chacun leur interface web, mais les indicateurs ne sont pas calculés de la même manière, et le seul moyen de réconcilier tout ça consiste à télécharger les rapports de vente au format CSV et à bidouiller ensuite avec Excel… ou à demander à la compta de fournir l’information en scrutant les virement reçus sur le compte en banque… 🤯 #CaSentLeVécu!

A chaque optimisation souhaitée par l’équipe Market, du travail de la part des développeurs est nécessaire… et ils sont sous l’eau, mobilisés sur d’autres sujets… Et puis l’étape initiale n’étant pas un franc succès, on hésite à continuer d’investir de peur que ce soit à fonds perdus.

Ce qui est dommageable avec cette situation, c’est que comme lorsqu’on monte l’Everest, plus on monte et plus la vue est belle : la business value se situe plus haut :

  • Optimiser le funnel en testant différentes offres / différents discours / différents manière de présenter le service
  • Gérer les impayés efficacement en les incitant à mettre à jour leur carte bleue si l’abonnement n’a pu être prélevé
  • Retenir les abonnés, en leur proposant des offres de rétention lorsqu’ils annulent leur abonnement
  • et le Saint-Graal qui se situe tout en haut, au sommet : être capable de calculer et optimiser le MRR (Monthly Recurring Revenue) et la LTV (Life-Time Value) de chaque abonné.

Autre problème qui empêche de monter plus haut : des raccourcis ont été faits lors de l’implémentation, les process n’ont pas été unifiés au niveau du backend, la stack technique est silotée. A peine mise en place, toute cette stack technique mériterait déjà d’être refactorée. Dans les faits : le funnel fonctionne à peu près et plus personne ne souhaite y toucher, de peur de casser quelque chose. Vous choisissez donc d’un commun accord avec votre équipe de vous arrêter là et acceptez de ne pas itérer sur ce pan du produit, pourtant critique pour le business.

L’In-App Purchase devrait être aussi facile à intégrer que les push notifications

Ces difficultés, constatées sur le terrain à de multiples reprises, nous font dire que quelque chose est cassé avec l’In-App Purchase. Les développements sont encore trop souvent faits à la main. Chaque startup implémente cette brique à sa sauce, ce qui revient à réinventer la roue. La plupart des sociétés rencontrent les mêmes difficultés, ce qui les empêche derrière de tirer le potentiel maximal de ce business model.

Chez Purchasely, cette histoire nous rappelle celle des pushs notifications, 10 ans en arrière. A cette époque, tout le monde y allait de son propre développement pour implémenter cette fonctionnalité novatrice, et très utile pour le business. Puis sont arrivés les premiers outils de CRM mobile : Accengage, Adobe Mobile Services, Batch, qui proposaient une intégration ultra simplifiée, clé en main, accompagnée d’analytics et de marketing automations à forte valeur ajoutée. 10 ans plus tard, les startups ont bien compris qu’elles perdraient leur temps (et de l’argent) en essayant de réimplémenter toutes ces fonctionnalités par elles-mêmes. L’utilisation de ces outils s’est donc très largement démocratisée (qui se lancerait dans le développement de sa solution de push in-house aujourd’hui ???). Cette démocratisation a elle-même contribué à accélérer la croissance des startups.

Chez Purchasely, on a l’ambition de réparer ce problème en proposant une solution qui révolutionne la manière d’appréhender l’In-App Purchase.

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore

© Rawpixel.com / Shutterstock
Guides

L’abonnement, le modèle économique en plein essor

C’est un euphémisme, les abonnements sont en plein essor depuis 10 ans. Plus qu’un effet de mode, ou une simple tendance de marché, il s’agit d’une véritable révolution qui est en train de bouleverser notre rapport aux services, et même à l’achat de manière plus générale. Le concept d’abonnement n’a pourtant rien de nouveau, mais l’essor du numérique est en train d’accélérer l’adoption de ce modèle économique par les consommateurs aussi bien que par les entreprises.

Guides

Téléchargez GRATUITEMENT l’e-book Subscriptions App Fundamentals (anglais)

Les abonnements In-App sont partout et sont en train de devenir un véritable style de vie et une nouvelle manière de consommer les services. Il s’agit du business model mobile avec la plus forte croissance depuis 2017. En 2020, ils représentent 96% des revenus générés par l’App Store et le Google Play Store (hors gaming)

en_US
fr_FR en_US