Rediseñar la experiencia de referidos en SimplyCodes

Contexto

SimplyCodes ya tenía un programa de referidos con códigos únicos, validación, atribución mediante la autenticación, seguimiento de actividad y recompensas. La experiencia web todavía no explicaba con claridad cómo funcionaba.

Como principal responsable del mantenimiento frontend, estuve a cargo del rediseño desde la idea inicial hasta la implementación. Definí las experiencias de quien invita y de quien recibe la invitación, expliqué la mecánica de recompensas en pasos concretos y coordiné con el equipo de backend para respetar los contratos de atribución existentes.

No necesitábamos reemplazar la infraestructura de referidos. Necesitábamos hacerla comprensible y útil para ambas partes.

Dos audiencias, dos preguntas

Un flujo de referidos sirve a dos personas con motivaciones diferentes.

Quien invita necesita entender por qué vale la pena compartir, dónde encontrar su enlace, cómo enviarlo y si sus amigos completaron los pasos. La persona invitada llega con menos contexto. Necesita saber quién la invitó, por qué confiar en la oferta y qué hacer después.

Una sola página genérica de adquisición no podía responder bien a las dos situaciones. Separé la experiencia en dos partes conectadas:

• una página para quien invita, donde puede descubrir el programa, desbloquear un código de referido, compartirlo y ver su progreso;
• una landing page para la persona invitada que convierte un enlace compartido en un camino claro de registro, instalación y compra.

[Imagen: las páginas de quien invita y de la persona invitada, una al lado de la otra, en desktop y mobile]

La experiencia de quien invita

La página de quien invita se adapta al estado de autenticación. Quienes no iniciaron sesión primero ven la explicación del programa y un llamado a la acción que los devuelve a la página de referidos después de iniciar sesión. Quienes ya iniciaron sesión ven su enlace único, los controles para compartir y el progreso de los referidos completados.

Las opciones para compartir también se adaptan al dispositivo. En mobile, los SMS y el menú nativo para compartir son las acciones más directas. En desktop, la interfaz permite copiar el enlace, compartirlo en X y redactar una invitación por email. La interacción de email incluye estados de validación, pendiente, éxito y error, en lugar de tratar la entrega como una acción invisible.

Revisé el mensaje para cada canal y agregué parámetros de origen a los enlaces de SMS y X. Esto mantuvo el mismo destino del referido y, a la vez, hizo visible en la URL el origen del tráfico compartido. También conservé la navegación de búsqueda habitual del sitio para que la experiencia de referidos se sintiera parte de SimplyCodes y no una página de campaña aislada.

La presentación del progreso muestra cinco posiciones visuales, pero la interfaz por sí sola no es la autoridad respecto de la elegibilidad de los referidos ni de los límites de las recompensas. Esas reglas pertenecen al servicio de recompensas y a su configuración de actividades.

La experiencia de la persona invitada

La página de la persona invitada tenía que explicar qué hacer después de recibir la recomendación. La organicé con una propuesta breve y pasos específicos para cada dispositivo.

En mobile, los pasos hacen énfasis en crear una cuenta, descargar la app y hacer una compra. En desktop, hacen énfasis en crear una cuenta, instalar la extensión del navegador, comprar con la extensión y activar las recompensas antes de la compra. Los llamados a la acción aparecen al principio y al final de la página, con una acción adicional en mobile junto al primer paso instructivo.

La página solo se renderiza para una persona visitante sin sesión y con un código de referido válido. Los enlaces inválidos y quienes ya iniciaron sesión vuelven a la experiencia estándar de descubrimiento. Para las invitaciones válidas, trasladé el código a la URL de inicio de sesión mientras el middleware de referidos existente conservaba el contexto de atribución en una cookie. Ese traspaso conectó la página rediseñada con la autenticación sin pedirle a la persona usuaria que entendiera el mecanismo subyacente.

También revisé los metadatos de la página y la presentación al compartir en redes sociales para que la invitación mantuviera su coherencia antes de que la persona destinataria llegara al sitio.

Límites del sistema

