# Spielerdaten erfassen
Pushwoosh muss wissen, wer Ihre Spieler sind und was sie im Spiel tun. Events erfassen die Aktionen, und Tags speichern den aktuellen Zustand jedes Spielers.
## Spieler anhand der User ID identifizieren
Pushwoosh verknüpft alle Geräte eines Spielers mit einer User ID, sodass Ihre Segmente und Journeys eine Person als einen Spieler behandeln. Events und User-specific Tags, die ein Gerät vor der Anmeldung des Spielers erfasst hat, bleiben bei seiner früheren ID. Device-specific Tags wandern mit dem Gerät.
Standardmäßig verwendet Pushwoosh die Hardware-ID (HWID) jedes Geräts als dessen User ID. Ein Spieler, der auf zwei Geräten spielt, zählt dann als zwei Spieler. Um das bei Spielern zu vermeiden, die sich anmelden, legen Sie Ihre eigene Konto-ID als deren User ID fest:
1. Wählen Sie die ID aus, die Sie verwenden möchten. Nehmen Sie die Konto-ID, die Ihr Spiel jedem Spieler bereits zuweist.
2. Bitten Sie Ihre Entwickler, `setUserId` mit dieser ID aufzurufen, wenn sich der Spieler anmeldet.
3. Prüfen Sie das Ergebnis. Melden Sie sich auf einem Testgerät im Spiel an, öffnen Sie dann **Zielgruppe** → **Benutzer-Explorer**, suchen Sie nach **Benutzer-ID** und geben Sie die Konto-ID ein. Das Profil des Spielers wird geöffnet.
Spieler, die sich nie anmelden, behalten die HWID als ihre User ID, und Pushwoosh legt sie für sie fest.
Mehr darüber, wie User IDs und Geräte zusammenhängen, erfahren Sie unter [Benutzer (Benutzer-IDs)](/de/product/pushwoosh-knowledge-hub/users-userids/).
## Die zu erfassenden Events einrichten
Über Events erfährt Pushwoosh, was ein Spieler tut. Erstellen Sie sie zuerst: [Segmente](/de/tutorials/industry-playbooks/mobile-games/build-the-segments/) gruppieren Spieler nach den Events, die sie ausgelöst haben, und [Journeys](/de/tutorials/industry-playbooks/mobile-games/build-the-journeys/) starten, wenn ein Event eintritt.
Planen Sie sowohl die Events als auch ihre Attribute, bevor Sie etwas aufbauen. [Empfohlene Events für Gaming-Apps](/de/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/) listet fertige Gaming-Events mit Attributen auf, und [Benutzerdefinierte Events](/de/product/audience-data-and-segmentation/events/custom-events/) erklärt, wie Sie eigene definieren.
Es gibt zwei Arten von Events:
* [Standard-Events](#default-events): Geräteregistrierung, App-Öffnung, Kauf und einige weitere. Das SDK sendet sie, und Sie erstellen sie nicht im Control Panel.
* [Benutzerdefinierte Events](#custom-events): Level abgeschlossen, Belohnung abgeholt, Shop geöffnet und andere. Ihre Entwickler [senden sie aus dem Spiel](#send-the-events-from-the-game), und Pushwoosh erstellt jedes Event, wenn es zum ersten Mal eintrifft. Wenn Sie die Attributtypen selbst wählen möchten, erstellen Sie das Event zuerst im Control Panel. Siehe [Benutzerdefinierte Events](/de/product/audience-data-and-segmentation/events/custom-events/) und [Automatisch erstellte Events](/de/product/audience-data-and-segmentation/events/#events-created-automatically).
### Standard-Events
Das SDK sendet diese Events für Sie. Sie benötigen sie für die meisten Journeys in diesem Playbook: Onboarding, Win-back und Kaufangebote.
* [`PW_DeviceRegistered`](/de/product/audience-data-and-segmentation/events/default-events/#pw_deviceregistered): Ein Gerät hat sein erstes Push-Token erhalten. Das SDK fordert das Token nur an, wenn das Spiel `registerForPushNotifications` aufruft, was unter iOS auch die Berechtigungsabfrage anzeigt, und das Token kommt unabhängig von der Antwort des Spielers an. Fragt das Spiel die Berechtigung später als beim ersten Start ab, wird das Event in diesem Moment ausgelöst, nicht bei der Installation. Um neue Spieler zu erfassen, verwenden Sie stattdessen das Event `Tutorial started`.
* [`PW_ApplicationOpen`](/de/product/audience-data-and-segmentation/events/default-events/#pw_applicationopen): Ein Spieler hat das Spiel geöffnet. Sie benötigen es, um Spieler zu finden, die noch spielen, und Spieler, die aufgehört haben, damit Sie sie zurückgewinnen können.
* [`PW_InAppPurchase`](/de/product/audience-data-and-segmentation/events/default-events/#pw_inapppurchase): Ein Spieler hat etwas im Spiel gekauft. Sie benötigen es, um zahlende von nicht zahlenden Spielern zu unterscheiden, zum Beispiel um einen Erstkauf nur Spielern anzubieten, die noch nie bezahlt haben. Ihre Entwickler aktivieren das Kauf-Tracking im iOS SDK oder senden Käufe aus dem Code, und unter Android senden sie sie immer aus dem Code. Unter iOS wird es nur für Produkte ausgelöst, die in App Store Connect konfiguriert sind.
* Optional: [`PW_UserIdle`](/de/product/audience-data-and-segmentation/events/default-events/#pw_useridle): Wird ausgelöst, wenn ein Spieler den Bildschirm für eine von Ihnen festgelegte Zeit von mindestens 30 Sekunden nicht berührt. Startet eine Journey, die einen In-App-Hinweis anzeigt, wenn ein Spieler nicht weiterkommt. Ihre Entwickler aktivieren es in der SDK-Konfiguration.
* Optional: [`PW_ApplicationExit`](/de/product/audience-data-and-segmentation/events/default-events/#pw_applicationexit): Wird ausgelöst, wenn ein Spieler das Spiel verlässt und nicht innerhalb von 10 bis 30 Sekunden zurückkehrt. Startet eine Win-back-Journey für Spieler, die mitten im Ablauf abbrechen. Ihre Entwickler aktivieren es in der SDK-Konfiguration.
Ein Event erscheint unter **Zielgruppe** → **Events**, nachdem das SDK es zum ersten Mal gesendet hat.
So fügen Sie ein anderes Standard-Event früher zur Liste hinzu, zum Beispiel um ein Segment zu erstellen, bevor das Spiel-Update live ist:
1. Öffnen Sie **Zielgruppe** → **Events** und klicken Sie auf **Event erstellen**.
2. Wählen Sie **Standard-Event**.
3. Wählen Sie das Event aus und klicken Sie auf **Aktivieren**.
Die Liste in Schritt 3 enthält `PW_UserIdle` und `PW_ApplicationExit` nicht. Sie erscheinen unter **Zielgruppe** → **Events** erst, nachdem das SDK sie zum ersten Mal gesendet hat.
Details zu diesen und weiteren Standard-Events finden Sie unter [Standard-Events](/de/product/audience-data-and-segmentation/events/default-events/).
### Benutzerdefinierte Events
Benutzerdefinierte Events erfassen, was in Ihrem Spiel passiert, zum Beispiel den Abschluss eines Levels. Sie wählen aus, welche das Spiel benötigt, Ihre Entwickler senden sie, und Sie prüfen, ob sie ankommen.
#### Die zu erfassenden Events auswählen
Wählen Sie die Events aus, die Ihr Spiel benötigt, und die Attribute, die jedes davon mitführt, zum Beispiel `level_id` für `Level completed`. Die Tabelle enthält Beispiele: Verwenden Sie sie unverändert, benennen Sie sie um oder fügen Sie eigene hinzu. Erfassen Sie nur die Events, die die von Ihnen gestarteten Journeys benötigen.
| Event | Wann es ausgelöst wird | Wichtige Attribute | Wofür es genutzt wird |
| --- | --- | --- | --- |
| [New level](/de/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#new-level) | Spieler erreicht ein neues Level | `level_id` (String) | Optional: Ihre eigenen Meilenstein-Segmente |
| [Level completed](/de/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#level-completed) | Spieler schließt ein Level ab | `level_id` (String) | Segmente „Engagierte Nichtzahler“ und „Festgefahrene Spieler“, Journey „Hilfe für festgefahrene Spieler“ |
| Level failed | Spieler scheitert an einem Level | `level_id` (String) | Segment und Journey für festgefahrene Spieler |
| Tutorial started | Spieler startet das Tutorial im Spiel | `tutorial_name` (String) | Onboarding-Journey, Segment für Tutorial-Abbrecher |
| [Tutorial completed](/de/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#tutorial-completed) | Spieler schließt das Tutorial im Spiel ab | `tutorial_name` (String), `completion` (Boolean) | Onboarding-Journey, Ablauf für die Push-Berechtigung |
| [Virtual currency earned](/de/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#virtual-currency-earned) | Das Guthaben des Spielers an In-Game-Währung steigt | `currency_name` (String), `quantity` (Integer) | Optional: Ihre eigenen währungsbasierten Segmente |
| [Achievement unlocked](/de/product/audience-data-and-segmentation/events/recommended-events-for-gaming-apps/#achievement-unlocked) | Spieler schaltet einen Erfolg frei | `achievement_name` (String), `level` (Integer) | Segment für Erfolgsjäger |
| Daily reward claimed | Spieler holt die tägliche Belohnung ab | `day_number` (Integer) | Journey zur Erinnerung an die tägliche Belohnung |
| Live event joined | Spieler nimmt an einem Live-Event teil | `event_id` (String) | Conversion-Ziel der Live-Event-Journey |
| Store opened | Spieler öffnet den In-Game-Shop | `section` (String) | Journey bei Shop-Abbruch |
#### Die Events aus dem Spiel senden
Stimmen Sie mit Ihren Entwicklern ab, welche Events das Spiel sendet und welche Attribute jedes davon mitführt. Die Namen der Events und Attribute müssen exakt übereinstimmen.
So sendet das Spiel zum Beispiel `Level completed` mit seinem Attribut `level_id`:
```java
TagsBundle attributes = new TagsBundle.Builder()
.putString("level_id", "12")
.build();
InAppManager.getInstance().postEvent("Level completed", attributes);
```
```swift
PWInAppManager.shared().postEvent("Level completed", withAttributes: ["level_id": "12"])
```
Tritt ein Event auf einem Server auf, der bereits eigene Webhooks sendet, etwa Ihr Spiel-Backend oder ein Turnierdienst, kann es Pushwoosh über einen [eingehenden Webhook](/de/product/integrations/inbound-webhook/) statt über `postEvent` erreichen. Sie ordnen die gesendeten Felder im Control Panel einem Pushwoosh-Event zu, und das Event kann wie jedes andere eine Journey starten.
Um zu prüfen, ob ein Event angekommen ist, öffnen Sie **Zielgruppe** → **Benutzer-Explorer**, suchen Sie einen Testspieler und öffnen Sie den Tab **Ereignisverlauf**.
### Umsatz als PW_Conversion erfassen
`PW_Conversion` erfasst Betrag und Währung jedes Kaufs in einem einheitlichen Format. Sie benötigen es für ein Umsatzziel in Journeys und für Ausgabestufen in der [RFM-Segmentierung](/de/product/audience-data-and-segmentation/segmentation/rfm-segmentation/), die Spieler danach gruppiert, wie kürzlich, wie oft und wie viel sie kaufen.
Käufe, die das iOS SDK erfasst, gelangen von selbst zu `PW_Conversion`, da sie die Attribute `__amount` und `__currency` mitführen. Käufe unter Android benötigen eine dieser Optionen:
* Wenn Ihr Spiel sowohl unter iOS als auch unter Android läuft, bitten Sie Ihre Entwickler, Android-Käufe als `PW_InAppPurchase` mit numerischen Attributen `__amount` und `__currency` über `postEvent` zu senden statt über die Kaufmethode des SDK. Dann deckt dieselbe automatische Zuordnung beide Plattformen ab.
* Wenn Ihr Spiel nur unter Android läuft, ordnen Sie die Käufe selbst zu, ohne neuen Code. Ein Event behält nur eine Zuordnung, daher würde eine manuelle Zuordnung in einem Spiel mit iOS-Käufen die automatische ersetzen.
So ordnen Sie Käufe selbst zu:
1. Öffnen Sie **Zielgruppe** → **Events** und öffnen Sie die Einstellungen für Conversion-Events.
2. Fügen Sie `PW_InAppPurchase` als Conversion-Event hinzu.
3. Wählen Sie die Attribute aus, die **Preis** und **Währung** enthalten.
4. Klicken Sie auf **Anwenden**.
Alle Einrichtungsoptionen finden Sie unter [Conversion-Events](/de/product/audience-data-and-segmentation/events/conversion-events/).
### Abonnements aus den Stores erfassen
Wenn Ihr Spiel Abonnements verkauft, etwa einen VIP-Pass oder einen Battle Pass, erhält Pushwoosh deren Statusänderungen vom App Store und von Google Play. Jede Änderung kommt als Event `PW_Subscription*` an, zum Beispiel:
* `PW_SubscriptionStart`: Ein Spieler schließt ein Abonnement ab.
* `PW_SubscriptionCancel`: Ein Spieler deaktiviert die automatische Verlängerung.
* `PW_SubscriptionBillingIssue`: Eine Verlängerungszahlung schlägt fehl.
Verwenden Sie diese Events, um Journeys zu starten, zum Beispiel eine Erinnerung, bevor ein gekündigter Pass abläuft.
Die Events decken nur Abonnements ab. Einmalkäufe, etwa ein Münzpaket, kommen weiterhin als `PW_InAppPurchase` an.
## Spielerdaten in Tags speichern
Ein [Tag](/de/product/audience-data-and-segmentation/user-data-tags/) ist ein Wert, den Pushwoosh im Profil eines Spielers speichert, etwa das Level des Spielers oder ob er bezahlt hat. Ein Event erfasst, was passiert ist, und ein Tag speichert den aktuellen Zustand. Mit Tags können Sie:
* Eine Nachricht nur an Spieler mit einem bestimmten Wert senden, zum Beispiel ein Angebot nur an zahlende Spieler.
* Den Wert in den Nachrichtentext einfügen, zum Beispiel das Level des Spielers. Siehe [Journeys erstellen](/de/tutorials/industry-playbooks/mobile-games/build-the-journeys/).
Tags sind optional. Die Journeys in diesem Playbook laufen über Events und über Standard-Tags, die Pushwoosh selbst setzt, sodass Sie anfangs auf eigene Tags verzichten können. Fügen Sie sie hinzu, wenn Sie mehr Möglichkeiten zum Gruppieren von Spielern wünschen. Siehe [Segmente nach Tags](/de/tutorials/industry-playbooks/mobile-games/build-the-segments/#segments-by-tags).
### Eigene Tags
Ihre Entwickler senden Tag-Werte aus dem Spiel, oder Sie können sie [aus einer CSV-Datei importieren](/de/product/audience-data-and-segmentation/user-data-tags/update-tags-via-csv/). Pushwoosh erstellt einen Tag, wenn Ihre Entwickler ihn zum ersten Mal senden, als User-specific Tag. Erstellen Sie den Tag zuerst im Control Panel, wenn Sie seinen Typ selbst wählen möchten. Siehe [Benutzerdaten mit Tags verwalten](/de/product/audience-data-and-segmentation/user-data-tags/tags/).
Diese Tags sind Beispiele. Benennen Sie sie passend zum Vokabular Ihres Spiels um und fügen Sie eigene hinzu:
| Tag | Typ | Beispiel | Wofür er genutzt wird |
| --- | --- | --- | --- |
| `player_level` | Integer | `12` | Nachrichten nach Fortschrittsstufe filtern |
| `is_paying_user` | Boolean | `true` | Nachrichten für zahlende und nicht zahlende Spieler trennen |
| `soft_currency_balance` | Integer | `1500` | Spielern mit niedrigem Guthaben ein Währungspaket anbieten |
| `vip_tier` | String | `gold` | VIP-Spielern eigene Angebote und frühen Zugang geben |
| `favorite_mode` | String | `pvp` | Live-Events für den Modus ankündigen, den der Spieler mag |
Wenn Sie einen Tag im Control Panel erstellen, lassen Sie [**Nutzerspezifisch**](/de/product/audience-data-and-segmentation/user-data-tags/tags/#tag-scope-general-vs-user-specific) aktiviert, wie es standardmäßig ist. Pushwoosh speichert dann einen Wert pro User ID, sodass der Wert zum Spieler gehört und nicht zu einem seiner Geräte. Ist **Nutzerspezifisch** deaktiviert, speichert jedes Gerät seinen eigenen Wert. Siehe [Spieler anhand der User ID identifizieren](/de/tutorials/industry-playbooks/mobile-games/collect-player-data/#identify-players-by-user-id).
### Standard-Tags
Pushwoosh speichert diese [Standard-Tags](/de/product/audience-data-and-segmentation/user-data-tags/tags/#default-tags) für jedes Gerät, sodass Sie sie nicht erstellen müssen:
* **Language**: die Sprache des Geräts. Pushwoosh verwendet sie, um jedem Spieler die Nachricht in seiner eigenen Sprache zu senden.
* **Last Application Open**: wann das Spiel zuletzt auf dem Gerät geöffnet wurde. Verwenden Sie ihn, um Spieler zu finden, die aufgehört haben zu spielen.
* **Push Alerts Enabled**: ob Benachrichtigungen in den Geräteeinstellungen erlaubt sind. Verwenden Sie ihn, um eine In-App-Nachricht nur Spielern anzuzeigen, die sie noch nicht erlaubt haben.
* **First Install**: wann das Spiel zum ersten Mal auf dem Gerät installiert wurde. Verwenden Sie ihn für Installationsjubiläen.
* **Country**: das Land des Geräts. Verwenden Sie ihn, um ein Angebot oder eine Live-Event-Ankündigung nur an Spieler in einer Region zu senden.