Omniata allows to you to create data visualizations with easy by providing easy flows for designing the visualizations and managing the underlying data transformations. In the following we will show you how to organize your data visualizations with dashboards, creating visualizations with widgets, selecting a sub-set of data with filters, designing custom data transformations with data fields, and managing the data transformations with tables.
Before diving into visualizing your data, we need to review how to organize your visualizations. The visualizations are organized in Omniata through Dashboards. A dashboard contains typically a set of visualizations (called widgets in Omniata) organized into a single page.
In the following we have an exercise on how to create a dashboard. Please follow the instructions below.
Go the pre-installed Training Project. Under the 'Dashboard' you will find '+ Add Dashboard'. Adding a dashboard opens up the following:
Name the dashboard.
Parent Group - when you start having several dashboards you might find it useful to start grouping them based on specific themes. Selecting a parent group will nest the new dashboard under the parent one.
Permissions - You have an option to set different access rights per dashboard. We cover the permissions in more detail in the chapter focused on access control and defining user groups.
Create the dashboard by saving it. The result should like this:
You have now created your first dashboard. This means that you are ready to move on the next chapter that focuses on visualizing your data through Widgets.
In Omniata, the data is visualizing through widgets. A widget can be a table, chart, or timeline depending on use case and chosen method for visualization. Different types of visualizations will convey the intended message potential in different ways thus Omniata enables users to select from several different visualizations. Below are a few examples.
Widgets are built on top of Tables. These tables contain all the data needed for creating widgets. If data is missing, a new reporting table can be created.
In the following we have an exercise on how to create a widget on top of an existing table.
Let’s go to the Training Project. Navigate yourself to the dashboard that you created.
You will see on the page an empty dashboard with an option to ‘Add Widget’
Let’s build a widget! Clicking on the Add Widget will open up this:
If you like tables, you can simple save this, but let’s try out a different visualization. This is done through the Widget Settings and its options. The Widget Settings can be found right under the Preview screen.
First widget! Well done! In the next chapter, we will take a look at how to filter results so that you will only the data that you really want to see.
By default a widget shows all data available, but often there is a need for viewing only part of the data. Omniata allows you to add filters on any data available in table upon which the widget is build on. The filters can range from common use cases, such as days that the user was active, or application specific data, such as user level.
In the following we have an exercise on how to add a filter.
In the Training Project, you created a dashboard where you added a widget. Let's add some filters there.
Click on the ‘Would you like to add a filter?’, which will lead you to the Dashboard Edit page. Here you can edit the name of the dashboard, add/edit filters, and re-arrange widgets. We will here focus on adding a filter. Select ‘Add Filter’ and then you will see this:
Select the data field ‘ User Level’ to filter the data per level. Feel free to explore the other options instead of ‘is one of’. Save the filters at the end of of the page. The end result should be like this:
You now have added a filter. Test it out by selecting a few levels.
Data Fields are another key concept in Omniata. They define how the data is being transformed from raw event data into formatted data that can be used in data visualization as well as in engaging user with targeted content.
Omniata has several different kinds of data fields. They include:
We will not review all of these here in detail, but leave that for later chapters focusing on data modeling. The focus here will be on the most common uses cases. Getting familiar with them will take you a long way in building unique visualizations and engaging with your users.
This is the most basic and common case. Event Parameter Field simply returns the value received in an Event Parameter, without any transformation.
Counters allow you to calculate the number of Events (Count Events) or number of unique users (Count Distinct Users).
Event Formula gives you the greatest flexibility to define the transformation. You can use scripting language Lua to write a formula (function) which takes Event Parameters, Event Meta Data, User State (System User Fields) and/or User Variables (Custom User Fields) as inputs and produces an output.
System User Fields are Data Fields which represent values from User State. User State contains basic user properties, such as acquisition date, acquisition country, last known country and lifetime session count. System User Fields can not be created/edited by users.
Custom User Fields can be used for storing user properties or other information per user. Some basic user properties are in the User State, accessible through System User Fields, but any other custom data can be stored as Custom User Field. Thus, Custom User Fields are in a sense extension of User State. Custom User Fields can be created/edited by users.
Table Fields are SQL formulas, that can be used in Tables (to be covered in the next Chapter). These formulas can take as input other columns, and return a value that is available to be used in a table. Table Fields effectively extends a table with virtual fields, creating new metrics calculated on-the-fly, as a function of existing data. A good example is ARPU (Average Revenue Per User) defined as sum(revenue) / sum(users), where revenue and users are already existing columns of that table.
It is important to keep in mind that Table Fields do not transform events, nor have access to the Event Parameters or User State during event processing. Table Fields are calculated over already aggregated Tables. Thus the input for these formulas are existing columns.
In the following you will create a few data fields that are going the used the following chapter where the focus shifts to tables. Table is the key component upon which you will build your visualization on. Data fields are the main components of tables.
Navigate yourself to Data Model > Fields. To create a new data field, select the ‘New...’.
We are creating a Counter Event Field, so select ‘Event Field’. This will open up a page that looks like this.
Do the following:
Create ' New...' > 'Table Field' and you will see the following:
The aim is to create a table field that indicates the number of attack per user. Let's call this field 'Attacks per User'
The data type will be a decimal number as we are dividing values.
The data source field asks you to insert the SQL formula. For this you need get the correct source names for the SQL from the Data Fields list from ‘Name’ column and use the machine name under the actual name. The SQL formula should look like this:
Then just go to the end of the page and hit ‘Save’.
You have now created two Data Fields. Next up - Tables! In the next chapter, you will take a look at how to structure your data in order to create unique visualizations.
All data visualizations in Omniata are based on Tables. What are tables? They are data tables which aggregate data from incoming events and are then used for building Widgets. As events are coming in on user level events, they need to be aggregated from potentially millions of rows of data to more aggregated format that pools user with similar attributes together. This allows showing overall measures, which can then be visualized in Widgets. No worries if this seems complicated. We will cover this again when going through the exercise.
Navigate yourself in the Training Project to Data Model > Tables, and you should see the something like this:
Select ‘New...’ and choose ‘Event Based Table’. The table builder is very similar to the widget builder that you used to create the first widget. Please take a look at the setup below and repeat it.
Save the table and you should see this:
What you created is a schema on how the data is going to be used in the data visualizations. Next step is to fill in the table with data. You can see an option ‘Run’, which allows you to backfill the table. Select ‘Run’ and you will see the following:
After selecting the date range (please check from the dashboards for which dates you have data for), start the data processing by clicking on ‘Create Job’. As a result, you will see something like this:
For a short job, the results should in after a few minutes. If you are having a longer date range, you will need to wait a few minutes more. The end result will look something like this:
And you are done creating your first event based table! Let’s wrap-up by creating a widget with the data in the table that you just created.
Create a dashboard ‘Attacks’
Create a new widget ‘Attacks per User’
Select ‘Attacks per User’ as the table
(Insight) You have an option also to create a reporting table directly from the Widget Builder by selecting ‘New Reporting Table’ and using the Builder to select desired dimensions and measures. Choose options that you like to have and run the job. This is alternative way for creating tables.
Select the dimensions and measure you like to visualize.
Choose the visualization that works best for you.
Save the Widget.
You have now completed the visualizations starter kit for Omniata. Congrats!