Embudos de aprendizaje en Roblox: encuentra dónde los jugadores dejan de avanzar

Empieza con una pregunta, no con un gráfico #

Imagina un taller donde un principiante recoge un paquete, camina hasta una estación y recibe una confirmación de entrega. El creador observa sesiones cortas y supone que el recorrido es demasiado largo. Sin embargo, el jugador podría salir antes de recoger el paquete, no entender el botón o completar la entrega sin notar la recompensa. La duración total no distingue esos casos.

Formula una pregunta concreta: ¿después de qué acción comprobable dejan de avanzar más participantes del tutorial? Esa pregunta define la secuencia antes de elegir la herramienta. No empieces intentando enviar toda la analítica posible. Cada evento debe responder a una cuestión sobre el comportamiento, en vez de demostrar únicamente que se ejecutó otra función. Una secuencia útil explica qué logró el jugador y dónde investigar después.

La web y el juego observan acciones distintas #

Pulsar Jugar en una web confirma una interacción con un enlace. No demuestra la entrada en un servidor, un pedido completado ni la recepción de un objeto. Mide la ruta dentro del juego por separado. No combines visitantes de la web y participantes del servidor en un mismo embudo sin una forma justificada de relacionar esas observaciones.

Este artículo trata la analítica de Roblox, no un nuevo objetivo de Yandex Metrica. El contador de la web permanece sin cambios. Leer una guía durante mucho tiempo no justifica un evento de tutorial completado dentro del juego. Confirma cada acción donde realmente ocurrió. Mantener estos límites claros facilita la interpretación y evita que una interacción en la web se convierta en un logro ficticio.

Define las cuatro etapas del taller #

Nuestra propuesta es: el jugador accede al escenario de aprendizaje; el servidor asigna el primer pedido; el servidor confirma la entrega; el servidor aplica la primera recompensa. Son etiquetas propias del diseño, no etapas obligatorias de Roblox. Anota para cada una el número, un nombre estable y una condición precisa de finalización.

Mostrar una pista no equivale a aceptar un pedido. Si investigas la disponibilidad de la pista, mide su aparición por separado, pero no la utilices para sustituir la aceptación. Del mismo modo, hacer aparecer un cofre no equivale a recibir su recompensa. La tabla debe explicar qué estado del servidor acredita cada etapa. Así otro desarrollador puede revisar la instrumentación sin adivinar qué significa terminado.

Abrir imagen a tamaño completo ↗

Envía eventos desde el contexto adecuado #

Roblox documenta LogOnboardingFunnelStepEvent para el aprendizaje inicial y LogFunnelStepEvent para otros embudos. Los eventos se envían desde el servidor en un juego publicado; Studio no los envía al servicio. Probar un controlador con un emisor simulado no acredita que los datos aparezcan en Creator Hub.

Separa la validación del juego del envío de analítica. El servidor sabe si asignó un pedido y aceptó una entrega, y puede registrar la etapa después. Una petición del cliente para registrar la etapa cuatro no sustituye esas condiciones. El ejemplo educativo siguiente recibe una etapa validada desde la lógica del servidor, no un número arbitrario enviado por el dispositivo. Los manejadores del juego deben confirmar la acción. El ejemplo no se ha conectado a un juego activo.

El código es un ModuleScript OnboardingObserver en ServerScriptService. Un Script del servidor crea observer = OnboardingObserver.new(function(player, step, name) AnalyticsService:LogOnboardingFunnelStepEvent(player, step, name) end). Llama a observer:RecordVerified(player, step) tras confirmar realmente la acción, y a observer:Forget(player) al salir. El módulo no conecta RemoteEvent ni valida la entrega por la lógica del juego. Comprueba el orden 1–4 y suprime repeticiones en el estado actual. true solo indica que la llamada local terminó sin error; no confirma la llegada al panel. Tras un fallo, una etapa posterior devuelve OutOfOrder hasta enviar correctamente la anterior: revisa el diagnóstico sin bloquear recompensas del juego. No guarda estado entre servidores. Las pruebas locales de Luau utilizaron un emisor simulado; no se enviaron eventos reales.

