Modelado de identidad multiinquilino para análisis de eventos

Las preguntas operativas y de productos suelen utilizar varias identidades a la vez: una persona, cuenta, espacio de trabajo, sesión, solicitud, dispositivo o visitante anónimo. Tratar esos valores como intercambiables crea embudos inflados, cohortes de retención rotas y exposición de datos insegura.

Defina el grano y la propiedad de cada identificador antes de usarlo en SQL.

Niveles de identidad separados

Utilice campos distintos para entidades distintas:

No ingrese una dirección de correo electrónico en user_id. Prefiere identificadores seudónimos internos y mantiene la búsqueda de identidad en el sistema que ya posee datos personales.

Definir los límites de los inquilinos

Cada evento de múltiples inquilinos debe incluir el identificador de inquilino necesario para la autorización y el análisis. Elija un campo canónico a nivel de cuenta y utilícelo de forma coherente en todos los servicios. Si un evento pertenece a un espacio de trabajo, incluya tanto account_id como workspace_id en lugar de sobrecargar un campo.

Decida cómo representar el tráfico interno, probar los inquilinos, los inquilinos eliminados y las fusiones de cuentas. Un panel que combine silenciosamente a los clientes de producción con los empleados y las pruebas automatizadas producirá tarifas engañosas.

Vincule cuidadosamente la actividad anónima y autenticada

Un visitante anónimo puede convertirse posteriormente en un usuario autenticado. Registre el evento de enlace explícito solo después de que la aplicación establezca la relación:

{
  "event_name": "identity_linked",
  "anonymous_id": "anon_7b2",
  "user_id": "usr_42",
  "account_id": "acct_18",
  "link_reason": "registration_completed",
  "identity_policy_version": "v2"
}

No reescribas los acontecimientos históricos en silencio. Mantenga la hora del enlace y la versión de la política para que una consulta pueda distinguir lo que se sabía en el momento del evento de la resolución de identidad posterior. Revise los requisitos de consentimiento y privacidad antes de conectar identificadores entre contextos.

Elija el grano analítico correcto

Cuente cuentas para activación y expansión de cuentas. Cuente los usuarios para adopción individual. Cuente sesiones distintas para la participación en la sesión. Cuente los ID del flujo de trabajo del terminal para los resultados del trabajo o del webhook.

Indique el grano en la definición métrica:

• “cuentas activas semanales” significa valores distintos de account_id con un evento principal elegible;
• “usuarios activados” significa valores distintos de user_id que alcanzan el hito de activación;
• La “tasa de error de solicitud” utiliza eventos de solicitud elegibles, no usuarios distintos.

Las guías embudo y retención de cohortes explican cómo la elección de identidad cambia los denominadores.

Manejar los cambios del ciclo de vida

Las fusiones de cuentas, la eliminación de usuarios, la transferencia de espacios de trabajo y los cambios de membresía requieren una política explícita. Conserve identificadores de tiempo de evento inmutables cuando la auditabilidad sea importante y únase a una dimensión actual solo cuando la pregunta solicite la propiedad actual.

Para las solicitudes de eliminación, documente qué identificadores seudónimos siguen siendo necesarios, cuáles pueden transformarse irreversiblemente y qué eventos deben eliminarse. Siga retención y eliminación de datos y eliminación de datos sensibles confidenciales.

Validar con casos extremos

Pruebe un usuario en múltiples espacios de trabajo, múltiples usuarios en una cuenta, una transición de anónimo a autenticado, una fusión de cuentas, un inquilino empleado y un usuario eliminado. Confirme que las consultas de activación, retención e ingresos cuenten la entidad deseada exactamente una vez.