Validation warnings

Eventvisor SDKs emit warnings when unknown events or payloads with wrong shapes are tracked.

Challenges#

One of the challenges in medium to large organizations is that teams are often given freedom to define their own events and payloads in an isolated manner.

This can lead to a lot of inconsistencies and errors, especially when these events start being used in more places, and not just the team alone where it originated from.

And operational hurdles only grow more over time when the event's shape keeps changing by different parties and nobody then knows what the source of truth is. Neither for tracking nor for reporting.

Eventvisor schemas#

When using Eventvisor, teams are expected to join a workflow where the events, attributes and their schemas are defined and managed in a centralized way with full visibility and control.

For example, if we have a page_view event, we can define it as follows:

description: Page view event
tags:
  - web
properties:
  url:
    type: string
required:
  - url

Above, we defined a page_view event with a url property which is a required property.

Tracking with SDKs#

When tracking events with SDKs, we can do:

eventvisor.track("page_view", {
  someUnknownProperty: "value",
});

Getting warnings#

Above, we know that the event name page_view is correct, but the payload is in wrong shape.

This will result in emitting a warning in the console, that developers can act upon.

If we do it the correct way now:

eventvisor.track("page_view", {
  url: "https://www.example.com",
});

This will not result in emitting a warning in the console.

Benefits#

By having a central place to define events and their payloads, we can ensure that:

• Teams will know what events to track and in what shapes
• Even if they make any mistakes, they will get a warning in application runtime that they can act upon
• Leading to more reliable data and better reporting in a self-served fashion