General FAQs

Why is the data I'm sending is not displayed on the panel? Why is my data missing?

There are several causes for this so please check the following:

  • Reset your filters (might show old data)
  • Refresh the page (data cached)
  • Check the Environment (this should usually be Production unless you are specifically looking at test data)
  • Check event flow (use the Event Console)
    • API key
    • Event Types
  • Omniata daily processing is still running

Why is my data not showing correctly?

There are several potential causes for this. Please check the following:

  • Check your filters and reset them if needed. Remember that filters are both on dashboard level (right side of the panel), and on the widget level (set in the widget builder as Conditions)
  • Check that you have added all the right event types to the Project
  • Check that you have added all the right parameters to the Project
  • Check the Fields. Review carefully all the used fields. The sources and conditions have significant impact on how data is processed and visualized.

Another situation that can cause confusion is when two charts report different values for the same metric, such as DAU or revenue. When comparing the results returned by two widgets, always remember to consider:

  • Are there dimensions being used that can effect the count of users?
  • Are there transient dimensions?
  • Are both widgets using the same environment?
  • Are either of the underlying Tables scoped to a particular type of event?
  • Are the visible filters the same?
  • Are hidden filters being used, either in a dashboard or within a widget?

How are new users created?

A new user is created by any event with a unique tuple of Environment ID, Project ID, and UID that has not been seen before. The API key defines the first two parameters, so any combination of API key and UID that has not been seen prior will be considered a new user.

How does the country detection work?

