Skip to content
Sangsoo Lee
← Volver a todos los proyectos

Caso de ingeniería

Matching bilateral — elegir candidatos con interés mutuo

Industria
Consumo · Matching
Año
2026
Rol
Decisiones de producto + implementación
Cliente
Producto de matching por suscripción anonimizado
Matching bilateral

Hacer visible la regla de selección.

Flujo del producto
  1. 01

    Perfiles

    Representar ambos lados.

  2. 02

    Candidatos

    Comparar posibles parejas.

  3. 03

    Evaluación

    Validar la regla con backtests.

  4. 04

    Revisión

    Inspeccionar la recomendación.

Flujo de producto ilustrado · no es una captura de producción

Consumo · Matching

  1. 01Reconstruir la evidencia previa al evento
  2. 02Comparar reglas de selección compuestas
  3. 03Definir la conversión con cohortes consistentes

Next.js · Supabase · PostgreSQL · Puntuación · Flujos de notificaciones

Flujo reconstruido · sin datos de clientes en producción

El problema operativo

Una tasa de aceptación alta de un lado no garantiza interés recíproco. Una regla de selección que reservaba plazas solo por la disposición a aceptar podía elegir candidatos con poca demanda del otro lado.

Antes

  • 01Clasificar la disposición de un solo lado
  • 02Reservar plazas solo por aceptación
  • 03Interpretar los recuentos por etapa sin cobertura

Después

  • 01Reconstruir la evidencia previa al evento
  • 02Comparar reglas de selección compuestas
  • 03Definir la conversión con cohortes consistentes

Lo que construí

  • 01Evalué retrospectivamente la selección con la información disponible antes de cada evento histórico y comprobé la sensibilidad al retraso de las respuestas.
  • 02Sustituí cuatro plazas basadas solo en aceptación y cuatro plazas compuestas por una única selección según la puntuación compuesta.
  • 03Diseñé los embudos de crecimiento y operación con unidades de análisis distintas, intersecciones secuenciales de etapas y límites de observabilidad visibles.

Antes / Durante / Después

  1. 01

    Antes — hipótesis inicial

    El supuesto inicial era que los candidatos que aceptaban con mayor frecuencia producirían más matches exitosos.

  2. 02

    Durante — restricciones y pivotes

    La reconstrucción histórica mostró que la disposición debía combinarse con la demanda recíproca. Comparé varias reglas para seleccionar los ocho mejores candidatos, incluido su efecto en el total de éxitos y la capacidad.

  3. 03

    Después — resultado

    Se implementó la regla revisada. La mejora documentada del 17–39% provino de simulaciones con distintos tamaños del grupo de candidatos; el informe original no estableció una mejora en producción después del cambio.

Con 2 semanas más, haría…
Seguiría cohortes posteriores al cambio con resultados consolidados, el tamaño del grupo y el número absoluto de resultados exitosos junto con la tasa.

Evidencia y alcance

+17–39%
Resultados exitosos · simulación de selección
Análisis retrospectivo
Tipo de evidencia
Revisada
Política de selección
No establecida
Mejora en producción

El medio caótico — supuestos, revisiones, tradeoffs

  • Supuesto fallidoSolo disposición a aceptar

    El segmento con mayor aceptación no produjo el mejor resultado recíproco.

  • TradeoffTasa frente al total de éxitos

    Un umbral estricto puede mejorar la tasa y, a la vez, dejar plazas vacías y reducir el total de éxitos en grupos pequeños.

Tecnologías y técnicas aplicadas

Herramientas: Next.js · Supabase · PostgreSQL · Puntuación · Flujos de notificaciones

  1. Matching recíproco y puntuación compuesta

    Sustituí los cupos reservados solo por aceptación por una selección con puntuación compuesta que considera disposición y demanda recíproca.

  2. Backtesting histórico y sensibilidad al retraso

    Reconstruí la información disponible antes de cada evento y comprobé el efecto de las respuestas tardías al comparar reglas de selección.

  3. Medición de embudos por cohortes consistentes

    Separé los embudos de crecimiento y operación según su unidad de análisis, con intersecciones secuenciales entre etapas y límites de observabilidad explícitos.

Nombre del cliente, capturas y URLs en vivo retenidos por acuerdo.