Al inicio del Script del servidor, declara local AnalyticsService = game:GetService("AnalyticsService") y local OnboardingObserver = require(game:GetService("ServerScriptService"):WaitForChild("OnboardingObserver")). Después de crear observer, conecta game:GetService("Players").PlayerRemoving:Connect(function(player) observer:Forget(player) end). Integra RecordVerified en los manejadores existentes de acciones confirmadas y conserva sus validaciones del juego.

-- ModuleScript: OnboardingObserver, in ServerScriptService.
-- Call only from server logic after a verified gameplay action.
-- This module observes progress; it never grants rewards.
local Observer = {}
local names = {"EnteredWorkshop", "OrderAssigned", "DeliveryAccepted", "RewardApplied"}

function Observer.new(send)
    assert(type(send) == "function", "Sender required")
    local lastStep = {}
    local adapter = {}

    function adapter:RecordVerified(player, step)
        if player == nil then return false, "InvalidPlayer" end
        if type(step) ~= "number" or step ~= math.floor(step)
            or step < 1 or step > #names then
            return false, "InvalidStep"
        end
        local previous = lastStep[player] or 0
        if step <= previous then return false, "AlreadyObserved" end
        if step ~= previous + 1 then return false, "OutOfOrder" end
        local ok = pcall(send, player, step, names[step])
        if not ok then return false, "SendFailed" end
        lastStep[player] = step
        -- Local call completed. This is NOT a dashboard delivery receipt.
        return true, "CallCompleted"
    end

    function adapter:Forget(player)
        lastStep[player] = nil
    end

    return adapter
end

return Observer

No omitas el inicio para mejorar el gráfico #

Según la documentación, el embudo comienza con su primera etapa registrada. Si el primer evento es recibir la recompensa, solo observas a quienes ya llegaron hasta allí. No puedes concluir que todos los que entraron completaron el tutorial: los demás quedaron fuera de la secuencia medida.

Elige el inicio según la pregunta. Para estudiar toda la llegada, puede corresponder a entrar en el servidor; para un tutorial concreto, a acceder a ese escenario. Escribe la definición junto a las etapas. No la cambies silenciosamente entre versiones. De lo contrario dos gráficos parecidos describirán poblaciones diferentes y sus diferencias no podrán interpretarse como el efecto de una única mejora.

Las repeticiones y los saltos cambian la interpretación #

Roblox considera la primera aparición de una etapa repetida, aunque los envíos adicionales siguen consumiendo el límite de eventos. Las etapas anteriores omitidas pueden considerarse completadas cuando llega una posterior. Por tanto, un gráfico lleno no demuestra automáticamente que el servidor haya enviado todos los registros esperados.

Lleva un registro educativo con acción, número esperado y número enviado. Comprueba especialmente las rutas donde un progreso antiguo guardado aplica una recompensa automáticamente. Ese jugador quizá no realizó el nuevo tutorial. Si es otra situación, no la mezcles con el primer aprendizaje ni envíes logros para rellenar un informe. Las definiciones y el registro deben describir la ruta real.

Verifica la medición antes de estudiar los abandonos #

Prepara recorridos controlados. Una persona entra y se detiene antes de aceptar el pedido. Otra lo acepta pero no termina la entrega. Una tercera completa todo el escenario. Describe de antemano los eventos que deben producirse y aquellos que no deben aparecer en cada recorrido.

No generes cientos de entradas idénticas para conseguir un gráfico atractivo. Una pequeña prueba controlada verifica la conexión, pero no caracteriza a la audiencia habitual. Marca estas observaciones en tus notas y tenlas en cuenta cuando haya pocos datos. Los recorridos aquí descritos son un plan, no una afirmación de visitas ya realizadas. Registra los resultados reales por separado cuando esté disponible el entorno publicado adecuado.

