Skip to main content

Limitations

Different limitations currently apply for sending events:

  • Size of POST request
  • Event field validation
  • Event count and cardinality limits

Size of POST request

The collector has a POST size limit of 1MB in the request body. Read more in the troubleshooting section on 413 status codes.

Event field validation

When events are submitted they will each be validated. These validation rules are listed by each event in this documentation. Read more in the troubleshooting section on 400 status code.

Event count and cardinality limits

GameAnalytics integrations should follow the limit guidelines provided and make sure the data sent by the game will not breach the defined limits.

Troubleshooting​

The servers validate fields and reject events that do not pass. Therefore it is valuable to know which field(s) did not pass validation and the reason why.

The most common HTTP response status codes 200, 401, 400.

200 : OK

The request went well. All possible events sent were collected successfully.

401 : UNAUTHORIZED

Authorization could not be verified. Either the game keys are not correct or the implementation is not done properly for calculating the HMAC hash for the Authentication header.

413 : REQUEST ENTITY TOO LARGE

The collector has a size limit of 1MB in the request body. If the post body is less than 2 times the max limit (between 1M and 2MB) you get a 413 response code. If it is bigger than that you will get a closed connection from the collector.

Therefore when submitting a large amount of events the code should split them up. Use multiple requests one after the other. Again it is highly recommended to use gzip as this will reduce the size significantly.

400 : BAD REQUEST

This can happen in the following scenarios.

the data sent was not valid JSON (unable to decode) the JSON data sent was not a list the JSON contents (events) failed validation

In the first 2 cases there will be very little information in the response.

The last case will happen when one or more events fail to match it’s validation schema.

The servers will then not collect the failed events but still collect the valid events. Then reply with a JSON string containing a list of objects for each event that failed. Each error object will contain information about all the fields that might have failed validation for that specific event and also include the event fields that were submitted.

When receiving a 400 status code during implementation please review the response JSON to ascertain if it’s valid and a list. Then review what fields did not pass validation and fix.

If a batch contains two events (A and B) and A fails validation but B passes then A will be rejected and B collected.

Due to this – do not resubmit event data when a 400 response is received.

Look at the following 400 response error reply snippet example in JSON:

[
    "event": {
        "connection_type": "wifi",
        "session_num": 1,
        "session_id": "b887216b-3cfa-11e5-b8a9-a8206618c53b",
        "device": "iPhone6.1",
        "manufacturer": "apple",
        "category": "user",
        "user_id": "AEBE52E7-03EE-455A-B3C4-E57283966239",
        "client_ts": 1438948324,
        "os_version": "ios 8.2",
        "custom_01": "ninja",
        "engine_version": "unity 5.1.0",
        "platform": "ios",
        "sdk_version": "rest api v2",
        "build": "alpha 0.0.1",
        "v": 2
    }
]

Re-submitting events​

When queued events are sent to the collector servers they should each be marked locally as being submitted.

If the attempt failed due to no connection (no network etc.) or 413 (body too large) then the being submitted events should be put into queue again. If you get a 413 then try to split the events into even smaller batches and then submit. For all other responses (200, 401, 400 etc.) these events should be wiped.

Do not keep events and resubmit based on other reasons than offline or the 413 response.

In production a 400 response should be logged and the implementation fixed for the next time the game is released.

Character Encoding​

Make sure your character encoding is UTF-8 for strings. Certain event_id strings require specific characters validated by matching a regex.

An example is the progression event_id string. This requires a match for this regex:

^(Start|Fail|Complete):[A-Za-z0-9\s-.\(\)\!\?]{1,64}(:[A-Za-z0-9\s-.\(\)\!\?]{1,64}){0,2}$

The validation for this event_id can fail if using UTF-8 strings dynamically (like level names). These might contain other characters then just a-Z and numbers. Make sure to encode strings to support the requirements.

Users are reporting issues with failing authentication using the UTF-8 standard in Java. In this case make sure you encode to the ISO-8859-1 standard instead.