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.

Lassen Sie AI Assistant die Events und Tags erstellen

AI Assistant kann die Events und Tags von dieser Seite in Ihrer Anwendung erstellen. Senden Sie ihm den Link zur Seite und bitten Sie ihn, die Tags als User-specific anzulegen. Prüfen Sie jede Änderung, bevor Sie sie genehmigen.

Spieler anhand der User ID identifizieren

Hilfe von Entwicklern erforderlich

Das Setzen der User ID ist eine Änderung im Code Ihres Spiels. Teilen Sie User IDs erfassen mit Ihren Entwicklern.

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

Die zu erfassenden Events einrichten

Über Events erfährt Pushwoosh, was ein Spieler tut. Erstellen Sie sie zuerst: Segmente gruppieren Spieler nach den Events, die sie ausgelöst haben, und 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 listet fertige Gaming-Events mit Attributen auf, und Benutzerdefinierte Events erklärt, wie Sie eigene definieren.

Es gibt zwei Arten von Events:

• Standard-Events: Geräteregistrierung, App-Öffnung, Kauf und einige weitere. Das SDK sendet sie, und Sie erstellen sie nicht im Control Panel.
• Benutzerdefinierte Events: Level abgeschlossen, Belohnung abgeholt, Shop geöffnet und andere. Ihre Entwickler senden sie aus dem Spiel, 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 und Automatisch erstellte Events.

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

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	Spieler erreicht ein neues Level	level_id (String)	Optional: Ihre eigenen Meilenstein-Segmente
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	Spieler schließt das Tutorial im Spiel ab	tutorial_name (String), completion (Boolean)	Onboarding-Journey, Ablauf für die Push-Berechtigung
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	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

Ihr Spiel hat kein Tutorial?

Verwenden Sie Ihre eigenen Events für die ersten beiden Aktionen, die jeder neue Spieler ausführt, zum Beispiel Start und Abschluss des ersten Levels, anstelle von Tutorial started und Tutorial completed, wo immer dieses Playbook sie erwähnt.

• Das erste Event startet die Onboarding-Journey, und das zweite teilt ihr mit, dass der Spieler fertig ist. Lassen Sie die Bedingung completion weg, die zu Tutorial completed gehört.
• Die SDKs senden kein eigenes Event für den ersten Start, daher müssen beide benutzerdefinierte Events sein, die Ihr Spiel sendet.

Die Events aus dem Spiel senden

Hilfe von Entwicklern erforderlich

Das Senden von Events ist eine Änderung im Code Ihres Spiels. Teilen Sie Events für Entwickler und die Beispiele für Gaming-Events mit Ihren Entwicklern. Sie senden jedes Event mit postEvent in dem Moment, in dem die Aktion stattfindet. Käufe und Belohnungsgutschriften sollten vom Spielserver mit der userId des Spielers kommen.

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:

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"])

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

Vorsicht

Verwenden Sie pro Transaktion nur einen Weg. Wenn Ihr Code für denselben Kauf zusätzlich PW_Conversion sendet, erfasst Pushwoosh zwei separate Conversion-Events.

Alle Einrichtungsoptionen finden Sie unter 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.

Hilfe von Entwicklern erforderlich

Das Spiel muss bei jedem Kauf die Pushwoosh-HWID des Spielers übergeben:

• Unter iOS als appAccountToken.
• Unter Android als obfuscatedAccountId. Das Spiel übergibt den Wert von getSubscriptionAccountId() aus dem SDK, also Application Code und HWID zusammen, nicht die HWID allein.

Ohne diesen Wert erhält Pushwoosh die Benachrichtigung, erfasst aber kein Event, und früher gekaufte Abonnements lassen sich später nicht mehr zuordnen. Teilen Sie Tracking von App-Store-Abonnements und Google Play-Abonnement-Tracking mit Ihren Entwicklern.

Die Events decken nur Abonnements ab. Einmalkäufe, etwa ein Münzpaket, kommen weiterhin als PW_InAppPurchase an.

Spielerdaten in Tags speichern

Ein Tag 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.

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.

Eigene Tags

Ihre Entwickler senden Tag-Werte aus dem Spiel, oder Sie können sie aus einer CSV-Datei importieren. 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.

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

Standard-Tags

Pushwoosh speichert diese Standard-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.