La experiencia completa atravesaba varios servicios a cargo de distintos equipos. Mi trabajo incluía el concepto de producto, las vistas web responsivas, las interacciones para compartir, el traspaso a autenticación con contexto de referidos, los metadatos y la integración frontend. Los servicios de backend existentes seguían a cargo de la identidad, la persistencia, la calificación, la moderación y las recompensas.

Mi alcance frontend

Página de quien invita
  -> obtener un código de referido existente
  -> compartir /invite/:code
  -> validar la ruta de la persona invitada
  -> conservar el contexto del referido
  -> derivar a la persona invitada al inicio de sesión

Pipeline existente entre servicios

Autenticación
  -> crear o resolver la persona usuaria de SimplyCodes
  -> pasar el contexto de referrer, referee y code a Karma

Karma
  -> guardar la relación de referido
  -> observar la instalación, el registro y la compra que reúne los requisitos
  -> aplicar las reglas de elegibilidad y actividad
  -> crear actividades de recompensa pendientes de moderación

Esta división de responsabilidades guio el diseño. El frontend podía explicar los pasos y mostrar información sobre las recompensas, pero no debía duplicar las reglas de calificación o pago. Con el equipo de backend verificamos que la experiencia respetara los contratos que tomaban esas decisiones.

Decisiones de implementación

El rediseño reutilizó el pipeline de referidos establecido en lugar de introducir otro mecanismo de atribución. El middleware de la ruta validaba el código de invitación antes de renderizar la landing page y conservaba su contexto de referido. El traspaso al inicio de sesión incluía explícitamente el mismo código, lo que mantenía comprensible la transición y permitía que la autenticación continuara el recorrido.

Las analíticas existentes distinguían las vistas de la página de quien invita con y sin sesión iniciada, los métodos para compartir, los envíos de email y las vistas de la landing page de la persona invitada. Mis cambios en las opciones para compartir agregaron información del canal a determinados enlaces, pero la evidencia disponible no abarca la creación de la cuenta, la instalación, la compra que reúne los requisitos ni la entrega de la recompensa. Por ese motivo, no presento los eventos de la página como un funnel de adquisición completo.

La comunicación de las recompensas puso de manifiesto otra restricción importante. Los incentivos pueden cambiar independientemente de un release del frontend. El sistema más amplio proporcionaba configuración de actividades y la interfaz actual lee algunos valores desde allí, pero durante el rediseño los textos de campaña no se generaban uniformemente a partir de la configuración. La lección duradera fue tratar el lenguaje de los incentivos como datos de producto siempre que fuera posible y revisar cualquier texto promocional restante cuando cambiaran las reglas.

Iteración después del rediseño

Después de la primera implementación hubo varias correcciones puntuales. Ajusté la navegación de la persona invitada a partir del feedback, restauré el comportamiento estándar de búsqueda en la página de quien invita y revisé los textos para compartir y la presentación en redes sociales a medida que evolucionaba el mensaje del producto.

No cambiaron la atribución. Corregí un encabezado para que se comportara como en el resto del producto, adapté los mensajes a cada canal y ajusté la vista previa compartida para que mostrara el destino correcto.

Resultado

El resultado fue una experiencia web conectada para ambas partes sobre el sistema de referidos existente. Quienes invitaban recibieron opciones para compartir según el dispositivo y una vista más clara del progreso. Las personas invitadas recibieron pasos concretos desde la recomendación hasta la creación de la cuenta y la instalación del producto. El rediseño también fijó los límites entre el frontend, la autenticación, SimplyCodes API y los servicios de Karma.

La evidencia analítica y de despliegue disponible para este caso de estudio no demuestra un aumento de la conversión, adquisición incremental ni tasas de finalización de recompensas. Esos resultados siguen abiertos hasta que se puedan recuperar y validar los dashboards correspondientes del funnel.

Reflexión

Un producto de referidos no se reduce a generar enlaces. Tiene que conectar a dos personas y varios sistemas sin perder la atribución. La interfaz debe explicar los incentivos sin convertir un texto promocional en la regla del negocio, incluso cuando la autenticación o la calificación ocurren en otro servicio.

Estar a cargo del rediseño implicó resolver la experiencia completa sin exceder la responsabilidad del frontend. No hacía falta un nuevo backend de referidos. Hacía falta un contrato más claro entre la intención de la persona, el estado de la interfaz y los servicios que procesaban el referido.