Woopra Documentation

Schemas are the skeleton of the Woopra project. Schemas are declarations of metadata about an event or visitor property. They define how the data tracked is read and processed by Woopra. The Schema configuration for all action and visitor data tells Woopra what type of data it is, how the user wants it to be displayed, and how it can be aggregated.

The type and aggregation set for each property will be leveraged for smart filtering and richer analytics throughout Woopra. Basic Schemas are automatically created from any custom action and visitor properties being tracked, or Integrations Apps’ actions that are selected from the configuration. Once added, they should be configured as desired by the user who set up the tracking code.

To access the Schema editor, you must be an Administrator. Click on the “Configure” button in the navigation bar and find Action and Visitor Schemas under the Manage section of the sidebar.

There are two types of Schema:

  • Visitor Schema
  • Action Schema

Schemas can be found in the Configure section of the Woopra Dashboard.

Visitor Schema

Visitor Schema define the custom visitor properties that are being tracked. The name, email, and company name are added to the Visitor Data Schema by default, but Woopra will also add Schema for the other custom visitor data (https://docs.woopra.com/docs/custom-actions-and-visitor-data) that the script is calling. To learn more about how to identify your visitors and track custom visitor data, please read the Javascript tracking tutorial.

For each Schema, define the title, description, key, type, and aggregation:

Please note, Schemas are character sensitive. We accept upper/lower case letters, numbers, underscore, dashes, dashes as well as spaces.

Schema Property
Description

Title

The Visitor Property title as seen throughout Woopra. This helps users understand the property being tracked, even if they did not participate in the setup. e.g. User ID.

Description

The description is an important reference for the entire team to understand the meaning of the visitor property, especially those who did not participate in the tracking code setup. It’s always a good practice to add a description to fields to make it easy for other users to take action on this data.

Key

The key name as tracked on the website. This comes directly from the tracking code. e.g. company size.

Type

Type of property:

  • Text – For any string value.
  • Number – For numbers/decimals.
  • Timestamp – For dates. Note that these should be sent in milliseconds rather than seconds.

Aggregation

Specify whether the property is a unique value (A property wished to be tracked, but do not wish to visualize graphically e.g. account_id), amount (e.g. monetary value), or group (value that could be shared with other customers and that is wanted to be seen in a report e.g. trial, package, etc.).

Action Schema

The Action Schema is different from the Visitor Schema. It defines the actions from the installed Integrations Apps or the actions that were set up for tracking and any properties associated with those actions. Each company has their own key events that need to be tracked.

For an e-commerce website, they may want to track product views, cart updates, and purchases, while a SaaS business may want to track form submissions, signups, trial engagement, conversions, etc. To learn more about how to track custom actions, please read the [Javascript tracking tutorial] (https://dash.readme.io/project/woopra/refs/intro-javscript-sdk).

The Action Schema configuration will fine tune the look and feel of Woopra for the company. Woopra will use the Schema to build the content of the customer Profiles (For example, instead of “Visitor did action payment”, it would say “Jim purchased the Yearly Small Business package for $1,999.50“) and more.

Action Info

Each action consists of three parts to be configured:

Title

The action name as seen throughout Woopra. This helps users understand the action being tracked, even if they did not participate in the setup. Administrators can associate an icon with the action that is being tracked.

Description

The description is an important reference for the entire team to understand the meaning of this action, especially those who did not participate in the tracking code setup. It’s always a good practice to add a description to fields to make it easy for other agents to act on this data.

Key

The name of the action as it’s tracked e.g payment.

Action Properties

Each property will have the below fields:

Key

The name of the property as it’s tracked e.g. amount.

Type

Types of the properties:

  • Text – For any string value.
  • Number – For numbers/decimals.
  • Boolean – For two possible values. Accepted input is True or False. It is an alias for Short Boolean.
  • Short Boolean – For two possible values. Acceptable input is 0 for False, 1 for True.
  • Timestamp – For dates. Note that these should be sent in milliseconds rather than seconds.

Number and Timestamp types support formats. Text type does not.

Aggregation

Specify whether the property is a unique value, amount, or group.

Action Template

Template

Defines how the action will be displayed in the activity stream of the customer Profiles. Properties can be added to the template from the action ${action.propertyname}, or visitor properties like ${visitor.name}. Below is an example of a template for the signup event:
${visitor.name} signed up to Woopra from ${action.company} (${action.company size}).

Aggregations

Group

Used for properties that can be applied to multiple events or visitors, such as company, product, or credit card type.

Unique

Used for properties that are a unique identifier for a specific event, such as a receipt ID or a transaction ID. For visitors, a username or email address would be a unique identifier, while company would be a “group” as it can be applied to more than one visitor.

Amount

Used for properties that can be added up or summed. When you designate a property as “amount”, you will be able to sum it in your segmentation filters (https://docs.woopra.com/docs/segmentation-filters) and analytics reports.
For example, in the “payment” Action Schema, we can designate the “amount” property as an “amount”. Now when we are using segmentation filters, we may segment for “all customers who have made payments that totaled more than $200”. Similarly, our action report for the “payment” event will include a column which sums the total payment amounts by day, week, or month.

Schema Auto-Generation

When a new event without a schema comes into Woopra, the system will create a basic schema so that the event can be found in reports and searched for in the Woopra interface. Users can then edit this schema in the schemas section to give some items a more sensical value that the computer cannot auto-generate such as Display Name, and Template.

Auto-Generated Characters

For Schemas to be auto-generated, the allowed characters are -- upper/lower case letters, numbers, underscore, dashes, and spaces.

Event Schemas

When an event has a schema, it will automatically be used to generate analytics reports.

Event Template

The template is how the event is displayed when it occurs in a timeline or actions history. It allows the user to use event properties in a sentence about that event when it occurs. For instance, the email_open event may have a title, "Email Opened", and a template of "Opened email with subject: ${actions.subject}".

See Woopra Templates for more on how to create your own templates.

*Schema Limits*

The Woopra system puts limits on how many event and visitor properties can have schemas declared. Those limits are currently at 200 visitor property schemas, and 200 event schemas.

For the javascript formatting for your schema, you can reference here.

Schema