There are several causes for this so please check the following:
There are several potential causes for this. Please check the following:
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:
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.
Omniata uses two methods for determining the country code of a user:
Omniata stores two different country code values for the user:
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.
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.
1. Create an Event Field with the following :
2. Create a User Field with the following:
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:
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.
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/101, 2014/01/02, 2014/01/15
Now the retention numbers for acquisition date 2014/01/01 are as follows:
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.
Session data and session length is calculated in Omniata by the following:
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; Else // 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 End last_event_time = event_timestamp; // update last event time
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.
Omniata's platform has several components, some of which are updated on different schedules:
|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|
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.
Conversion rate is the percentage of users active today that spent money divided by all users.
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:
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.
The default timezone is UTC, and it is not adjustable.
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.
Events sent to the Event API will be available shortly after UTC midnight for that calendar day.
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:
Once the email looks ready, you can set up a new Omniata account associated to an email alias (i.e. email@example.com)