Close

Applications - Server-to-Server

Integration with Omniata is also possible without using SDKs. The following aspects should be taken into account when integrating server-to-server.

Event Headers

All event headers must include the IP address of the user in X-Forwarded-For field. Omniata uses the source IP address of Event API calls when determining the country of the user. When events are relayed through server, that IP address is the address of the server. In order to the country detection to work, X-Forwarded-For HTTP header must include the IP address of the user.

host=example.analyzer.omniata.com
Connection=keep-alive
X-Forwarded-Port=80
X-Forwarded-For=44.99.222.333
Accept=*%2f*
X-Forwarded-Proto=http

Real-Time Event Streaming

Events should be sent from the server to Omniata with minimal delay. The server must have the capacity to relay the event stream also during peak moments. The server also needs to do the mapping from internal data format to Omniata event format, which should be remembered when considering the capacity. Real-time event streaming is especially important when the data is used for real-time targeting in content delivery.

Event Flow

The server must relay events of one user in exactly the same order as in which the client sent those events to the server. Correct event flow is important for example for valid country and progression data. Valid event flow can be achieved by placing the events in a FIFO (first in, first out) queue when they reach the backend server, and then sending the events from the queue.

The order in which the events are sent during user's session is critical. Having correct event flow ensures that for example country and progression data is valid. The overall structure and order of the events must be checked during integration. The following templates can be used for this purpose. Some common parameters have been added as an example.

Event Name Parameters Example When is it sent?
om_load api_key
uid
om_platform
om_event_type
om_locale
om_sdk_version
game_version
om_device_id
om_device
om_os_version
000000
1234567
android
om_load
en_US
1.0
201411051900
0987654321
Nexus
4.4.4
The first event when game starts and when game goes to foreground. Only when the UID is known, this means that it should not be an install event unless the UID is known.
om_user api_key
uid
om_platform
om_event_type
country
dob
gender
om_locale
om_timezone
game_version
user_name
000000
1234567
android
om_user
US
1989-01-01
M
en_US
CEST
201411051900
Jon Doe
(Optional) If additional user data needs to be passed on. In that case, after the first ever om_load and always when information of any of the parameters changes.

All subsequent events should be sent in the same order in which the action they're representing occur in the application. This is especially important if the events are sent to Omniata through a backend server.

Event Name Parameters Example When is it sent?
om_revenue api_key
uid
om_platform
currency_code
total
om_event_type
game_version
000000
1234567
android
USD
1.99
om_revenue
201411051900
When verified real-world revenue is made.
om_apns_enable api_key
uid
om_platform
om_event_type
om_device_token
000000
1234567
ios
om_apns_enable
ABCDEFGHIJK
When an iOS device token is available or when enabling Apple Push Notification messages to the user.
om_apns_disable api_key
uid
platform
om_event_type
000000
1234567
ios
om_apns_disable
When the user has Apple Push notification enabled and wishes to disable it.
om_gcm_enable api_key
uid
om_platform
om_event_type
om_registration_id
000000
1234567
android
om_gcm_enable
ABCDEFGHIJK
When Android registration ID is available or when enabling Android Push Notification messages to the user.
om_gcm_disable api_key
uid
om_platform
om_event_type
000000
1234567
android
om_gcm_disable
When the user has Android Push notification enabled and wishes to disable it.
User Defined Events api_key
uid
om_platform
om_event_type
...
000000
1234567
android
ABCDE
Whenever an action of interest have been performed.

Error Handling and Retry Mechanism

The event sending system must be able to handle errors and failures in event sending, for example in case of lost network connection, while preserving the event and its place in the event flow. The system also needs to include a retry mechanism to account for timeouts in case they occur. For example, in case an event sending queue is used, each event needs to be removed from the queue only after an OK response is received for the event sending request.

Data Volume

High data volume can cause a bottleneck during event streaming if a single thread is used. In case that several threads are used, please ensure that the events of each user are sent in the original order. Omniata recommends to follow a hashing schema based on the UID to load several threads of event senders. The hashing schema consist of having an X number of senders (threads of event creations) delivering events in FIFO manner. Lets assume we have X threads, namely 0, 1, 2, X-1 for example. Each sender would have its own queue. For each event, you would then calculate y = CRC32(uid)%X and place the event in the queue of thread y. That way, all events from one user are placed in same queue.

If X is large enough (depending on the load of users and number of events), the size of each queue will stay small enough. For example, if the over-all load is 100 events per seconds and sending one event takes 200 milliseconds, and thus one queue can send 5 events per second, there needs to be at least 20 event sending queues.

This article was last updated on December 11, 2015 00:32. If you didn't find your answer here, search for another article or contact our support to get in touch.

Contact Sales

Add Phone Number