Collecter les données des joueurs

Pushwoosh a besoin de savoir qui sont vos joueurs et ce qu’ils font dans le jeu. Les événements enregistrent les actions, et les tags conservent l’état actuel de chaque joueur.

Laissez AI Assistant créer les événements et les tags

AI Assistant peut créer dans votre application les événements et les tags de cette page. Envoyez-lui le lien vers la page et demandez-lui de rendre les tags User-specific. Vérifiez chaque modification avant de l’approuver.

Identifier les joueurs par User ID

Assistance d'un développeur requise

La définition du User ID est une modification du code de votre jeu. Partagez Collecte des User ID avec vos développeurs.

Pushwoosh relie tous les appareils d’un joueur à un seul User ID : vos segments et vos Journeys traitent donc une personne comme un seul joueur. Les événements et les tags User-specific qu’un appareil a enregistrés avant la connexion du joueur restent associés à son ancien ID. Les tags Device-specific suivent l’appareil.

Par défaut, Pushwoosh utilise l’identifiant matériel (HWID) de chaque appareil comme User ID. Un joueur qui joue sur deux appareils compte alors comme deux joueurs. Pour éviter cela chez les joueurs qui se connectent, définissez votre propre identifiant de compte comme leur User ID :

1. Choisissez l’ID à utiliser. Prenez l’identifiant de compte que votre jeu attribue déjà à chaque joueur.
2. Demandez à vos développeurs d’appeler setUserId avec cet ID lorsque le joueur se connecte.
3. Vérifiez le résultat. Connectez-vous au jeu sur un appareil de test, puis ouvrez Audience → Explorateur d’utilisateurs, recherchez par Identifiant utilisateur et saisissez l’identifiant de compte. Le profil du joueur s’ouvre.

Les joueurs qui ne se connectent jamais conservent le HWID comme User ID, et Pushwoosh le définit pour eux.

Pour en savoir plus sur la relation entre les User ID et les appareils, consultez Utilisateurs (ID utilisateur).

Configurer les événements à suivre

Les événements permettent à Pushwoosh de savoir ce que fait un joueur. Créez-les en premier : les segments regroupent les joueurs selon les événements qu’ils ont déclenchés, et les Journeys démarrent lorsqu’un événement se produit.

Planifiez les événements et leurs attributs avant de construire quoi que ce soit. Événements recommandés pour les applications de jeu répertorie des événements de jeu prêts à l’emploi avec leurs attributs, et Événements personnalisés explique comment définir les vôtres.

Il existe deux types d’événements :

• Événements par défaut : enregistrement de l’appareil, ouverture de l’application, achat et quelques autres. Le SDK les envoie, et vous ne les créez pas dans le Control Panel.
• Événements personnalisés : niveau terminé, récompense réclamée, boutique ouverte, et d’autres. Vos développeurs les envoient depuis le jeu, et Pushwoosh crée chacun d’eux la première fois qu’il arrive. Pour choisir vous-même les types d’attributs, créez d’abord l’événement dans le Control Panel. Consultez Événements personnalisés et Événements créés automatiquement.

Événements par défaut

Le SDK envoie ces événements à votre place. Vous en avez besoin pour la plupart des Journeys de ce guide pratique : onboarding, reconquête et offres d’achat.

• PW_DeviceRegistered : un appareil a reçu son premier jeton push. Le SDK ne demande le jeton que lorsque le jeu appelle registerForPushNotifications, qui affiche aussi la demande d’autorisation sur iOS, et le jeton arrive quelle que soit la réponse du joueur. Si le jeu demande l’autorisation après le premier lancement, l’événement se déclenche à ce moment-là, et non à l’installation. Pour repérer les nouveaux joueurs, utilisez plutôt l’événement Tutorial started.
• PW_ApplicationOpen : un joueur a ouvert le jeu. Vous en avez besoin pour trouver les joueurs qui jouent encore et ceux qui ont arrêté, afin de les reconquérir.
• PW_InAppPurchase : un joueur a acheté quelque chose dans le jeu. Vous en avez besoin pour distinguer les joueurs payants des joueurs non payants, par exemple pour proposer un premier achat uniquement aux joueurs qui n’ont jamais payé. Vos développeurs activent le suivi des achats dans le SDK iOS ou envoient les achats depuis le code, et sur Android, ils les envoient toujours depuis le code. Sur iOS, il ne se déclenche que pour les produits configurés dans App Store Connect.
• Facultatif : PW_UserIdle : se déclenche lorsqu’un joueur cesse de toucher l’écran pendant une durée que vous définissez, d’au moins 30 secondes. Démarre un Journey qui affiche une astuce in-app lorsqu’un joueur est bloqué. Vos développeurs l’activent dans la configuration du SDK.
• Facultatif : PW_ApplicationExit : se déclenche lorsqu’un joueur quitte le jeu et n’y revient pas dans un délai de 10 à 30 secondes. Démarre un Journey de reconquête pour les joueurs qui partent en cours de parcours. Vos développeurs l’activent dans la configuration du SDK.

Un événement apparaît dans Audience → Événements après que le SDK l’a envoyé pour la première fois.

Pour ajouter plus tôt à la liste un autre événement par défaut, par exemple pour créer un segment avant la mise en ligne de la mise à jour du jeu :

1. Ouvrez Audience → Événements et cliquez sur Créer un événement.
2. Choisissez Événement par défaut.
3. Sélectionnez l’événement et cliquez sur Activer.

La liste de l’étape 3 n’inclut pas PW_UserIdle ni PW_ApplicationExit. Ils n’apparaissent dans Audience → Événements qu’après le premier envoi par le SDK.

Pour en savoir plus sur ces événements et les autres événements par défaut, consultez Événements par défaut.

Événements personnalisés

Les événements personnalisés enregistrent ce qui se passe dans votre jeu, comme la réussite d’un niveau. Vous choisissez ceux dont le jeu a besoin, vos développeurs les envoient, et vous vérifiez qu’ils arrivent.

Choisir les événements à suivre

Choisissez les événements dont votre jeu a besoin et les attributs que porte chacun d’eux, par exemple level_id pour Level completed. Le tableau donne des exemples : utilisez-les tels quels, renommez-les ou ajoutez les vôtres. Ne suivez que les événements nécessaires aux Journeys que vous lancez.

Événement	Quand il se déclenche	Attributs clés	À quoi il sert
New level	Le joueur atteint un nouveau niveau	level_id (String)	Facultatif : vos propres segments d’étapes clés
Level completed	Le joueur termine un niveau	level_id (String)	Segments des joueurs non payants engagés et des joueurs bloqués, Journey d’aide aux joueurs bloqués
Level failed	Le joueur échoue à un niveau	level_id (String)	Segment et Journey des joueurs bloqués
Tutorial started	Le joueur commence le tutoriel du jeu	tutorial_name (String)	Journey d’onboarding, segment d’abandon du tutoriel
Tutorial completed	Le joueur termine le tutoriel du jeu	tutorial_name (String), completion (Boolean)	Journey d’onboarding, parcours d’autorisation push
Virtual currency earned	Le solde de monnaie du jeu du joueur augmente	currency_name (String), quantity (Integer)	Facultatif : vos propres segments basés sur la monnaie
Achievement unlocked	Le joueur débloque un succès	achievement_name (String), level (Integer)	Segment des chasseurs de succès
Daily reward claimed	Le joueur réclame la récompense quotidienne	day_number (Integer)	Journey de rappel de la récompense quotidienne
Live event joined	Le joueur rejoint un événement live	event_id (String)	Objectif de conversion du Journey de l’événement live
Store opened	Le joueur ouvre la boutique du jeu	section (String)	Journey d’abandon de la boutique

Votre jeu n'a pas de tutoriel ?

Utilisez vos propres événements pour les deux premières actions de chaque nouveau joueur, comme commencer et terminer le premier niveau, à la place de Tutorial started et Tutorial completed partout où ce guide pratique les mentionne.

