¿Cuáles son los componentes de los datos de eventos?

Esta es la cuarta parte de la serie de cinco partes sobre Datos del cliente. Aquí están las partes uno, dos y tres.

Los datos del cliente comprenden los datos de eventos y los datos de la entidad; ya lo sabe si ha pasado por la primera parte (¿Qué son los datos del cliente?).

En esta guía, aprenderá sobre los componentes de los datos de eventos, la convención de nomenclatura preferida para definir eventos, las categorías de datos de entidades y los dos tipos principales de entidades.

Datos de eventos

Como probablemente haya comprado cosas en línea, comencemos con un ejemplo de comercio electrónico.

Cuando interactúa con una aplicación de comercio electrónico (web o móvil), normalmente compra un producto agregándolo a su carrito, procediendo a pagar y completando el pago; estos son eventos que realiza cuando pasa por el proceso de compra de un artículo en la aplicación.

El viaje del comprador, sin embargo, no es tan sencillo y hay varios otros eventos que pueden tener lugar, como:

• Se ve un producto
• El carrito es visto
• Un producto es eliminado del carrito
• Se aplica un cupón
• Se elige una dirección
• Se elige un método de pago.
• Se completa un pedido

Y así.

Los eventos comunes como Agregar al carrito, Proceder al pago y Realizar el pago vienen a la mente de inmediato, pero para comprender el comportamiento del usuario, también es necesario realizar un seguimiento de otros eventos como los mencionados anteriormente.

Decidir qué eventos rastrear y nombrar los eventos usando una convención de nomenclatura adecuada son los dos primeros pasos en el proceso de recopilación de datos de eventos.

¿Cuáles son los siguientes dos pasos?

¡Me alegra que hayas preguntado!

Cada evento va acompañado de propiedades de evento (o atributos de evento) que brindan más contexto sobre un evento. Decidir qué propiedades asociar con un evento y nombrar esas propiedades son los siguientes dos pasos en el proceso de recopilación de datos de eventos.

¿Lo que hay en un nombre?

Cuando se trata de datos, todo.

Una convención de nomenclatura o taxonomía adecuada es lo que hace que los buenos datos se destaquen de los malos y permite que las partes interesadas entiendan lo que están viendo. No mantener una taxonomía estandarizada, por otro lado, es una de las principales causas de que los conjuntos de datos estén sesgados o hinchados con redundancia.

Además, cuando se trabaja con datos de clientes, uno de los mayores errores que se pueden cometer es no mantener mayúsculas y minúsculas uniformes al nombrar eventos y propiedades de eventos, uno que puede tener ramificaciones a largo plazo. Una buena convención de nomenclatura siempre debe ir acompañada de pautas estrictas de mayúsculas y minúsculas.

Este es el por qué:

Add to Cart, added_to_cart, productAdded, add to cart, added to cart, Product added son diferentes formas de definir el mismo evento.

Si bien ninguno de estos es incorrecto per se, y no hay reglas establecidas cuando se trata de nombrar eventos y propiedades, existen mejores prácticas que uno debe considerar seguir.

La convención de nomenclatura de objetos y acciones se ha convertido prácticamente en el estándar de la industria y por una buena razón: describe claramente la acción que ya ha tenido lugar. Producto Agregado definitivamente significa que un objeto (producto) es seguido por una acción (agregado).

Obtén más información sobre cómo configurar una taxonomía coherente para tus eventos .

Componentes de datos de eventos

Hay dos componentes clave de un evento: una entidad (una o más) y las propiedades del evento.

La asociación de datos de entidad como user_id con un evento proporciona información sobre el usuario que realizó el evento.

En ausencia de un identificador único como user_id , los datos del evento permanecerán anónimos y no habrá forma de saber quién realizó dicho evento. De manera similar, en el contexto de SaaS B2B, donde un usuario puede ser potencialmente parte de varias organizaciones, el id_organización debe estar asociado con eventos para saber dónde se llevan a cabo.

Además de las entidades, existen otras piezas de información que se pueden recopilar con fines de análisis y segmentación cuando ocurren eventos.

