Q: How often is my data updated?
A: The data is available in the event browser QA tool within about 5 minutes of being sent to the system, the metrics that drive the Engage campaign segmentation are updated within 10 minutes of the event happening. The dashboards and analysis tools are typically updated every 1-2 hours.
Q: Do you have a fair usage policy?
A: In consideration of your payment of the applicable charges, Unity shall provide the deltaDNA Platform Services to you in accordance with these UGS Terms.
Fair and Reasonable Use of the Service. The charges are based on fair and reasonable use of the deltaDNA Platform Services as defined below (unless specific provisions have been made in the Offering Identification):
- Direct Access Queries: average of 250 per day during month;
- Events: 100 per daily active users (“DAU”) average during the month;
- In-game engagements: average 20 per DAU during the month;
- Out-of-game messages: average 12 per monthly active users (“MAU”) during month; and
- 50 maximum active segments.
These metrics are calculated and monitored for each calendar month based on activity within that month. In the first instance, Unity and you will work together to adjust performance to work within these criteria. If you are unable to work with Unity to manage your deltaDNA Platform usage within these thresholds, then an additional fee may be charged. MAU is calculated on the basis of at least one Event being collected for each unique user ID provided by you to Unity. A user ID is deemed active and counted in the MAU count for that month if it triggers at least one Event that month or if you send an Event linked to that user ID to Unity.
Q: My game is multi-platform, should I set up different environments for each platform or have one singular environment?
A: The system lets you define the platform as a parameter in the event, so by sending this you can use a single environment. This is exposed through all the tools including a filter on the dashboard. The alternative is to use different environments, both options work but our recommendation is to use a single environment and the platform parameter.
Q: Do you support HTTPS for event collection and engage?
A: Yes, the collect and engage URLs support HTTPS as well as HTTP.
Q: How can I ensure accuracy around revenue tracking?
A: The system supports revenue validation using the transaction receipt from the IAP to verify that the revenue is valid.
To set this up please see the section transaction validation in our SDK documentation.
It works really nicely as you will see only validated revenue in your dashboards, but you can also drill in to the validation data in Data Mining to get a feel for the scale of false purchases. You could even use Engage campaigns to alter the game behaviour for those users.
Q: What are the pros and cons of implementing an REST API vs an SDK?
A: The data is sent to the system through a REST interface. The SDK’s are wrappers for the REST interface which provide helper methods to make creating the JSON simpler and also provide a local storage for mobile devices where connectivity is an issue. There is nothing to stop you using the REST API on any device including mobile and some developers have done this as they are looking for total control of the data flow. The SDK’s provide easy implementation of some features such as image messaging and push notifications. The REST API will always provide the low level support, the SDKs provide a higher level implementation which should make integration easier.
Q: My game has launched and now I see a lot of invalid events in the event browser with the reasons “Duplicate event” and “Event timestamp outside valid boundaries”.
A: Duplicate events occur when the game has not received an OK on sending the events but it has already managed to send the events. It will then retry and the same event will be received twice by collect. Our SDK’s as of version 4.1 will send a unique ID for each event, once we see the same ID twice we will consider the second one invalid. Usually these errors can be ignored and they can therefore also be filtered out in the event browser. The event timestamp outside of valid boundaries error will occur when the eventTimestamp is set by the device and the timestamp is either more than a month in the past or more than 2 days in the future.
Q: I want to send some events from a server or a 3rd party service outside of the player session. I won’t have access to a player sessionID and I don’t want to generate a new one as it will incorrectly inflate my player’s session count.
A: These are called GHOST events, they record valuable player information but are sent outside the player session. These are likely to be attribution events or transaction events that have come from a 3rd party payment provider. In these scenarios you can safely omit the sessionID parameter and value on any events that you wish to exclude from session counting and session length calculations.
NB : If you have game events that were created before Jul 2016 you will need to contact support for assistance if you wish to change any sessionID parameters to Optional.
Q: Can I access or download historic archives of my data.
A: Yes, when you add your game to the deltaDNA platform you should specify the name of an Amazon S3 Bucket on your own Amazon account that will be used for archiving your data. deltaDNA will automatically copy compressed CSV files containing your event data to your S3 Bucket, multiple times per day as events are processed.
Q: The retention numbers look high, the game has been running for a number of months before implementing the deltaDNA analytics SDK.
A: New users are defined as the first time deltaDNA sees the user and not the newPlayer event. The reason for this is that not all games send a newPlayer event accurately or at all so relying on this event would make these charts unusable. The effect of this is that games that have an existing user base will show a higher initial retention rate as existing players will be counted as new players in these charts. This will settle out over a couple of week.
Q: What is the difference between the Return Rate and the Retention charts.
A: The Return Rate graph looks at the number of active users on a highlighted day and compares that to the players playing N days before the highlighted day, showing how many of those players from N days ago were playing on the highlighted day.
The new player Retention considers only players who have installed on the highlighted date and shows the percentage of players that come back on day N after installing.
The new player Retention usually shows the most drastic changes over time, the Return Rate can be used to focus on the behavior of returning players.
Q: Can I view the different currencies coming in from my transactions?
A: The dashboard will convert the currencies to a single currency of your choice which is defined at set up. This is so you can get an easy to see representation of the revenue being generated. The original currency is stored in the event and using the data mining tool you can inspect and query the individual currencies.
Q: How long do I have to wait until Decision Point or Event Triggered campaigns that I have set-up go live.
A: It can take up to 5 minutes for A/B Tests and Targeting to go live.
Q: How frequently are user segments updated?
A: There are two types of Segment that you can create.
- Metric based segments will go live within 5 minute of you setting them up and are continually refreshed as new events that influence them are processed, this is typically within 4-5 seconds of an event arriving.
- Event based segments are processed once every 24 hours in the early hours of the morning (UTC) or upon saving. This is because they are not solely based on live events updating a player’s state, like the two segementation types above. Target lists can be based on queries that look deeper in to the data and therefore target in-activity or combinations of events. e.g. Target Whales who haven’t played in last 30 days.
Q: What do the communicationState values mean in my outOfGameSend event?
A: There are a few different values you might see and these represent how successful an out of game campaign was in sending an action. The values and their meanings are as follows:
- SENT : The action was delivered to the third party successfully.
- DUPLICATE : There are multiple target users with the same token and the action will only be sent to the most recently active user – the other user(s) will get an outOfGameSend event with a DUPLICATE communicationState.
- FAIL : An attempt was made to deliver the action but the third party has indicated that this token is not valid – generally due to the user uninstalling or disabling push notifications.
- OPTED_OUT : This is recorded for users who have never allowed the token to be stored – this is generally due to the user not getting to the push notification ‘registration’ point in the game or the user preemptively disabling notifications.