Proyecto tipo: AddOn para Gmail

PROBLEMA

El cliente ha visto un post mío sobre la creación de un AddOn para Gmail para personalizarlo y quiere una propuesta de que se podría hacer para ayudar a su empresa similar al software X que ahora tienen.

PROPUESTA

Alguno de los puntos a tener en cuenta.

  • No se puede meter cualquier cosa dentro de un AddOn para Gmail
  • El AddOn para Gmail sólo existe en el contexto de un hilo de correo específico

Por esto, mi propuesta sería hacer algo lo que os ofrece X, pero sólo para las personas que estén en el hilo de correo.

Para las gráficas, habría que meterlas como imágenes, y que sean completamente anónimas, pues las imágenes tienen que ser públicas para poder incoporarlas a un add-on. Además, como en cada correo serían distintas, habría que generarlas al vuelo (para esto se podría usar Google Graph o hacer un servicio a medida).

Para darle más valor, intentaría introducir información que ahora no os proporcione X porque no tenga sentido de manera agrupada, pero que sí tenga sentido en correos individuales. No sé que feedback tenéis de los usuarios de X, pero por ejemplo se me ocurre que se podrían mostrar semáforos o algo así para saber si se está respondiendo pronto (antes de la media) o tarde, o la hora a la que se calcula que se recibirá respuesta.

Para poder tener algo de referall, yo permitiría incluir en el texto que se esté escribiendo información estadísitica, y así quienes recepcionen el mensaje verán la información dada por este AddOn para Gmail fomentando que tal vez se conviertan en usuarios.

Yo creo que funcionaría mejor tener todo en una única pantalla, pero eso se puede probar y hacer lo que se vea en las estadísticas de uso.

Esto es lo que creo que tiene sentido a la hora de hacer un AddOn para Gmail, y no replicar lo que ya está en X. Si queréis replicar eso, como hablamos, creo que sería mejor que optaseis por una app como la que ya tenéis.

Nota aclaratoria:

Este proyecto tipo, es un ejemplo de proyecto que se ha realizado o se podría realizar. En ningún caso tiene validez como presupuesto real y sólo pretende documentar las distintas posibilidades que existen.

Actualmente, con los cambios que ha habido en cuanto a las posibilidades que dan los add-on, la propuesta habría sido distinta.

Se han omitido nombres de empresas y productos.

Proyecto tipo: Recomendador para app de relatos

PROBLEMA

El cliente solicita la elaboración de dos apartados:

  1. Sistema recomendador basado en Machine Learning
  2. Sistema de detección de tendencias

En la entrevista con el cliente se llega a la conclusión de que lo que en el fondo quiere es aumentar el tiempo de uso de la app y la recurrencia de uso: la retención.

Además, necesita comenzar a almacenar datos para posteriormente explotarlos.

Actualmente el volumen de relatos es de aproximadamente 300 y se espera un crecimiento de aproximadamente uno al día.

PROPUESTA

Para el primer problema (el recomendador) empezaría por implementar algunas estrategias que no requieren servicios externos, para así comenzar a tener datos y ver cuales de ellas son las que mejor funcionan. Por ejemplo:

  • Al acabar una historia proponer de 1 a 3 recomendaciones: una random, otra random de la misma categoría, otra random de el mismo autor.
  • Si se incluyesen tags para afinar la categorización de las historias, incluiría una cuarta recomendación en el punto anterior.
  • Cuando se abandona una historia preguntaría si se quiere guardar el progreso (y así saber si hay interés en ella).
  • Gestionar el progreso que se lleva en cada historia.
  • A las 6h, 12h, 24h, 48h del último uso lanzaría una notificación con texto del último párrafo leído de la última historia si se dejó a medias, o el primero de una recomendación del tipo que mejor esté funcionando para ese usuario (por categoría, autor, random, o tags si se implementan).
  • Incluir fotos de los personajes y una vista de su perfil.

Todo esto se puede gestionar con facilidad desde la propia aplicación, y entendiendo que la empresa dispone de desarrolladores para esa parte, por el momento no se presupuestará.

Para la captación de datos para su explotación, los principales actores son 3:

  1. Google Analytics. El problema que tiene es que en el momento que se quieren exportar datos se necesita la versión premium que tiene un coste de $150.000 USD al año.
  2. Mixpanel. Una solución de análisis que dispone de APIs para integrarla con cualquier sistema y poder exportar los datos. Su precio es de $999 USD al año. Es una buena solución siempre que no se vuelva poco flexible, ya que a la larga te tienes que amoldar a sus posibilidades.
  3. Una solución a medida que permita guardar cuantos datos se desee en el formato que se prefiera, para que posteriormente se les puedan dar distintos tratamientos para obtener distintas informaciones ya sean en modo de servicio para proveer de nuevas funcionalidades a la aplicación, informes, datos tratados para su venta. Es una buena solución en cuanto a relación flexibilidad y coste.

Dado que las dos primeras opciones sólo requieren realizar modificaciones en la aplicación, se presupuestará sólo la tercera.

A partir de tener los datos almacenados mediante cualquiera de los sistemas, posteriormente se podrán tratar para cubrir cualesquiera necesidades surjan:

  • Obtener perfil de uso y progreso de un usuario.
  • Obtener recomendaciones a medida de un usuario.
  • Creación de informes.
  • Búsqueda de patrones de comportamiento.
  • Envío de notificaciones personalizadas.
  • Etc.

CONCEPTO

Elaboración de un servicio que reciba datos para identificación del dispositivo/usuario y una colección de eventos (1..N) para almacenar todas las acciones que haya realizado el usuario. El paso de datos se hará en formato JSON de tal modo que la definición de la estructura pueda ir variando con el tiempo sin necesidad de modificar el servicio.

El hecho de permitir mandar varios eventos, permitirá que no se pierda información cuando la aplicación se use offline. Además permitirá no estar realizando comunicaciones constantes si por ejemplo se decide registrar cada uno de los “scroll” que se hacen en las historias para seguir leyendo, pudiendo guardarse cada 10 scrolls por ejemplo.

A petición del cliente se usaría Azure.

Se propone para la computación usar Azure Functions, ya que permite que el sistema escale de manera automática y no pagar nada cuando no hay uso del servicio.

Para el almacenamiento se sugiere el uso de Azure Cosmos DB, una base de datos orientada a documentos, que permite almacenar cualquier tipo de estructura de datos, pudiendo cambiarse esta sobre la marcha, permitiendo así introducir nuevos datos que se haya visto con el uso que pueden ser útiles.

PRECIO*

El precio total es de 2.800€.

* Se omite el desglose en componentes por simplicidad.

TIEMPOS

El proyecto tiene una estimación de tiempo de entrega de 1 (un) mes, desde la fecha de inicio de los trabajos.

Nota aclaratoria:

Este proyecto tipo, es un ejemplo de proyecto que se ha realizado o se podría realizar. En ningún caso tiene validez como presupuesto real y sólo pretende documentar las distintas posibilidades que existen.

Por favor, si tuviese necesidad de algo similar, no dude en ponerse en contacto.