Volviendo al ejemplo del comercio electrónico, cuando se compra un producto, además de saber quién realizó la compra, como mínimo, también necesita saber qué producto se compró , a qué precio y cuándo .

Esa información adicional se recopila en forma de propiedades de eventos .

En la primera parte de esta serie, se mencionó que los datos de eventos comprenden tres elementos clave:

• La acción o el evento que tuvo lugar.
• La marca de tiempo o la fecha y hora precisas en que tuvo lugar el evento.
• El estado o todas las demás propiedades asociadas con el evento (conocidas como propiedades del evento)

Veamos el evento Producto agregado (el nombre en mayúsculas y minúsculas según el marco de acción de objeto para el evento Agregar al carrito ) y supongamos que lo realizó un usuario el 1 de enero de 2020 a las 10 a. m. UTC. Los datos recopilados cuando tuvo lugar el evento incluyen lo siguiente:

• La acción: Producto Agregado
• La marca de tiempo: 1577872800 (marca de tiempo de Unix para el ABZ 7.99 ( El estado: 0123 ABZ 7.99 ( Según este ejemplo, las propiedades asociadas con el evento Product added son user_id, product_id, price y cantidad , cada una de las cuales brinda más información sobre el evento. La marca de tiempo se asocia con el evento para saber cuándo tuvo lugar.

  También es útil especificar un nombre para la marca de tiempo que es esencialmente una propiedad de evento. No es obligatorio hacerlo, ya que la práctica estándar es asociar la marca de tiempo como marca de tiempo con cada evento al enviar datos a herramientas de terceros; sin embargo, especificar un nombre distinto para la propiedad que almacena la marca de tiempo puede ser útil a largo plazo cuando necesite trabajar con datos de eventos históricos.

  La taxonomía recomendada para las marcas de tiempo es el nombre del evento seguido de "en": product_added_at para el evento Producto agregado.

  Es posible que ya haya notado que se usa snake_case para definir las propiedades de los eventos, lo que facilita distinguir los nombres de los eventos de las propiedades de los eventos. Dicho esto, tenga en cuenta que aquí no hay reglas predefinidas y debe elegir lo que funcione mejor para usted y su equipo.

  Este es un vistazo final a las propiedades asociadas con el evento Producto agregado y los tipos de datos de cada una de esas propiedades:

  

  Especificar el tipo de datos para cada propiedad garantiza la coherencia de los datos y facilita el proceso de instrumentación.

  

  Nota al margen: es bueno tener en cuenta que Ahora debería quedar claro que la recopilación de datos de eventos consta de los siguientes pasos:

  • Decidir qué eventos rastrear
  • Nombrar esos eventos usando una convención de nomenclatura adecuada
  • Decidir qué propiedades asociar con cada evento
  • Nombrar esas propiedades usando una convención de nomenclatura adecuada

  La siguiente (y última) parte de esta serie cubre el proceso de decidir qué eventos rastrear y qué datos recopilar.

  Sin embargo, debe tener una buena idea de qué esperar al observar los datos de eventos (ya sea en un plan de seguimiento antes de la instrumentación o dentro de un destino de datos, como su herramienta de análisis de productos).

  Algunos eventos comunes y sus propiedades.

  Antes de continuar, eche un vistazo a algunos eventos y propiedades comunes que rastrean la mayoría de los productos tecnológicos.

  

  Tipos de entidad

  Es hora de echar un vistazo en profundidad a las diferentes entidades y sus propiedades. Si aún no lo ha hecho, consulte esta guía para comprender cómo se relacionan los datos de entidad con los datos de eventos.

  En la primera parte de esta serie, se mencionó que los datos compartidos por los usuarios se incluyen en los datos de la entidad. Si bien eso es cierto, no todos los datos de la entidad son compartidos por los propios usuarios; también se pueden generar datos de la entidad.

  Los datos de la entidad comprenden propiedades asociadas con la entidad: si el usuario es la entidad, toda la información sobre un usuario se recopila en forma de propiedades de usuario.

  User_id se genera para cada usuario de forma predeterminada para identificar a los usuarios (y actúa como identificador de eventos).

  Dicho esto, por el momento olvídate de los eventos y piensa en los diferentes datos que se relacionan exclusivamente con los usuarios y te hablan de sus características.

  Tipos de datos de entidad

  Los datos de la entidad se pueden clasificar en los siguientes grupos (también mencionados en la parte 3 de esta serie):

  • Información de identificación personal , como Datos demográficos como la Persona como Preferencias como Datos específicos del producto, como Los datos de cada depósito se encuentran en las propiedades del usuario. En otras palabras, las propiedades de los usuarios almacenan varios detalles y características de los usuarios, lo que le permite identificarlos y saber más sobre ellos.

    Si bien la mayor parte de la información proviene directamente del usuario, ciertas propiedades del usuario se generan automáticamente con el tiempo como resultado del uso del producto.

    ¿Pero no se generan también datos de eventos debido al uso del producto?

    Seguro que lo es: las propiedades del usuario son detalles adicionales relacionados con un evento que se recopilan cuando se lleva a cabo. Echemos un vistazo al evento Signed Up y sus propiedades:

    

    Como puede ver, todas las propiedades asociadas con este evento brindan detalles sobre los usuarios: detalles que comparten los propios usuarios ( nombre, apellido, correo electrónico, teléfono, país ) o detalles que se generan automáticamente ( registrado_en, ID_usuario ).

    Es útil tener en cuenta lo siguiente:

    • Algunos eventos como Signed Up o La mayoría de las propiedades de los usuarios, excepto las marcas de tiempo y los identificadores, están sujetas a cambios. Un usuario puede cambiar su nombre, correo electrónico, teléfono, ubicación, industria, puesto de trabajo, etc. Pero el usuario no puede cambiar la hora de registro (signed_up_at) o el identificador único (user_id).

    Propiedades de usuario frente a propiedades de organización

    Con las aplicaciones de consumo, el tiempo dedicado, los productos comprados, las canciones reproducidas o los videos vistos son propiedades asociadas con el usuario almacenadas como propiedades de usuario, cuyos valores se actualizan constantemente con un aumento en el uso.

    En el contexto de B2B SaaS, el usuario y la organización son las entidades principales, y los eventos recopilados están vinculados a un usuario o una organización (o ambos).

    Podría haber otras entidades grupales, como equipos o proyectos, con ciertos datos vinculados a ellos, como es el caso con la mayoría de las herramientas de productividad; el proceso de recopilación de datos de la organización también es aplicable en tales casos.

    Echemos un vistazo a algunas propiedades de usuario comunes relevantes para los productos B2B SaaS:

    

    Cuando un usuario es parte de una organización , mucha información importante está vinculada a la organización y no al usuario.

    Algunas propiedades comunes de la organización (también denominadas propiedades de grupo ) son las siguientes:

    

    Es importante tener en cuenta que el organization_id también actúa como un identificador y debe asociarse con eventos para saber bajo qué organización se llevó a cabo un determinado evento.

    Tener en cuenta las siguientes afirmaciones puede ayudar a diferenciar entre propiedades de usuario y propiedades de organización:

    • Toda la información que ayuda a definir las cohortes de usuarios (de dónde vienen, quiénes son, cuál es su objetivo o qué hacen dentro de un producto) se almacena como una propiedad del usuario .
    • Toda información que ayude a segmentar cuentas u organizaciones ( el tipo de cuenta, los ingresos que genera, los productos o características que utiliza, los recursos que consume o la cantidad de usuarios que forman parte de ella) se almacena como una propiedad de la organización ( o propiedad de grupo).

    Una vez que pueda diferenciar entre los anteriores, será fácil incorporar nuevas entidades (como equipos o proyectos) a la mezcla.

    Próximos pasos

    Ahora debería tener una comprensión clara de cómo definir eventos y sus propiedades asociadas, así como especificar las propiedades de cada entidad (usuario y organización).

    Para comenzar a definir eventos y organizar sus datos hoy, comience con una cuenta gratuita de Amplitude.