Interpreta una caída ficticia con cautela #

Supongamos un ejemplo inventado con 100 entradas, 60 pedidos aceptados, 45 entregas y 40 recompensas recibidas. No son estadísticas de nuestra web ni de nuestros juegos. Cuarenta participantes no avanzaron entre la primera y la segunda etapa, pero esos cuatro números no establecen la causa.

Podrían no encontrar la estación, distraerse, sufrir un error o decidir que el juego no les interesa. Reproduce después esa transición y comprueba la claridad de la tarea y los posibles fallos. No culpes al botón basándote únicamente en el embudo. La medición identifica un lugar para investigar; explicar el motivo exige observaciones adicionales. Mantén la hipótesis separada de lo que demuestran las acciones contadas.

Compara móvil y ordenador cuidadosamente #

Antes de comparar dispositivos, verifica que ofrecen el mismo tutorial. En un teléfono, un panel podría tapar el botón. En un ordenador, alguien podría cerrar una pista accidentalmente. Son hipótesis distintas que se pueden probar, no conclusiones establecidas sobre los hábitos del público.

Los filtros del embudo de Roblox corresponden a su primera etapa. Cambiar de dispositivo durante el recorrido no traslada todo el resultado a otro grupo. Tenlo en cuenta al interpretar los datos. No supongas que la acción final ocurrió necesariamente en el dispositivo mostrado por el filtro. Durante una prueba manual de interfaz, registra el dispositivo real por separado: responde a una cuestión diferente de la atribución de la cohorte.

Cambia una cosa concreta #

Elige un cambio comprobable: acercar la explicación del paquete a la estación, mostrar la dirección después de aceptar el pedido o hacer más visible la confirmación de entrega. Son propuestas para el taller ficticio, no funciones añadidas a los juegos existentes del autor.

Evita cambiar simultáneamente recorrido, recompensas, precios e interfaz si quieres comprender un ajuste. Conserva fecha de publicación, versión del escenario y definiciones de etapas. Compara después periodos apropiados y la composición de la audiencia. Con pocos jugadores los resultados pueden ser inestables. Ningún porcentaje universal garantiza un tutorial exitoso en todos los juegos. Describe la muestra real y la incertidumbre restante.

Abrir imagen a tamaño completo ↗

Reconoce un problema de medición #

Si casi todos tienen un evento de recompensa pero pocas entregas aparecen, revisa primero el orden y las etapas omitidas. Si se mezclan nombres diferentes tras actualizar, selecciona un periodo apropiado para la versión deseada. Si no hay datos, comprueba publicación, contexto del servidor y cumplimiento real de la condición.

No arregles un informe enviando logros inventados. El juego debe seguir sus reglas incluso cuando falla la analítica: una recompensa no se entrega por registrar un evento correctamente. Separa la operación del juego de su observación. El fallo de un canal no debe producir una finalización ficticia en el otro. Un diagnóstico útil explica la diferencia, en vez de esconder ambos estados detrás de una bandera genérica de éxito.

Prepara una entrega útil para otro desarrollador #

Entrega la tabla de etapas, condiciones, puntos de llamada en el servidor, fecha de lanzamiento, plan de pruebas y observaciones reales. Enumera lo desconocido: comprobaciones pendientes, filtros sin verificar, muestra pequeña o ausencia de datos. Otro chat podrá continuar sin tratar las suposiciones como hallazgos.

Esta etapa está lista cuando cada evento describe una acción clara y se ha verificado el envío en el entorno adecuado. Eso no demuestra que el tutorial haya mejorado ni que haya aumentado la retención. El artículo explica el diseño de la medición y el ciclo de investigación. Preparar este borrador no modificó analítica de juegos activos ni objetivos de la web. Cualquier implementación posterior requiere sus propias pruebas y evidencias.