Integration with Omniata is also possible without using SDKs. The Omniata API guide provides details about the functionality available when integrating without SDK. The following aspects should be taken into account when integrating directly from server side.
The server must relay events of one user in exactly the same order as in which the client sent those events in the first place. 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. You can find more details and examples in the Event API guide.
|Event Name||Parameters||Example||When is it sent?|
|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.|
|(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.|
|When verified real-world revenue is made.|
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.
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=220.127.116.113 Accept=*%2f* X-Forwarded-Proto=http
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.
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.
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.
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.
Calling the Channel API from server side is no different from the SDK operation mode. As with the event integration, you must ensure that the order of events stays true to the origin for the segmentation in Omniata to work properly. Once you receive the content you can forward or preprocess it as needed.
Check out the Channel API guide to access more details about the server side integration.