Data Definition and Segment Implementation

Mar Sierra Guillén
5 min readSep 14, 2020

--

What is a Data Definition?

Segment.io

Segment.io

A data definition involves a process in which a Measurement Plan is constructed to clarify the KPIs (Key Performance Indicators) or performance indicators that will inform us whether our product is meeting business objectives while also fulfilling user needs. Once these measurement requirements are identified, a technical implementation process is carried out to collect behavioral data in the digital environment.

It is essential to distinguish between two types of KPIs. The first category pertains to the usage and exploitation of our product, which indicates how the product and its features are being utilized, including aspects such as usability, accessibility, and comprehensibility. This category provides a quantitative overview of the actions taking place within the environment. The second category relates to macro-conversions, which are connected to business outcomes; that is, they involve achieving funnels or actions that directly or indirectly yield benefits for the business.

I refer to these as “service KPIs” and “transactional KPIs.” When working with teams, it is crucial to clarify that we need to pursue and visualize both types. Some will inform design decisions, while others will guide business or strategic decisions.

Construimos el Plan de medición

Constructing the Measurement Plan

We began by mapping all potential user flows within the product. Our focus was on Certicalia, a platform connecting professional certifiers with users in need of certificates.

For this, we utilized Sketch for design, and we documented all the flows in Miro as a collaborative tool to engage with different team members.

In total, we identified 10 flows that needed measurement.

Example of One Flow (Onboarding)

Ejemplo de uno de los flujos (Onboarding)

Afterward, we differentiated service actions from transactional actions within each flow.

Diferenciación de tipología de acción en los flujos de Registro y Comparador.

Differentiating Action Types in the Registration and Comparison Flows

Once we had clarified the primary actions that could occur in each flow, we began mapping our measurement plan.

This plan must reflect the product’s main objectives at different stages of a funnel’s maturity. At each stage, the product will have different goals, and those goals must correlate with associated KPIs, most of which are expressed as rates, allowing us to view the data as a percentage: Users completing X action / Total Users.

In the following example, you can see the measurement plan for the main flows associated with a user type who is a professional certifier using the platform for online certificates. The KPIs are grouped by funnel stage and corresponding flow. (Some KPIs may require detailed explanations, but I will not delve into that here. Keep this as an example.)

What is Segment, and Why Did We Choose It?

👉 Segment is a Customer Data Infrastructure (CDI) platform that collects, stores, and routes user data to hundreds of tools and digital properties.

It eliminates the need to continuously modify or adapt the code for new tools we want to test, thus saving on development costs and enabling more precise data activation.

Segment offers several types of calls or specs. Depending on the type of event, we will use one or another:

  • Identify: Who is the customer?
  • Track: What are they doing?
  • Page: Which webpage are they on?
  • Screen: Which screen of the application are they viewing?
  • Group: What account or organization do they belong to?
  • Alias: What was their previous identity?

We have used three types of calls: Identify, Track, and Page. These events draw from “properties” for the .track spec or “traits” for the .identify spec.

Properties are similar to traits, but they are associated with specific actions rather than individual users. Each .track() call can accept an optional dictionary of properties, which can contain any key-value pairs desired. These properties serve as dimensions that allow your end tool to group, filter, and analyze the events.

The Tagging Guide

How Do We Organize It in Certicalia? We identified the type of variable and the event to which it is sent. We ended up with a total of 57 variables. Here are a few examples:

Afterward, we mapped all the variables within each of the defined events.

Example of Properties in a Completed Order Event:

Example of Events in a Registration Flow:

Each event is associated with a trigger reference in the tagging guide, which helps developers understand where the event is triggered within the product flow. We generated references for each event to clarify its context within the flow. Furthermore, this guide is designed for developers to leave comments and track the implementation status of each event.

Flujo con “trigger ref” de diferentes eventos

Flow with Trigger Reference for Different Events

Tagging Guidelines

The tagging guide should be accompanied by a set of tagging rules, which outline the standards and best practices for creating label syntax to capture analytics events.

It aims to serve as a reference for determining the taxonomy of events and the variables to define for measuring actions or values to track within digital environments.

This document reflects the needs identified during the reformulation of the entire taxonomy, which we sought to adapt to the new data collection tool.

We recommend using the following basic naming conventions for events and variables. This will help maintain consistency in naming and avoid errors in data processing:

  • Use lowercase letters.
  • Avoid accents or characters that could lead to erroneous data processing or unrecognized symbols by the data tool.
  • Eliminate spaces; instead, use underscores (“_”).
  • Use English as the official language, which will facilitate better communication with support teams for the tools, as English is the official language.

Example of Variable Taxonomy

Ejemplo de taxonomía de variables

Co-Creation as a Work Culture

In conclusion, the choice of tool for implementation is secondary; in this case, we chose Segment for the advantages and versatility it offers in connecting/disconnecting sources and activating actions.

The data strategy is a step above; that is, first, consider what you need to measure and the product strategy you want to pursue, and only then adapt the tool. Preliminary work with different teams is essential, and all must contribute to the construction of that plan. Therefore, I encourage you to be co-creative!

--

--

Mar Sierra Guillén
Mar Sierra Guillén

Written by Mar Sierra Guillén

Product & Service Designer / Analyst head and designer at heart

No responses yet