User event data

Auxia's typical engagement removes all the heavy lifting that comes with the data integration. Your teams are only required to share your relevant tables and our internal deployment teams will do all the transformation required to ingest this data into Auxia's system.

Background

Event data refers to records of actions or occurrences, often captured as individual events, with details like the type of action, the time it happened, the user or system involved, and other relevant metadata. These events can come from various sources, such as visitor interactions across your web and mobile applications.

Each time an event occurs on your website or mobile app, it's typically stored as a entry into your analytics database or data warehouse. This entry corresponds to a single row that captures all the specific details of the event, contributing to a complete set of clickstream data.

Here is an example of what that able might look like:

userId	Timestamp	Event	Email	Channel
7f8a3c9d-2e4b-48ab	2024-09-01T10:23:45Z	page_viewed	[e-mail]	Website
9c4d21f7-1f2a-4a19-9b23	2024-09-01T11:45:32Z	added_to_cart	[e-mail]	Mobile App
c7b43d2e-a1c5-4e6d-bd41	2024-09-01T12:15:20Z	purchased	[e-mail]	Website

How Auxia uses event data

Event data provides a rich source of information that can be transformed to help Auxia's models understand patterns in user behavior, predict outcomes, and power your personalization initiatives. Once events are ingested into Auxia, they are used to create aggregations which are relevant for:

Events generated on the client are ingested in the Auxia's system to create aggregations (e.g. number of logins per week, products viewed last month, etc) on top of them, which are then used for:

1. Qualification Criteria: Define rules to determine which users should receive a treatment and which should not.

2. Content Personalization: Tailor treatment content by dynamically inserting specific attributes into the messaging.

3. Enhanced Treatment Selection: Use user attributes to guide the model in selecting the most appropriate treatment for the user.

4. Machine Learning Features: Features are measurable characteristics of data that are used by the model to make predictions. Think of these as the input variables that help the model understand and learn patterns in the data.

How to structure your events for ingestion

The event data that's ingested into Auxia has the following structure:

[required] user_id: Unique identifier for every user

[required] event_name: Name of the event, such as, add_to_cart, image_upload, sign_up, order_completed, etc.

[required] event_timestamp: The timestamp at which the event happened.

[optional] event_properties: A list of key value pair which adds more context to the event, such as, cart_amount, category_of_purchase, etc.

[optional] user_properties: A list of key value pair which adds more context to the state of the user, such as, subscription_status, etc.

After the event data is shared with Auxia, it's transferred to a unified event schema, demonstrated below:

message LogEventsRequest {
  // For any given Auxia customer, this should always be the same.
  // Required.
  string project_id = 1;

  // Unique ID for the user that can be joined to events and attributes.
  // For example, Firebase or Amplitude events should have this ID in each event.
  // Required.
  string user_id = 2;

  // Events for the user.
  // Required.
  repeated Event events = 3;
}

// Attributes of a single event.
message Event {
  // A unique identifier for the event.
  // Required.
  string event_name =  1;

  // A unique identifier for the event. Auxia uses this identifier to de-duplicate the events for the same user.
  // Optional.
  string insert_id = 2;

  // A dictionary of key value pairs that represent data associated with the event.
  // Optional.
  map<string, PropertyValue> event_properties = 3;

  // A dictionary of key value pairs that represent data associated with the user.
  // Optional.
  map<string, PropertyValue> user_properties = 4;

  // The timestamp of the event.
  // Required.
  .google.protobuf.Timestamp client_event_timestamp = 5;

  // The timestamp at which the event was received by the server.
  // Optional.
  .google.protobuf.Timestamp server_received_timestamp = 6;

  // Unique identifier for the user when the user was signed out.
  // This identifier is used to identify a user across signed out and signed in sessions.
  // Required to support merging user across signed out and signed in sessions.
  // Optional.
  string pre_login_temp_user_id = 7;
  
  // Unique identifier for a single user session.
  // Optional.
  string session_id = 8;
  
  // Country of the user.
  // Optional.
  string country = 9;
  
  // Region of the user.
  // Optional.
  string region = 10;

  // City of the user.
  // Optional.
  string city = 11;

  // IP Address of the user.
  // Optional.
  string ip_address = 12;

  // Unique identifier for the user's device.
  // Optional.
  string device_id = 13;

  // Version of the app that the events correspond to.
  // Optional.
  string app_version_id = 14;
}

// Value corresponding to the property.
// Required.
message PropertyValue {
  oneof property_value {
    int64 long_value = 1;
    double double_value = 2;
    string string_value = 3;
    bool boolean_value = 4;
    .google.protobuf.Timestamp timestamp_value = 5;
  }
}