Convención objeto-acción para eventos
La convención más escalable para nombres de eventos es Objeto + Acción en formato snake_case o camelCase. Por ejemplo: product_viewed, cart_item_added, checkout_completed. El objeto es la entidad sobre la que actúa el usuario (producto, carrito, perfil), la acción es el verbo en pasado (viewed, clicked, submitted).
¿Por qué pasado? Porque el evento ya ocurrió cuando lo trackeás. 'Checkout completed' es mejor que 'Complete checkout', que suena a CTA. La consistencia en tiempo verbal elimina confusión: si mezclás 'signup_started' con 'complete_purchase', tu equipo no sabe qué convención seguir.
Evitá nombres genéricos como 'button_clicked' o 'page_loaded'. Especificá: 'cta_signup_clicked', 'pricing_page_loaded'. Cada evento debe responder '¿qué objeto?' y '¿qué acción?'. Si necesitás contexto adicional, usá propiedades: el evento es 'product_viewed', la propiedad 'product_category' te dice si es ropa o electrónica.
Estructura de un tracking plan
Un tracking plan documenta cada evento: nombre, descripción, cuándo dispara, qué propiedades incluye, tipos de datos. Sin esto, tu analytics se vuelve caos: eventos duplicados ('user_signup' vs 'signup_completed'), propiedades inconsistentes ('user_id' como string en un evento, número en otro), o eventos que nadie recuerda qué significan 6 meses después.
Para cada evento definí: trigger (cuándo se dispara exactamente), propiedades requeridas (user_id, timestamp), propiedades opcionales (utm_source, device_type), valores esperados (si 'plan_type' existe, debe ser 'free'|'pro'|'enterprise'). Esto es tu contrato entre producto, dev y data.
Herramientas como Avo, Segment Protocols o un simple Google Sheet sirven. Lo importante es que esté versionado y actualizado. Cada vez que agregues un evento nuevo, actualizá el tracking plan ANTES de implementar. Si implementás primero y documentás después, nunca documentás.
Propiedades vs eventos separados
Decidir entre crear eventos separados o usar propiedades es crítico. Regla general: si la acción es fundamentalmente distinta, evento separado; si es la misma acción con contexto diferente, propiedad. Ejemplo: 'video_played' con propiedad 'video_type: tutorial|webinar' es mejor que 'tutorial_played' + 'webinar_played'.
Eventos separados son útiles cuando necesitás trackear el funnel exacto. En ecommerce: 'product_viewed' → 'cart_item_added' → 'checkout_started' → 'payment_info_entered' → 'order_completed'. Cada uno es un paso distinto en el funnel, no una variación del anterior. Usá propiedades para segmentar análisis dentro del mismo paso.
El costo de demasiados eventos: tu lista se vuelve inmanejable. El costo de muy pocos: tenés que hacer queries complejas filtrando por 50 combinaciones de propiedades. El balance: ~50-200 eventos core para un producto mediano. Si llegás a 500, probablemente estés creando eventos que deberían ser propiedades.
Errores comunes en naming de eventos
Error #1: nombres desde la perspectiva del sistema, no del usuario. 'api_call_successful' no dice nada sobre qué hizo el usuario; 'search_results_loaded' es mejor. Pensá en el comportamiento observable, no en la implementación técnica. El evento es 'form_submitted', no 'post_request_sent'.
Error #2: inconsistencia en formato. Si usás snake_case, usalo siempre. No mezcles 'user_signup', 'product-viewed' y 'checkoutStarted' en el mismo proyecto. Elegí una convención (snake_case es el estándar en analytics) y forzá su uso con linters o validaciones en CI.
Error #3: eventos demasiado granulares. No necesitás 'filter_price_min_changed' y 'filter_price_max_changed'. Usá 'filters_applied' con propiedades 'filter_type: price_min' y 'value: 50'. Consolidá eventos que siempre vas a analizar juntos.
Error #4: no versionar cambios. Si cambiás el schema de un evento (agregás propiedad obligatoria, cambiás tipo de dato), eso rompe análisis históricos. O versioná el evento ('checkout_completed_v2'), o usá propiedades opcionales que sean backward-compatible.