API Reference

Data Architecture

Appuri stores data for each of your applications in a separate Amazon Redshift database. This page describes how the data is laid out in the data warehouse.

❗️

Read this carefully

It will help you understand how to send data to Appuri if you understand how the data will be laid out in the warehouse. Resist the temptation to jump ahead and read this section carefully.

Event Tables

Events are stored in several tables to make querying simpler and more efficient.

  1. Raw events are stored in the _events table. With a few small changes, this table contains events just as you sent them to Appuri.
  2. Named events are stored in tables named _e_ENTITY__EVNAME. For example, the user entity's sign_in event is stored in _e_user__sign_in.
  3. Appuri automatically explodes JSON in the body key of the event into columns in event tables.

🚧

What happened to the @set event?

The @set event is special. It lets you set properties on entities. There is no event table created for the @set event.

1148

Event Tables

Property Tables

Appuri allows you to set properties for any entity as described in the Setting properties section. The diagram below shows how properties are laid out in the data warehouse for the user entity, probably the most interesting entity to most analysts.

  1. user entity properties are stored in tables named _p_user__<property>. For example, the latest value of the email property is stored in _p_user__email and the city property is stored in _p_user__city.
  2. Historical property values are stored in tables named _p_history_user__<property>. For example, historical values for the email property are stored in _p_user__email.
  3. Current values of every user property are joined in a materialized table _profiles. This table is very handy as it contains every user and their current properties.
1207

Property Tables