• Le premier événement démarre le Journey d’onboarding, et le second lui indique que le joueur a terminé. Ignorez la condition completion qui accompagne Tutorial completed.
• Les SDK n’envoient aucun événement de premier lancement qui leur soit propre : les deux doivent donc être des événements personnalisés envoyés par votre jeu.

Envoyer les événements depuis le jeu

Assistance d'un développeur requise

L’envoi d’événements est une modification du code de votre jeu. Partagez Événements pour les développeurs et les exemples d’événements de jeu avec vos développeurs. Ils envoient chaque événement avec postEvent au moment où l’action se produit. Les achats et l’attribution de récompenses doivent provenir du serveur du jeu, avec le userId du joueur.

Convenez avec vos développeurs des événements que le jeu envoie et des attributs que porte chacun d’eux. Les noms des événements et des attributs doivent correspondre exactement.

Par exemple, voici comment le jeu envoie Level completed avec son attribut level_id :

Android

TagsBundle attributes = new TagsBundle.Builder()
    .putString("level_id", "12")
    .build();

InAppManager.getInstance().postEvent("Level completed", attributes);

iOS

PWInAppManager.shared().postEvent("Level completed", withAttributes: ["level_id": "12"])

Si un événement se produit sur un serveur qui envoie déjà ses propres webhooks, comme le backend de votre jeu ou un service de tournois, il peut parvenir à Pushwoosh via un webhook entrant au lieu de postEvent. Vous associez les champs qu’il envoie à un événement Pushwoosh dans le Control Panel, et l’événement peut démarrer un Journey comme n’importe quel autre.

Pour vérifier qu’un événement est arrivé, ouvrez Audience → Explorateur d’utilisateurs, trouvez un joueur de test et ouvrez l’onglet Historique des événements.

Suivre les revenus avec PW_Conversion

PW_Conversion enregistre le montant et la devise de chaque achat dans un format unique. Vous en avez besoin pour un objectif de revenus dans les Journeys et pour les niveaux de dépense de la segmentation RFM, qui regroupe les joueurs selon la date de leur dernier achat, leur fréquence d’achat et le montant dépensé.

Les achats suivis par le SDK iOS arrivent d’eux-mêmes dans PW_Conversion, car ils portent les attributs __amount et __currency. Les achats Android nécessitent l’une des solutions suivantes :

• Si votre jeu fonctionne à la fois sur iOS et sur Android, demandez à vos développeurs d’envoyer les achats Android sous forme de PW_InAppPurchase avec des attributs numériques __amount et __currency via postEvent, au lieu de la méthode d’achat du SDK. Le même mappage automatique couvre alors les deux plateformes.
• Si votre jeu fonctionne uniquement sur Android, mappez vous-même les achats, sans nouveau code. Un événement ne conserve qu’un seul mappage : dans un jeu avec des achats iOS, un mappage manuel remplacerait donc le mappage automatique.

Pour mapper vous-même les achats :

1. Ouvrez Audience → Événements et ouvrez les paramètres des événements de conversion.
2. Ajoutez PW_InAppPurchase comme événement de conversion.
3. Sélectionnez les attributs qui contiennent son Prix et sa Devise.
4. Cliquez sur Appliquer.

Attention

N’utilisez qu’une seule méthode par transaction. Si votre code envoie aussi PW_Conversion pour le même achat, Pushwoosh enregistre deux événements de conversion distincts.

Pour toutes les options de configuration, consultez Événements de conversion.

Suivre les abonnements depuis les stores

Si votre jeu vend des abonnements, comme un pass VIP ou un pass de combat, Pushwoosh reçoit leurs changements de statut depuis l’App Store et Google Play. Chaque changement arrive sous la forme d’un événement PW_Subscription*, par exemple :

• PW_SubscriptionStart : un joueur s’abonne.
• PW_SubscriptionCancel : un joueur désactive le renouvellement automatique.
• PW_SubscriptionBillingIssue : un paiement de renouvellement échoue.