Omniata uses two methods for determining the country code of a user:

  1. From the Event Type om_load, Omniata gets the value of the source IP address, or if it exists the header X-Forwarded-For ( Then it does a country lookup based on the IP address using the geoip library.
  2. From the Event Type om_user, find the value of the "country" parameter and directly use that value as the country code. This overrides the automatic country detection based on om_load event.

Omniata stores two different country code values for the user:

  • System User Property country (user_state['country']). This is the current location of the user, and it can be set daily.
  • System User Property acq_country (user_state['acq_country']). This is the location of the user on acquisition date, and it can be set only during the acquisition day. The value is determined based on the events (1. and 2.) of the user on the creation date of the user. After the creation date the value is immutable.

For visualization purposes the country code (such us US, DE) is mapped to a human-readable country name (e.g. United States, Germany) using Omniata lookup table.

How is revenue from different currencies handled?

Omniata always displays revenue in USD by default.​ Revenue from different currencies is converted during processing using a table of exchange rates which is updated daily.

How do I get the time a user first sends an event?

1. Create an Event Field with the following :

  • Date Type: String
  • Event Formula:

    if tonumber(user_vars['name of your user field in step 2']) == nil
    then return user_vars[''name of your user field in step 2']
    return"%Y-%m-%d", tonumber(math.floor(tonumber(user_state['datestamp']))) or 0)
  • For the following events:
    [the name of your event_type]

2. Create a User Field with the following:

  • Date Type: String
  • Data Source:
    • Event Field: [name of the event field from step 1]

3. Then update the event formula in the Event Field in step 1 with machine name of the user field in step 2 (the 'name of your user field in step 2').

4. Create a table with the following:

  • Dimensions
    • Activity Date
    • Project Name
    • Project ID
    • Acquisition Date
    • First Event User Field
  • Measures
    • Count of Users
    • Count of Events

How is retention calculated?

Omniata uses strict retention, instead of rolling retention. As an example, consider user who installs an application on January 1st and comes back on January 2nd and January 6th.

  • The acquisition date and day 0 of the user is January 1st.
  • The user is retained on days 0 (January 1st), 1 (January 2nd), and 5 (January 6th).
  • The user is not retained on days 2, 3, and 4.

This is due to the strict calculation of retention. If the calculation method would be rolling retention, the user would be retained also on days 2, 3, and 4, because he/she had come back on day 5.

The formula for "Retention Day N" for acquisition date D is defined as:

(the count of distinct active users N days after date D that were acquired on date D) / (the count of distinct users that were acquired on date D)

As a special case, the retention is undefined for acquisition dates when there are no acquired users, because the denominator in the formula is zero.

The acquisition date of a user is the date when Omniata received the first ever event (of any type) of a user. An active user for a date means that Omniata received at least one event (of any type) for that user on that date.

As an example, let’s consider users u1 and u2 who have been acquired on 2014­/01/­01. They have activity (send events) on the following dates:
u1: 2014­/01/­01, 2014­/01/­02, 2014­/01/­04, 2014­/01/­15
u2: 2014/­0/1­01, 2014/­01/­02, 2014/­01/­15

Now the retention numbers for acquisition date 2014/­01/01 are as follows:

  • D0 (2014/01/01) retention: 2 / 2 = 100 %
  • D1 (2014/01/02) retention: 2 / 2 = 100 %
  • D2 (2014/01/03) retention: 0 / 2 = 0 %
  • D3 (2014/01/04) retention: 1 / 2 = 50 %
  • ...
  • D14 (2014/01/15) retention: 2 / 2 = 100 %

The longer time retention isn’t always smaller than a shorter time retention, however in practice with a bigger user base, that is normally the case.

Because of the definition of the retention in the Widgets the retention numbers are normally available until day before yesterday. That’s because the D1 retention can be calculated for day
before yesterday, and for yesterday no retention can be calculated, since there’s no date for today yet. Similarly, D3 retention is zero for days three days before today and later, D7 is zero for seven
days before today and later.

How is session data calculated?

Session data and session length is calculated in Omniata by the following:

  • Any event will begin a session on a given day
  • A session continues so long as another event is received within 30 minutes after the previous event, provided it is still during the same day (UTC time)
  • Once 30 minutes elapses during a session, where there is no activity, any event will start a new session.
    • If it is the same day, the delta_session_seconds and delta_session_count will both start at the previous value
    • If it is a new day, the the delta_session_seconds and delta_session_count will start over at zero.
  • Session calculation cannot be modified at this time

The first session of a user in Omniata begins with the first event ever received for that user. It will set the system user attributes last_event_time and last_session_start to be equal to the timestamp of the event received event_timestamp. These 3 variables store the value as unix timestamp in seconds since the epoch. The timestamp of the event is set by our server clocks in UTC. So it is effectively the timestamp of the arrival of the event to Omniata.

On first event:

last_event_time = event_timestamp;
last_session_start = event_timestamp;
delta_session_count = 1;
delta_session_seconds = 0;

On any subsequent event the session data is updated, if the time from the previous event is longer than 30 minutes.

If (event_timestamp - last_event_time) > 30 * 60 then
delta_session_count = delta_session_count + 1; // update daily session count
session_count = session_count + delta_session_count // update global session count
// start a new session
last_session_start = event_timestamp;
delta_session_seconds = 0;
// the current session is extended
delta_session_seconds = delta_session_seconds + (event_timestamp - last_event_time); // update daily session time
session_seconds = session_seconds + delta_session_seconds // update global session time
last_event_time = event_timestamp;  // update last event time
Finally, all sessions are closed at the end of the day in order to close the analytics for that day. A fresh new session starts for all users at 00:00 UTC.

What defines an active user?

By default, any event received by Omniata will make that user "active" for that time period; however, if you have a custom definition of an "Active User" (e.g. any user that triggers the om_load event), you can create a custom definition in Omniata.

How often are various parts of the platform updated?

Omniata's platform has several components, some of which are updated on different schedules:

Section Update Schedule
Standard Metrics - General Nightly at midnight UTC
Standard Metrics - Hourly Hourly
Custom Metrics Nightly at midnight UTC, but can be run during the day
Real Time Analytics Real time
Segment definitions Nightly at midnight UTC

What is the definition of active user retention?

Active User Retention Day N is the percentage of active users (both new and returning) that came back to play exactly N days after. This is ideal to detect early any tendency on churn.

What is the definition of conversion rate?

Conversion rate is the percentage of users active today that spent money divided by all users.

How can I create my own custom conversion rates?

To create a custom conversion rate metric, it is necessary to define both the numerator and denominator of the specific metric that is to be created. To create "First Day Conversion", the following Data Fields will need to be part of the Reporting Table:

  • Acquisition Date (suf_creation_date)
  • Retained Days (suf_retained_days)
  • First Time Payers (ct_first_time_payers)
  • Count of Users (ct_users)

With access to these fields, a Table Field can be created to calculate the first day payer conversion with the following SQL:

SUM(IF(suf_retained_days = 0, ct_first_time_payers, 0)) / SUM(IF(suf_retained_days = 0, ct_users, 0)) * 100

This code will get the total number of first time payers on their Acquisition Date (where retained days is equal to zero) and divide this by the total number of users acquired on that day. For "First Week Conversion", similar code is used:

SUM(IF(suf_retained_days <= 6, ct_first_time_payers, 0)) / SUM(IF(DATEDIFF(DATE_SUB(CURDATE(),INTERVAL 1 DAY), suf_creation_date) >= 6, IF(suf_retained_days = 0, ct_users, 0),0)) * 100

The additional SQL code used within the denominator of the metric is used to ensure that the there has been a week or more of data to show. Without this, it would be possible to analyze first week payer conversion for cohorts of users that were acquired less than a week ago, which would effectively penalize their conversion rate as they have not had an entire week for the payers to convert.

What timezone do you report in, and is it adjustable?

The default timezone is UTC, and it is not adjustable.

When is hourly data available?

Hourly data is available 1 hour after receiving the event. It reflects the data for the beginning of the hour displayed. So the 22 hour is the hour from 22:00-22:59 UTC.

When will my events be available for use in the charts?

Events sent to the Event API will be available shortly after UTC midnight for that calendar day.

How do I enable daily emails?

You’ll see the “Subscribe” icon on the top right of each Dashboard page that you view.

Each Dashboard page is considered a Report - which is the information that will be emailed to you daily. You will receive a sample of the email immediately upon clicking subscribe so you’ll get an idea of what the email looks like.

Each user can subscribe to their own email reports - and you can manage your email subscription from 'Profile' accessed from the top right cornerof the panel.

For emails intended for a wider audience:

  1. Create a new dashboard called, for example, “Email”
  2. Clone the desired charts to this new dashboard
  3. Adjust the chart parameters to make them email friendly

Once the email looks ready, you can set up a new Omniata account associated to an email alias (i.e.

Enabling Daily Emails for a Larger Group

  1. Create an Omniata User account with an email address that will forward to the appropriate people
    • Global Settings > User Management > Accounts
    • Example email address:
  2. Send an invite to that email
  3. Log in as that user
  4. Subscribe to the "Email" dashboard that's been set up in the steps above

This article was last updated on February 25, 2016 22:32. If you didn't find your answer here, search for another article or contact our support to get in touch.