Promoción / ROBLOX
Embudo de tienda en Roblox: separar visitas repetidas y resultados de compra
Planifica la analítica de una tienda que se abre varias veces durante una sesión. Distingue intentos mediante funnelSessionId, define pasos observables y evita convertir una vista de producto en una compra sin confirmar.
Elige una pregunta sobre un recorrido recurrente #
Imagina una tienda de objetos de práctica: el jugador abre la ventana, mira una ficha, la cierra y vuelve después. Un único registro de visita no explica ambos intentos. El primero puede terminar en la vista y el segundo llegar a una solicitud de compra. Empieza preguntando en qué paso dejan de avanzar las visitas individuales.
Utilizamos el embudo ficticio PracticeShop para diseñar la medición de una próxima experiencia, no para informar sobre nuestras estadísticas. No se enviaron eventos de AnalyticsService, se hicieron compras ni se cambió código de juegos. No hay cifras de conversión medidas. Primero acuerda qué significa un intento y cada paso; después implementa su observación.
Define los límites de un intento #
Describe qué apertura confirmada inicia un nuevo intento. Decide después qué ocurre al cerrar, cambiar de sección y regresar. Cambiar entre fichas puede formar parte de la misma visita; es una decisión del proyecto. No crees otro intento por cada fotograma de interfaz o cambio del producto seleccionado.
En el ejemplo, cerrar termina el intento A y volver a abrir inicia B. Esta frontera permite comprobar el diseño con acciones normales. Regístrala junto con la versión del embudo. Si cambia más adelante, los eventos antiguos y nuevos necesitan una explicación para no aparentar un único recorrido sin modificaciones.
Abrir imagen a tamaño completo ↗Distingue la identidad del jugador y del intento #
En un embudo recurrente, funnelSessionId conecta los pasos del mismo intento y lo distingue del siguiente intento del jugador. Una sesión de juego puede contener varias visitas a la tienda. Por tanto, mismo jugador y mismo intento son relaciones diferentes que el registro debe conservar.
Las letras A y B del esquema son etiquetas de práctica, no identificadores reales. Un escenario nuevo necesita un ID nuevo, y sus pasos posteriores utilizan ese mismo ID. Hay dos errores opuestos: un ID constante mezcla visitas, mientras que uno nuevo en cada paso rompe la secuencia. Revisa ambos antes de confiar en un gráfico.
Abrir imagen a tamaño completo ↗Crea un diccionario de pasos observables #
Asigna número, nombre breve y condición exacta de finalización. Por ejemplo, ShopOpened indica la apertura acordada, ItemViewed la ficha seleccionada mostrada y CheckoutRequested el inicio del proceso de compra previsto. Son nombres ilustrativos. Dos desarrolladores deben entender igual cuándo puede registrarse cada evento.
El último paso GrantConfirmed significa entrega confirmada solo si existe un sistema de compra y entrega verificado por separado. No se completa al pulsar un botón, abrir un diálogo de pago o cerrarlo. Si la entrega aún no está preparada, limita el embudo de práctica a las vistas. Una medición limitada y honesta sirve más que un recorrido aparentemente completo con un final inventado.
| Paso ilustrativo | Qué confirma |
|---|---|
| ShopOpened | Apertura acordada |
| ItemViewed | Ficha seleccionada mostrada |
| CheckoutRequested | Proceso de compra iniciado |
| GrantConfirmed | Solo entrega confirmada |
Identifica la fuente de cada evento en el servidor #
La documentación permite enviar estos eventos desde el servidor en juegos publicados, no desde Studio ni el cliente. Separa la observación de interfaz de la decisión del servidor sobre la validez del paso. Una vista comunicada debe corresponder a un intento existente y un paso permitido, no a un número arbitrario recibido del cliente.
Prepara un mapa de condición, lógica de confirmación, número de paso e ID. Este artículo no contiene una tienda lista ni un validador universal. El mapa hace explícita la implementación pendiente. Una operación del juego y su observación analítica también son diferentes: registrar un paso no debe entregar el objeto ni crear permiso para recibirlo.
Comprueba la repetición de un paso #
Una ficha puede mostrarse otra vez dentro del mismo intento. Según la documentación, el embudo considera la primera aparición de un paso repetido, pero los envíos adicionales siguen consumiendo el límite de frecuencia. Un gráfico sin duplicación no prueba que el controlador se ejecute una sola vez o evite trabajo innecesario.
Planifica casos separados para ver la misma ficha, elegir otra y volver a abrir la tienda. Son acciones distintas. Registra el ID y número usados en cada una y compáralos con la frontera elegida. No añadas envíos repetidos sin sentido para que el informe parezca activo; cada observación necesita un motivo claro.
Conserva el significado de los pasos omitidos #
Un paso posterior puede completar automáticamente los anteriores en el informe. Eso no demuestra que tus controladores observaran todas las acciones previas. Si aparecen entregas, pero pocas aperturas registradas, inspecciona orden y condiciones de envío antes de interpretar el resultado como conducta del jugador.
Incluye un caso propuesto donde falta un paso temprano y separa el comportamiento esperado del informe del registro de llamadas reales. No es una razón para enviar logros ficticios. El objetivo es detectar un recorrido defectuoso o una observación incompleta. Mantén separadas las acciones conocidas y lo que la herramienta deduce de un evento posterior.
Recorre dos visitas mediante el registro #
En el primer escenario propuesto, el jugador abre, mira un objeto y cierra sin comprar. En el segundo vuelve a abrir e inicia el proceso de compra previsto. El registro debe distinguir A y B y el orden dentro de cada intento. Una solicitud de compra continúa siendo diferente del pago o la entrega.
Guarda etiqueta de práctica, inicio, pasos utilizados y motivo de finalización. Registra la entrega solo después de tu propia confirmación. La tabla contiene planes y expectativas, no resultados de partidas realizadas. El autor verifica los envíos en un entorno publicado adecuado; para esta guía no se enviaron eventos reales.
Interpreta según versión y periodo #
Compara el informe con el diccionario y la versión del escenario. Después de cambiar el significado de apertura o renombrar un paso, elige un periodo correspondiente y marca la actualización. Un periodo mezclado puede ocultar un cambio de significado aunque se mantengan los mismos números.
La documentación limita el seguimiento a los diez valores únicos más recientes de funnelSessionId por jugador y embudo. No lo uses como archivo ilimitado de intentos ni reutilices un ID antiguo para continuar una visita cerrada hace mucho. Una conclusión necesita datos reales y una muestra clara. Aquí no se proporcionan, así que no se afirma un aumento de compras.
Entrega una especificación clara #
Comparte pregunta, límites del intento, diccionario, condiciones del servidor, reglas de ID y registros de las dos visitas propuestas. Incluye las comprobaciones todavía pendientes. Otro chat podrá implementar la medición sin adivinar qué significa compra ni confundir sesión de juego y visita a tienda.
Un diseño de medición no garantiza ventas mejores ni sustituye el tratamiento de la entrega. Las metas del sitio observan otras acciones y no confirman compras internas. Este material ofrece esquemas originales y pruebas propuestas, sin pagos, conversiones reales ni cambios de nuestros juegos. Verifica la implementación antes de interpretar sus observaciones.
| Especificación | Registrar |
|---|---|
| Límite | Inicio y final del intento |
| Diccionario | Número, nombre y condición |
| Fuente | Lógica confirmatoria del servidor |
| Versión | Fecha y cambio de significado |
Fuentes originales
Roblox Creator Hub — Funnel eventsRoblox Creator Hub — AnalyticsService API
