Track
Primeros pasosReferenciaPrincipiante

Los 23 eventos estándar: una taxonomía que encaja limpiamente con todas las plataformas publicitarias

El catálogo canónico de eventos de Track — eventos de engagement, autenticación, lead, comercio y suscripción — con las propiedades que lleva cada uno, las finalidades de consentimiento que necesita por defecto y cómo se traduce a Meta, Google, TikTok, LinkedIn y el resto.

Por
Equipo editorial de Track
Publicado
Última revisión
Tiempo de lectura
4 min de lectura

Puntos clave

  • 23 eventos estándar en cinco categorías — engagement, auth, lead, commerce y subscription — siguen el vocabulario de eventos recomendados de GA4 y llevan una envoltura tipada y un bloque de commerce.
  • Las categorías fijan las finalidades de consentimiento por defecto: los eventos de commerce, lead y subscription necesitan la finalidad de marketing para llegar a los destinos publicitarios.
  • Los eventos personalizados deben cumplir el patrón de nombres y estar declarados en el plan de tracking; los no declarados se cuentan y se notifican, pero no se entregan a los destinos publicitarios.
  • Cada conector incluye un mapeo predeterminado editable a los nombres de evento de la plataforma, y cuatro reglas mantienen honesto el plan: un evento por acción, valores del sistema de origen, reembolsos como eventos, nombres en snake_case.
CategoríaEventosFinalidades por defecto
engagementpage_view, view_content, search, downloadanalytics
authsign_up, loginanalytics
leadgenerate_lead, contact, book_appointmentanalytics, marketing
commerceview_item_list, select_item, view_item, add_to_wishlist, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refundanalytics, marketing
subscriptionsubscribe, start_trialanalytics, marketing

Los nombres siguen el vocabulario de eventos recomendados de GA4 cuando existe uno, porque es la estructura de data layer más implementada y el SDK puede observar directamente los push al dataLayer al estilo de GA4. Las categorías deciden las finalidades de consentimiento por defecto: los eventos de commerce, lead y subscription son señales de conversión que las plataformas publicitarias quieren, así que requieren la finalidad de marketing para llegar a un destino publicitario; los eventos de engagement y auth son de analítica por defecto.

Propiedades

Cada evento lleva la envoltura: ID de evento, marca de tiempo, URL (con los IDs de clic eliminados), referrer, título, registro de consentimiento, fuente y — cuando el consentimiento lo permite — ID anónimo, ID de sesión, ID de usuario e identificadores con hash.

Los eventos de commerce añaden un bloque commerce tipado: currency, value, transaction_id, coupon, shipping, tax e items[] con item_id, item_name, price, quantity, item_category, item_brand, item_variant. refund lleva el transaction_id original y un valor negativo o parcial.

Los eventos de lead y subscription usan un conjunto reducido de propiedades: lead_type, form_id, plan, interval, trial_days y value cuando existe un valor documentado.

Todo lo demás va en props, que se valida contra el esquema del sitio: las claves desconocidas se notifican como hallazgos, el texto libre se analiza en busca de datos personales y los objetos anidados se enmascaran en lugar de reenviarse.

Eventos personalizados

Los nombres personalizados están permitidos cuando cumplen ^[a-z][a-z0-9_]{2,39}$, no colisionan con un nombre estándar y están declarados en el plan de tracking. Los eventos personalizados no declarados se aceptan, se cuentan y se notifican como hallazgos de esquema para que el plan pueda actualizarse de forma deliberada; no se entregan a los destinos publicitarios hasta que se mapean.

Traducción a las plataformas

Como el vocabulario es fijo, cada conector incluye un mapeo predeterminado:

CanónicoMetaGoogle AdsGA4TikTokLinkedInPinterestSnapchat
view_itemViewContentview_itemViewContentpage_visitVIEW_CONTENT
add_to_cartAddToCartadd_to_cartAddToCartadd_to_cartADD_CART
begin_checkoutInitiateCheckoutbegin_checkoutInitiateCheckoutSTART_CHECKOUT
purchasePurchaseacción de conversiónpurchaseCompletePaymentregla de conversióncheckoutPURCHASE
generate_leadLeadacción de conversióngenerate_leadSubmitFormregla de conversiónleadSIGN_UP
sign_upCompleteRegistrationacción de conversiónsign_upCompleteRegistrationregla de conversiónsignupSIGN_UP
subscribeSubscribeacción de conversiónSubscriberegla de conversiónSUBSCRIBE
start_trialStartTrialacción de conversiónStartTrialregla de conversiónSTART_TRIAL

Un guion significa que la plataforma no tiene un equivalente estándar; puedes mapearlo a un evento personalizado de la plataforma o dejar la fila desactivada. Cada valor predeterminado es editable por destino, y cada cambio queda versionado y aparece en el diff de publicación.

Reglas que mantienen honesto el plan

  • Un evento por acción del usuario. purchase se dispara una vez por pedido, desde la fuente que tenga autoridad para ese sitio (navegador, webhook de la tienda o servidor), con el mismo ID de evento o ID de pedido en todas las vías.
  • Los valores vienen del sistema de origen. No hay valor predeterminado; un valor sin mapear es null, y una plataforma que exige uno rechaza la fila de forma visible.
  • Los reembolsos son eventos, no ediciones. Un refund hace referencia a la transacción original; el purchase original nunca se reescribe.
  • Los nombres van en minúsculas con guiones bajos (snake_case). La forma de escribirlos en cada plataforma (CompletePayment, PURCHASE) es cosa del conector.

Fuentes primarias

Documentación y estándares en los que se basa este artículo.

  1. Google Analytics — Recommended eventssupport.google.com
  2. Meta — Standard eventsdevelopers.facebook.com

¿Te ha resultado útil este artículo?

Editor responsable

Equipo editorial de Track

Producto e ingeniería

Las personas que construyen Track: ingenieros y analistas que trabajan a diario en tracking server-side, herramientas de consentimiento e integraciones de conectores.