This document provides the guidance to start a successful integration with Kubit's Self-Service Analytics. It covers the different approaches to share your data with Kubit and also how to get your metrics configured properly. It also includes the best practices in data model design and implementation as a reference.

This is a warehouse-native type of integration where Kubit connects directly to your data warehouse through a secure connection. This means you will always have real-time access to your data, full control over it and be able to maintain a Single Source of Truth. Check out the Direct Connect page for more details on supported data warehouses and the integration steps for each.

If you are already collecting data through a Customer Data Platform (CDP) such as Segment, Snowplow, Rudderstack, mParticle, you can configure a Snowflake Destination to a Kubit account to materialize all your analytical data there. In this way Kubit can again cover all the compute and storage costs for the Self-Service Analytics.

In case you are running an on-premise data warehouse such as Presto, Spark, ClickHouse or Vertica you can also share your data with Kubit by uploading daily exports to a storage service (see our S3 guide). The data will then be loaded into a Kubit-managed data warehouse and still cover all the compute and storage costs involved with Self-Service Analytics so there is no impact on your data operations and budget.

Your data should already be stored in data warehouse tables for analytics purposes. They should also be updated frequently to stay live. Here are the key considerations for the integration and some best practices.

Data model is sometimes presented as an ER (Entity Relationship) diagram. It captures the relationship between all the entities in your database.

It is not preferred to share schema-less transactional data (i.e. database tables used for serving your users) into the data warehouse for analytics purposes. A star schema is the most recommended pattern for storing analytics data.

If your current data model is different, don't worry, there are many creative ways to address that by collaborating with your data engineers.

The fact tables store information about when something happens (events), some inline properties (e.g. timestamp, country, app_id, app_version), and some dimension keys which can be used to lookup for the dimension values in dimension tables (e.g. user_id to lookup user's email in users table, campaign_id to lookup for a campaign's start and end dates).

In most scenarios, it is recommended to use inline properties on the events as much as possible, i.e. capture most dimensions' values as properties and store them on every event. It simplifies the query and also improves analytics performance dramatically. Modern analytical data warehouses like Snowflake have built-in optimizations to store duplicated column values very efficiently. If you are interested in this topic, read more about Columnar Database.

Implementation of ETL (Extract, Transform and Load) to populate the star schema from your transactional data is out of the scope for this guide. Though feel free to contact Kubit support to get additional information or advice on this topic.

Every user, regardless of registered or anonymous (guest), requires a unique identifier for the analytics to work. Counting unique users and following a user's behavior (action events) are the most common analytical measures.

We understand that User Identification can be complicated because the relationship between a person, different apps, their devices and credentials can be complex. We will work with your team around considerations of privacy, fraud, hacking, device and credential sharing to ensure the best solution is made available. Our flexible data model allows you to be in control of user identity definitions.

Conceptually, there are several IDs:

Events are generated when a certain action takes place. For example: Login, Stream, Vote Up, Page View, Button Click. It is the most critical data structure for analytics.

Data Dictionary

Events need to be instrumented in the code on both mobile (in the app) and server (backend) sides because some events are triggered by user actions, some by backend processes (e.g. subscription renewal, push notifications sent).

If you are starting from scratch, there is no need to reinvent the wheel. It is recommended to use a CDP (Customer Data Platform) like Segment, Snowplow, Rudderstack or mParticle to give you a mature SDK and the maximum flexibility to control where the data goes.

Technology aside, the key of a successful instrument project is communication. Keep in mind that the engineers who are injecting the events into code flow don't usually know how these events are used in analytics. Providing this context information is often critical to avoid bugs and surprises down the line.

There are two kinds of properties for the events: Common Properties and Event Properties. A property can be categorical (enumeration of values) or numerical (unbounded continuous values).

These are the properties that every event should have. Usually they are used in filters or breakdowns as dimension attributes. Here are some examples:

Each event can have its own set of properties depending on the context. It is recommended to store them in a set of named generic properties instead of introducing ad-hoc properties on the fly. This way the database table schema can be kept clean and efficient. These generic properties can be explained and managed using Data Dictionary. Here are some examples:

Any timezone conversion during query time will kill the performance.

The complex issue of timezone arises when any date or time is presented in text format, as in every analytics report with dates (MM/DD/YYYY). It is recommended for the organization to decide on using one certain timezone across the board for all analytics purposes. Usually the selected timezone is where the headquarter is based since it is much easier to talk about local dates in business settings.

This section provides guidance on how to convey your organization's definition on metrics (KPIs) and dimensions.

Please provide a list of top metrics for your product analytics needs. Most of these metrics can be presented in simple math formulas with measure functions, along with some filter conditions. For example:

Please provide the definitions of all the dimensions needed in the analytics. Most of these dimensions can come from the event's properties. Some dimensions require joining with dimension tables during query time. Here are the information needed:

Cohort is a group of users matching certain criteria. You can define these cohorts to be used for breakdowns in any Report, Prediction and Braze Integration using very similar definitions like a query with measures, filters and conditions. For example:

For a SaaS solution, security is always on top of the priority list at Kubit.

Kubit utilizes Auth0, the leading Enterprise Authentication and Authorization Platform to handle all user security and management.

If your organization is using enterprise user identity services like Google G-Suite, Active Directory or LDAP already, Single Sign-On can be enabled with Kubit through Auth0. There are no extra credentials for users to remember and your IT department has full control over who has access to Kubit.

To start simple, you can also just provide several users' email addresses to get them provisioned on Kubit directly. They can login to Kubit with email and password. Also MFA (Multi-Factor Authentication) can be enabled for these users too to add more security.

Support

If you have questions or need help you can: