Refus Google Play
Google n'a rien contre la publicité. Il a quelque chose contre les annonces qui surprennent l'utilisateur, masquent le contenu, apparaissent avant que l'app soit utilisable ou atteignent des enfants via un réseau non certifié. L'intégration AdMob de WebViewGold comporte une poignée de réglages qui décident de quel côté de cette ligne vous vous trouvez.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Les règles comportent trois volets. Emplacement et timing : les annonces plein écran ne doivent pas apparaître de manière inattendue, par exemple au démarrage de l'app, entre chaque appui, avant le chargement du contenu ou sans pouvoir être fermées ; les annonces ne doivent pas pouvoir être confondues avec le contenu de l'app ou avec des notifications système, et doivent rester dans l'app. Déclarations : la réponse « Contient des annonces » dans Contenu de l'app, l'identifiant publicitaire dans le formulaire Sécurité des données et la classification du contenu doivent correspondre à ce que fait l'app. Audience : les apps dont l'audience cible inclut des enfants ne peuvent utiliser que des SDK publicitaires certifiés pour les familles et ne doivent pas afficher de contenu publicitaire inapproprié.
Les examinateurs ne lisent pas vos réglages AdMob. Ils installent l'app, la parcourent pendant une minute et observent ce qui se passe. Un interstitiel au deuxième appui, avant même qu'ils aient vu votre produit, suffit pour un refus.
Les interstitiels au lancement, pendant le chargement ou juste après l'écran de démarrage sont la violation classique. Affichez-les après une action terminée, lors de pauses naturelles.
Les annonces plein écran doivent proposer une option de fermeture visible au bout d'un court instant ; les annonces qui piègent l'utilisateur ou se rouvrent d'elles-mêmes sont interdites.
Pas de bannières déguisées en boutons de votre app, pas d'annonces qui imitent des boîtes de dialogue ou des notifications système, pas d'annonces dans la barre d'état ni sur l'écran de verrouillage.
Si AdMob est activé dans Config.java, répondez oui sous Contenu de l'app → Annonces et déclarez l'identifiant publicitaire dans Sécurité des données. L'incohérence inverse, des annonces déclarées mais aucune affichée, est sans conséquence ; la première ne l'est pas.
Pour une audience cible qui inclut des enfants, seuls les SDK publicitaires de la liste Google certifiée pour les familles sont autorisés, avec un traitement adapté aux enfants configuré. Le choix conforme le plus simple pour une app pour enfants : aucune annonce.
Le contenu publicitaire doit être adapté à la classification par âge de l'app. Configurez les filtres de contenu et la classification maximale du contenu publicitaire dans votre compte AdMob.
Toutes les options se trouvent dans Config.java ; les ID vont dans strings.xml.
Créez l'app dans votre compte AdMob, puis collez l'ID d'app et les ID des blocs d'annonces bannière et interstitiel dans strings.xml, comme décrit dans la documentation AdMob. Un ID d'app manquant ou erroné fait planter l'app au lancement, ce qui se traduit alors par un refus pour fonctionnalité défaillante.
Réglez SHOW_BANNER_AD sur true pour une bannière placée en dehors de la WebView. Vérifiez que la navigation en bas ou les boutons flottants de votre app web ne sont pas masqués derrière elle ; l'injection de CSS personnalisé peut ajouter une marge en bas quand la page tourne dans l'app.
Gardez SHOW_AD_AFTER_X suffisamment élevé pour qu'un examinateur puisse explorer l'app avant la première annonce plein écran, et laissez INCREMENT_WITH_TAPS sur false pour que la saisie et le défilement ne comptent pas pour la prochaine annonce. Compter les chargements de page plutôt que les appuis rend le timing prévisible.
Ajoutez des fragments d'URL comme « /thank-you/ » ou « /result » à AD_TRIGGER_URLS pour que les interstitiels apparaissent après une action terminée plutôt que selon un compteur. C'est l'emplacement que Google décrit comme acceptable, et il convertit mieux, en plus.
Les annonces avec récompense sont déclenchées par l'utilisateur, ce qui en fait le format le plus sûr. Activez ENABLE_REWARDED_ADS et déclenchez-les depuis votre app web quand l'utilisateur choisit de regarder une annonce en échange d'un avantage ; laissez USE_REWARDED_ADS_WHERE_POSSIBLE sur false si c'est le code de votre site qui décide quand les lancer.
Laissez ASK_FOR_AD_CONSENT sur true pour que la gestion du consentement de Google affiche le message requis aux utilisateurs des régions concernées, et configurez ce message dans votre compte AdMob. Répondez ensuite oui sous Contenu de l'app → Annonces et ajoutez l'identifiant publicitaire dans Sécurité des données.
Excellente façon de convertir son app web en app native ! Un délai très court, et un super moyen de mettre ses apps dans les stores sans devoir développer une app native complète !
| Passe | Signalé | |
|---|---|---|
| Première impression | Écran de démarrage, contenu, puis annonces après une vraie utilisation | Interstitiel juste après le lancement ou au premier appui |
| Fréquence | Un interstitiel après une tâche terminée ou après un nombre de pages généreux | Des annonces tous les trois appuis, des annonces pendant que l'utilisateur tape |
| Bannière | Bannière fixe qui ne couvre jamais la navigation | Bannière qui chevauche des boutons ou semble faire partie de la page |
| Avec récompense | Sur demande, avec un avantage clair, fermable | Annonces « avec récompense » imposées, sans possibilité de refuser |
| Enfants | Aucune annonce, ou un SDK certifié pour les familles avec des réglages adaptés aux enfants | AdMob par défaut dans une app qui attire les enfants |
INCREMENT_WITH_TAPS sur false.ASK_FOR_AD_CONSENT sur true.Oui. Tout format publicitaire, y compris les annonces avec récompense et les bannières, signifie que l'app contient des annonces. La mention apparaît sur votre fiche et les examinateurs la comparent à ce qu'ils voient.
Non. Les annonces plein écran affichées avant que l'utilisateur ait fait quoi que ce soit dans l'app sont le motif de refus publicitaire le plus courant. Affichez-les après une action terminée ou lors d'une pause naturelle.
AdMob a ses propres règles, par exemple sur le trafic incorrect et les clics sur vos propres annonces pendant les tests. Utilisez des annonces de test et un appareil de test enregistré pendant le développement, et ne passez aux blocs d'annonces réels que pour le build de release.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.