# 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.

<Aside type="tip" title="Laissez AI Assistant créer les événements et les tags">
[AI Assistant](/fr/product/pushwoosh-ai/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.
</Aside>

<span id="identify-players-by-user-id" />

## Identifier les joueurs par User ID

<Aside type="caution" icon="setting" title="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](/fr/developer/first-steps/collecting-user-ids/#setuserid-sdk-method) avec vos développeurs.
</Aside>

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)](/fr/product/pushwoosh-knowledge-hub/users-userids/).

<span id="set-up-the-events-to-track" />

## Configurer les événements à suivre

Les événements permettent à Pushwoosh de savoir ce que fait un joueur. Créez-les en premier : les [segments](/fr/tutorials/industry-playbooks/mobile-games/build-the-segments/) regroupent les joueurs selon les événements qu'ils ont déclenchés, et les [Journeys](/fr/tutorials/industry-playbooks/mobile-games/build-the-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](/fr/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/) répertorie des événements de jeu prêts à l'emploi avec leurs attributs, et [Événements personnalisés](/fr/product/audience-data-and-segmentation/events/custom-events/) explique comment définir les vôtres.

Il existe deux types d'événements :

* [Événements par défaut](#default-events) : 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](#custom-events) : niveau terminé, récompense réclamée, boutique ouverte, et d'autres. Vos développeurs [les envoient depuis le jeu](#send-the-events-from-the-game), 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](/fr/product/audience-data-and-segmentation/events/custom-events/) et [Événements créés automatiquement](/fr/product/audience-data-and-segmentation/events/#events-created-automatically).

<span id="default-events" />

### É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`](/fr/product/audience-data-and-segmentation/events/default-events/#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`](/fr/product/audience-data-and-segmentation/events/default-events/#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`](/fr/product/audience-data-and-segmentation/events/default-events/#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`](/fr/product/audience-data-and-segmentation/events/default-events/#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`](/fr/product/audience-data-and-segmentation/events/default-events/#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](/fr/product/audience-data-and-segmentation/events/default-events/).

<span id="custom-events" />

### É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.

<span id="choose-the-events-to-track" />

#### 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](/fr/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#new-level) | Le joueur atteint un nouveau niveau | `level_id` (String) | Facultatif : vos propres segments d'étapes clés |
| [Level completed](/fr/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#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](/fr/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#tutorial-completed) | Le joueur termine le tutoriel du jeu | `tutorial_name` (String), `completion` (Boolean) | Journey d'onboarding, parcours d'autorisation push |
| [Virtual currency earned](/fr/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#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](/fr/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#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 |

<Aside type="tip" title="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.
</Aside>

<span id="send-the-events-from-the-game" />

#### Envoyer les événements depuis le jeu

<Aside type="caution" icon="setting" title="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](/fr/developer/guides/audience-and-segmentation/events/) et les [exemples d'événements de jeu](/fr/developer/guides/audience-and-segmentation/events/custom-events-examples#gaming-apps) 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.
</Aside>

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` :

<Tabs>
<TabItem label="Android">
```java
TagsBundle attributes = new TagsBundle.Builder()
    .putString("level_id", "12")
    .build();

InAppManager.getInstance().postEvent("Level completed", attributes);
```
</TabItem>
<TabItem label="iOS">
```swift
PWInAppManager.shared().postEvent("Level completed", withAttributes: ["level_id": "12"])
```
</TabItem>
</Tabs>

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](/fr/product/integrations/inbound-webhook/) 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**.


<span id="track-revenue-as-pw_conversion" />

### 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](/fr/product/audience-data-and-segmentation/segmentation/rfm-segmentation/), 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**.

<Aside type="caution">
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.
</Aside>

Pour toutes les options de configuration, consultez [Événements de conversion](/fr/product/audience-data-and-segmentation/events/conversion-events/).

<span id="track-subscriptions-from-the-stores" />

### 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é.

<Aside type="caution" icon="setting" title="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](/fr/product/integrations/app-store-subscription-tracking/) et [Suivi des abonnements Google Play](/fr/product/integrations/google-play-subscription-tracking/) avec vos développeurs.
</Aside>

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

<span id="store-player-data-in-tags" />

## Stocker les données des joueurs dans des tags

Un [tag](/fr/product/audience-data-and-segmentation/user-data-tags/) 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](/fr/tutorials/industry-playbooks/mobile-games/build-the-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](/fr/tutorials/industry-playbooks/mobile-games/build-the-segments/#segments-by-tags).

### Vos propres tags

Vos développeurs envoient les valeurs des tags depuis le jeu, ou vous pouvez [les importer depuis un fichier CSV](/fr/product/audience-data-and-segmentation/user-data-tags/update-tags-via-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](/fr/product/audience-data-and-segmentation/user-data-tags/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**](/fr/product/audience-data-and-segmentation/user-data-tags/tags/#tag-scope-general-vs-user-specific) 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](/fr/tutorials/industry-playbooks/mobile-games/collect-player-data/#identify-players-by-user-id).

### Tags par défaut

Pushwoosh stocke ces [tags par défaut](/fr/product/audience-data-and-segmentation/user-data-tags/tags/#default-tags) 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.