Launch and measure
Este conteúdo ainda não está disponível no seu idioma.
Test every journey on your own phone before real players get its messages, then check whether it works.
Test each journey before you launch it
Anchor link toA journey has no test mode, so once it is running, real players who match its entry get its messages. Testing on your own phone first catches a missing event, an empty segment, or a wrong message before players see it.
Run through this list for each journey:
-
Install the version of your game that includes the Pushwoosh SDK on your phone, and log in with a test account. If you do not have one, ask your developers for a test version. The phone must register in the application where the journey runs. To send test messages from presets, also register it as a test device.
-
Play the game and do what the journey needs, for example complete a level. Then open Audience → User Explorer, find the test device, and check Events history. The events must be there with the expected attributes, or the segment and the journey do not see them.
-
If the journey starts from a segment, open it in Audience → Segments and refresh its size to see whether it counts any players.
-
Launch the journey for your test players only. Build a test segment from your test User IDs with the User ID filter. If the journey starts from a segment, use the test segment as its entry. See How to test a journey with a test segment.
-
Start the journey on the test phone: do the action that the entry waits for. Check that the message arrives, and follow the test player with Find user path.
-
After a day, check how many players entered the journey. See Read the journey statistics.
Read the journey statistics
Anchor link toJourney statistics show whether players enter a journey, get its messages, and reach its goal. To see them:
- Open the journey on the canvas. The statistics panel on the left shows the whole journey.
- For numbers on each element, open Canvas settings (the gear icon in the bottom-right corner) and turn on Show metrics. See Journey element statistics.
For what each metric means, see Overall journey statistics.
In the first week after launch, look for these signals:
| If you see | It usually means | What to do |
|---|---|---|
| No entrances | The entry segment is empty or the entry event does not arrive | Repeat steps 2 and 3 of Test each journey before you launch it |
| Far fewer messages sent than entrances | Many players can’t get push, or frequency capping and the silence period hold messages back | Check Frequency capping in Communications, add an in-app or email branch after a Reachability check, and check your delivery rules |
| Many drop-offs | Players left the journey because of a problem, such as a device that was not found or an invalid push preset | Expand the Drop-offs block on the element to see the reasons |
| Messages are opened, but few players reach the goal | The message works, but the offer or the moment does not | Test another text or offer with an A/B/n split |
Journey statistics count goal conversions, not revenue. To compare revenue, use Conversion events.
Measure results
Anchor link toTo measure whether a journey changes player behavior, use the three tools below, from simplest to strongest.
-
Conversion goals: every journey in this playbook has one. The goal can be reached within the period you set, up to 30 days after the player leaves the journey. See Conversion goals.
-
Holdout Split: hold back 1% to 20% of the players who reach a Holdout Split element and compare their goal rate with everyone else. The Goal uplift vs holdout report updates once a day.
-
Control group: by default, holds out a share of the players from all marketing messages in the application, so you can measure the combined effect of your messaging. Set it up before you launch. See Set up a control group before you launch. To read the results, see Analyze control group impact.
Common pitfalls
Anchor link toThese are the mistakes that most often leave a segment empty or a journey silent in a mobile game. Check them before you launch a journey.
| Pitfall | What happens | What to do |
|---|---|---|
| A guest who plays on two devices | Until the player logs in, each device has its own User ID, so one player counts as two | Identify players by User ID |
| iOS push permission prompt | iOS shows it only once, so a player who declines on the first launch can’t be asked again | Ask for push permission at the right moment |
Repeating events such as Level completed | They fire many times a day and start the journey again and again | Set a campaign entry limit. See Best practices for every journey |
PW_ApplicationOpen | It fires each time the game comes to the foreground, not only on cold launches, so open counts run higher than sessions | Segments by events |
| Purchases | On iOS, only products configured in App Store Connect are tracked, and on Android the game sends purchases from code | Default events |
| Store subscriptions | Without appAccountToken on iOS or getSubscriptionAccountId() on Android, subscription events are not recorded | Track subscriptions from the stores |
| The Unity plugin | It has no Message Inbox, so a Unity game can’t show App Inbox messages | Use push or in-app instead. See Live event and VIP announcements |