Best practices

The performance of the EMMA SDK can be linked to the integration made in your App. Therefore it is very important to know the good practices in the integration of EMMA in your App.

EMMA allows you to send and receive information from your App using different methods:

  • SDK
  • API Master
  • Data export (CSV)

EMMA allows you to send the content of the different communications to users of your App from our platform through the EMMA SDK integrated into your App.

The sending of data to and from the different communication formats is key in the content request time and its publication in your App.

EMMA SDK functions for communications

The main function of the EMMA SDK is to record user activity and check if the device has in-app campaigns available, connecting via HTTPS protocol to EMMA servers.

EMMA servers continue the activity and  check the availability of campaigns in the EMMA backend.

Communication with EMMA servers

An event queue is used to communicate with EMMA servers. If the events do not require user interaction (events that do not have an automation rule), they are accumulated and sent every 30 seconds to the server in order to minimize the number of HTTPS requests made by the application and limit the impact of requests in application performance.

In the event that the event record has an associated rule, that call will cause an immediate emptying of the queue, sending all pending events in the queue along with the request of the rule. We differentiate the rules, since they are requests that wait for a response treatment to determine if the user has in-app campaigns available for that rule.

In the case of in-app calls, we have the same behavior as the rules, there is an immediate emptying of the action queue, sending all pending records.

Response times may vary depending on the implementation. Check the average times for each In-App format.

EMMA SDK implementation recommendations for communication campaigns

  1. To prioritize an in-app campaign, we must invoke the method to recover the screen before any other event so that a call from that campaign is made in a unique way.

  2. If we are not going to use the automatic events, it is advisable to turn off the functionality from the SDK as it can increase the number of events transmitted and slow down communications.

  3. Only events that are really going to retrieve in-app campaigns should be activated as a screen. The registration of these events is slower than a normal event because it involves more actions.

  4. Whenever we need more than one NativeAd on the same screen, use the so-called "batch" that optimizes the recovery of those spaces.

  5. If we mix rules, with in-app campaigns, we have to make sure that in-app campaigns are invoked before, so they can be retrieved on separate calls.
Have more questions? Submit a request


Article is closed for comments.