Utilisez ces événements pour démarrer des Journeys, par exemple un rappel avant l’expiration d’un pass annulé.

Assistance d'un développeur requise

Le jeu doit transmettre le HWID Pushwoosh du joueur avec chaque achat :

• Sur iOS, en tant que appAccountToken.
• Sur Android, en tant que obfuscatedAccountId. Le jeu transmet la valeur de getSubscriptionAccountId() du SDK, qui combine l’Application Code et le HWID, et non le HWID seul.

Sans cela, Pushwoosh reçoit la notification mais n’enregistre aucun événement, et les abonnements achetés auparavant ne pourront pas être associés plus tard. Partagez Suivi des abonnements de l’App Store et Suivi des abonnements Google Play avec vos développeurs.

Ces événements ne concernent que les abonnements. Les achats ponctuels, comme un pack de pièces, arrivent toujours sous forme de PW_InAppPurchase.

Stocker les données des joueurs dans des tags

Un tag est une valeur que Pushwoosh stocke dans le profil d’un joueur, comme son niveau ou le fait qu’il ait payé ou non. Un événement enregistre ce qui s’est passé, et un tag conserve l’état actuel. Les tags vous permettent :

• D’envoyer un message uniquement aux joueurs ayant une certaine valeur, par exemple une offre uniquement aux joueurs payants.
• D’insérer la valeur dans le texte du message, par exemple le niveau du joueur. Consultez Créer les Journeys.

Les tags sont facultatifs. Les Journeys de ce guide pratique reposent sur des événements et sur des tags par défaut que Pushwoosh définit lui-même : vous pouvez donc vous passer de vos propres tags au début. Ajoutez-les lorsque vous voulez davantage de façons de regrouper les joueurs. Consultez Segments par tags.

Vos propres tags

Vos développeurs envoient les valeurs des tags depuis le jeu, ou vous pouvez les importer depuis un fichier CSV. Pushwoosh crée un tag la première fois que vos développeurs l’envoient, en tant que tag User-specific. Créez d’abord le tag dans le Control Panel si vous voulez choisir vous-même son type. Consultez Gérer les données utilisateur avec les tags.

Ces tags sont des exemples. Renommez-les selon le vocabulaire de votre jeu et ajoutez les vôtres :

Tag	Type	Exemple	À quoi il sert
player_level	Integer	12	Filtrer les messages par palier de progression
is_paying_user	Boolean	true	Séparer les messages destinés aux joueurs payants et non payants
soft_currency_balance	Integer	1500	Proposer un pack de monnaie aux joueurs dont le solde est faible
vip_tier	String	gold	Offrir aux joueurs VIP leurs propres offres et un accès anticipé
favorite_mode	String	pvp	Annoncer les événements live pour le mode préféré du joueur

Lorsque vous créez un tag dans le Control Panel, laissez l’option Spécifique à l’utilisateur activée, comme elle l’est par défaut. Pushwoosh conserve alors une valeur par User ID : la valeur appartient au joueur et non à l’un de ses appareils. Lorsque Spécifique à l’utilisateur est désactivé, chaque appareil conserve sa propre valeur. Consultez Identifier les joueurs par User ID.

Tags par défaut

Pushwoosh stocke ces tags par défaut pour chaque appareil : vous n’avez donc pas à les créer.

• Language : la langue de l’appareil. Pushwoosh l’utilise pour envoyer à chaque joueur le message dans sa propre langue.
• Last Application Open : la dernière ouverture du jeu sur l’appareil. Utilisez-le pour trouver les joueurs qui ont arrêté de jouer.
• Push Alerts Enabled : indique si les notifications sont autorisées dans les paramètres de l’appareil. Utilisez-le pour afficher un message in-app uniquement aux joueurs qui ne les ont pas encore autorisées.
• First Install : la première installation du jeu sur l’appareil. Utilisez-le pour les anniversaires d’installation.
• Country : le pays de l’appareil. Utilisez-le pour envoyer une offre ou l’annonce d’un événement live uniquement aux joueurs d’une région.