El Guarén: descuentos bancarios en restoranes

El problema

Los bancos y las casas comerciales publican descuentos en restoranes, pero cada uno lo hace en su propia página, con su propio formato y sus propias reglas: unos aplican solo ciertos días, otros tienen tope de devolución, otros valen únicamente con una tarjeta específica. Para saber dónde conviene comer hoy hay que abrir dieciséis sitios distintos y leer la letra chica de cada uno.

El problema de fondo no es juntar los datos, es que caducan sin avisar. Un banco saca un convenio de su página y no queda registro: el descuento sigue circulando en listados y capturas de pantalla, y uno se entera en la mesa, cuando no se lo respetan.

Construí la aplicación para resolver las dos cosas: consolidar la oferta en un solo lugar y, sobre todo, publicar únicamente lo que se puede verificar contra la fuente.

Lo que hay publicado

Los descuentos se reparten muy desigual entre emisores, y eso cambia qué tarjeta conviene tener.

Ocho de los dieciséis emisores. Los otros ocho suman 117 descuentos entre todos.

El flujo, de la página del banco a la aplicación

Cada pieza hace una sola cosa y se puede correr por separado. Una vez al mes, después de la extracción, todo lo demás se arma y se publica con un comando.

1. 01
   ExtracciónUn extractor por emisor. Unos leen la API pública del sitio del banco, otros necesitan navegador porque la página responde con un desafío antibot, y uno viene de un PDF mensual de beneficios.
2. 02
   Verificación contra la fuenteEn los emisores que lo permiten, cada convenio se comprueba en la página de su banco y lo que da 404 se cae. Lo que se capturó con navegador vale solo el mes en que se capturó, y un archivo de otro mes no se publica.
3. 03
   ConsolidaciónUn mismo restorán llega con nombres distintos desde varios emisores. Se unifica, se deduplica y se aplican las correcciones hechas a mano, cada una con su motivo escrito.
4. 04
   EnriquecimientoGeocodificación de cada local (1.148 de 1.285 con dirección exacta), foto desde el propio sitio del restorán, carta, horario y tipo de cocina.
5. 05
   Publicación con frenosEl despliegue se detiene solo si un emisor perdió más del 40% de sus descuentos, si un JSON quedó vacío o inválido, o si algo con forma de credencial se coló en la carpeta publicada.
6. 06
   Uso y vueltaYa publicado, la aplicación recoge opiniones de quienes fueron y cuenta qué se mira, para saber qué datos vale la pena mejorar el mes siguiente.

La regla que ordena todo el proyecto

El primer día que estuvo publicada, la aplicación mostraba un 40% los jueves en un restorán, con vigencia hasta fin de mes según el aviso original. El banco ya lo había sacado de su página. Fui, pedí el descuento y no me lo respetaron.

De ahí salió la única regla que no se negocia: se publica solo lo que la página del banco muestra hoy. No basta con que la fecha de vigencia no haya pasado. Cada descuento guarda el día en que se vio en la fuente, y la ficha lo muestra junto al porcentaje.

Es una decisión incómoda, porque borra convenios que probablemente siguen vivos y deja la aplicación con menos contenido del que podría tener. Pero el valor de este dato está en que se pueda usar frente a un garzón, y para eso un falso positivo cuesta mucho más que un vacío.

Del catálogo a una decisión

Un listado de 787 descuentos no responde la pregunta que de verdad importa: ¿qué tarjeta me conviene tener? Esa pregunta mezcla tres cosas que la persona sí sabe (cuántas veces sale a comer al mes, cuánto gasta por vez, cuánto gana) con dos que están en los datos (en cuántos lugares sirve cada tarjeta y de cuánto es el descuento) y una que hay que ir a buscar aparte (el costo de mantención y la renta mínima que pide cada tarjeta).

El resultado es una estimación de ahorro mensual por emisor, contra su costo, y un veredicto en una línea: qué tarjeta conviene, cuánto ahorra al mes, en cuántos lugares sirve y cuánto cuesta. La página dice de forma explícita que es una estimación y no asesoría financiera, y descarta tarjetas que no le van a dar a quien responde.

Lo que aporta quien fue

Hay un dato que ninguna página de banco publica: si el descuento efectivamente se respetó. Eso solo lo sabe quien fue, así que la ficha de cada restorán permite dejar una nota, etiquetas y un comentario corto, sin cuenta ni registro.

Abrir un formulario público a internet obliga a resolver el abuso antes que la funcionalidad. Las opiniones viven en una base SQL en el borde, y cada una pasa por varios filtros: la petición tiene que venir de la propia página, el texto se valida y se rechaza si trae links, correos o teléfonos, y hay límites por conexión y por restorán al día. Los límites se guardan como huella derivada de la IP, nunca la IP completa, y vencen solos.

El promedio aparece recién desde tres opiniones, para que una sola no defina la nota de un local.

Pensada para el teléfono

Esto se usa de pie, en la calle, decidiendo dónde entrar. Por eso se diseñó primero para el celular, y después de publicarla la revisé en doce tamaños de pantalla, con una revisión de accesibilidad aparte.

La ubicación del GPS se usa para ordenar por cercanía y no sale del teléfono. No hay cuentas ni cookies.

Qué me llevo

• La frescura es parte de la calidad del dato. Un dato correcto que ya no está vigente es un dato equivocado. Guardar la fecha de verificación al lado de cada registro, y mostrarla, cambió el proyecto entero.
• Las validaciones tienen que estar en el proceso, no en la cabeza. Si un extractor se rompe, lo normal es que devuelva menos filas sin dar error. Por eso la publicación se detiene sola cuando un emisor pierde el 40% de sus descuentos de un mes a otro.
• Deduplicar entidades sin clave común es el trabajo lento. Dieciséis fuentes escriben el mismo restorán de dieciséis maneras, y las correcciones a mano, con el motivo escrito, terminaron siendo tan importantes como el código.
• Los identificadores publicados no se tocan. De ellos cuelgan los enlaces compartidos y las opiniones: mejorar los datos no puede romper lo que ya está afuera.