Cómo construir un eCommerce Singular. Capítulo 2, El Monolito

Publicado el abril 29, 2018 por carlosguardiola

Aunque es verdad que a veces hacer las cosas mal cuesta más que hacerlas bien, nadie se propone de manera consciente construir un sistema de software que sea ineficiente o inmantenible. Simplemente, pasa. Algo se desarrolla pensando en resolver un problema; pero el problema va cambiando, o creciendo; y entonces se van añadiendo nuevos módulos, nuevos componentes, o se añade funcionalidad sobre algo que ya existía, y la cosa se termina por complicar.

Frankenstein, o el Nuevo Monolito

Un sistema de software donde todos sus elementos están fuertemente acoplados y además está autocontenido y se ejecuta como un sistema único puede llegar no sólo a ser difícil de mantener y evolucionar, sino que también podría no ser capaz de mantener su rendimiento y eficiencia cuando aumenta su uso y por tanto las interacciones, lo que viene conociéndose como escalar.

El concepto de acoplamiento en términos de ingeniería del software hace referencia a la dependencia que tienen diferentes partes de un sistema, a la hora de realizar la función para la que fueron diseñadas. Aunque es normal que cuando se construye un sistema, haya partes que necesiten de otras para realizar ciertas tareas, la forma en que esta dependencia se construye podrá hacerse con mayor o menor acoplamiento. Por ejemplo: el caso de un formulario en una web que acaba insertando información en una base de datos. Puede hacerse con cierto desacoplamiento cuando los datos de los formularios viajan por diferentes capas / componentes que los piden, los recogen, los validan y los procesan cada uno como corresponda; o muy acoplada cuando un único componente coordina la operación, y le va pasando al resto no sólo los datos, sino instrucciones sobre qué hacer con ellos y cómo hacerlo.

UX Designer FullStack Developer DevOps as a Service

Tradicionalmente, se define un sistema Monolítico como aquél en el que todas las capacidades de representación, procesamiento y almacenamiento están entrelazadas, y son gestionadas como una única unidad de ejecución, prevista para correr en un único servidor. Es decir, una única aplicación contiene y es responsable de todas sus funcionalidades.

Hay muchos motivos por los que alguien acabaría teniendo un sistema Monolítico. Estadísticamente yo diría que de menor a mayor probabilidad, serían cuatro.

Primer motivo: porque alguien lo habría diseñado así intencionadamente.

En esta categoría podemos meter por ejemplo el llamado “Majestic Monolith” (no hace falta traducción) de Basecamp. En un artículo de 2016, David Heinemeier presenta el concepto Majestic Monolith para referirse a la forma en que Basecamp está construida. Los conceptos subyacentes a esta decisión de arquitectura son: eliminar abstracciones innecesarias, y hacer distribuidas únicamente las partes del sistema necesarias. Básicamente defiende que es la mejor alternativa en el escenario de un equipo reducido de desarrolladores (12), con experiencia y criterio, que conocen y entienden el código del sistema; código que se ha escrito con criterios de simplicidad, limpieza y orientación a la prueba. Teniendo en cuenta que este hombre creó Ruby on Rails, parece que es una decisión razonada que le permite mantener y evolucionar un sistema que en 2018 tiene más de 2,8 millones de cuentas registradas, accesible desde 6 plataformas.

Segundo motivo: porque estaba mal diseñado.

Asumamos como cierto que las personas que han estudiado una carrera de informática (técnica o superior; en la universidad o en la FP, o como se llamen ahora respectivamente, que yo no estoy muy al día) han recibido los conceptos y bases necesarios para diseñar arquitecturas de software. Asumamos también como cierto que otras personas que no han estudiado en las universidades o centros de formación profesional pueden adquirir conocimiento a partir de la experiencia, la lectura de documentación y el aprendizaje autodidacta o desde un referente. Asumir estos planteamientos significa partir de la base de que las empresas ponen a diseñar arquitecturas de software a personas que saben como hacerlo, que han leído, conocen patrones de referencia, y quieren hacer bien su trabajo.

Sin embargo, shit happens. Como decía al empezar este post, no creo que nadie diseñe de manera consciente sistemas para que sean ineficientes o no escalen; simplemente a veces se toman las decisiones erróneas. En 2013 tres investigadores de la universidad de Groningen (Holanda) D. Tofan, M. Galster y P. Avgeriou publicaron un paper en el que analizaban las causas por las que un Arquitecto de Software llegaba a tomar malas decisiones a la hora de plantear una solución técnica.

D. Tofan, M. Galster y P. Avgeriou, ECSA 2013

Como resultado del estudio, llegaron a varias conclusiones, aunque a lo mejor no todas sorprendentes e inesperadas:

El principal motivo que lleva a tomar decisiones erróneas a la hora de hacer una arquitectura de software es la dependencia con otras decisiones ajenas a la decisión técnica en sí; seguido por el impacto que una decisión a priori técnica tenía en el negocio. Es decir, al propósito por el que se está construyendo el software en la organización, en el caso de un eCommerce: ganar dinero vendiendo cosas por internet.
Por el contrario, que hubiera demasiadas alternativas o muchas personas en el proceso de toma de decisión no se consideraban motivos relevantes de un diseño mal planteado.
Existe una diferencia entre los motivos que detectan los arquitectos de software según su experiencia. Los que tenían menos de 5 años de experiencia consideraban problemático tener que enfrentarse a criterios y recomendaciones contradictorias a la hora de tomar una decisión, y que cuanto más había que pensar, más difícil les resultaba decidirse. Por el contrario, los arquitectos de software con más de 5 años de experiencia no daban importancia a estos conceptos, sino al tema del contexto y el negocio (lo cual hace inevitable resucitar la paradoja del Arquitecto de Software Junior)
El tiempo medio que se se consideraba necesario para tomar las decisiones de diseño de una arquitectura de software era de 8 jornadas de trabajo. Paradójicamente, el estudio también apunta a que los arquitectos de software con menos experiencia tardaban la cuarta parte en tomar decisiones de diseño (de ahí el refrán acerca de la ignorancia y el atrevimiento)

Tercer motivo: porque estaba bien diseñado, pero en algún momento las cosas se torcieron.

Se que al final se me hacen unos post muy largos, que a veces abro muchos temas y demás, pero es que hay que hablar de la deuda técnica. Más allá de que nos guste más o menos el término, o su sentido; en el contexto de este post voy a usarlo porque me parece la forma más universal de hacer referencia a la degradación que sufren los sistemas durante su desarrollo y evolución. Puede que se partiese de un sistema bien definido y planteado, pero con el paso del tiempo la aplicación acaba siendo ponzoña. ¿Por qué? De nuevo, es algo que nadie quiere que ocurra de manera intencionada, yo creo en la buena fe de las personas. Pero ocurre.

Por lo general, el código de un sistema se degrada poco a poco, como respuesta a situaciones del tipo “me ha quedado complicado, pero ya lo arreglaré más adelante”, “no tengo tiempo para hacer las pruebas”, “este fallo debe ser un Expediente X, porque suele funcionar”, etc.

En 2015, Neil Ernst del Software Engineering Institute de la Universidad Carnegie-Mellon publicó un estudio / paper sobre los motivos de por qué sucede esta degradación. Os comparto la gráfica que me parece más relevante. Es bastante auto-explicativa, la verdad.

Neil Ernst, SEI 2015

Cuarto y último motivo: porque no sabía que se lo estaba comprando.

Creo que es lo más normal, y suele pasar cuando alguien compra un producto mirando los Cuadrantes que publican los analistas de negocio, o porque nobody ever was fired for buying IBM, o porque las demos de jugar estaban bien, etc. En lugar de hacer una due diligence tecnológica como Dios manda.

¿Qué hace aquí este Monolito?

El esfuerzo e interés por desarrollar aplicaciones desacopladas no es algo nuevo, y forma parte del corpus teórico de la ingeniería del software desde sus inicios. En el caso que nos ocupa en este contexto, que es el eCommerce (algo inherentemente ligado a la Web y en los últimos años al móvil) las arquitecturas en tres capas (presentación, lógica de negocio y datos) y el Patrón Model-View-Controller han sido la forma habitual de construir sistemas con bajo acoplamiento.

No sólo desde el punto de vista de la construcción, ya que al separar de forma conceptual las distintas partes del sistema es más fácil actuar sobre ellas; sino desde el punto de vista de la infraestructura que las soporta, con el objetivo de mejorar el escalado y el rendimiento. Poder empaquetar y desplegar cada una de las capas en servidores diferentes permite al sistema escalar de manera independiente cada capa cuando se producen los picos de acceso al sistema (cuando hay ventas privadas, o campañas como Rebajas, San Valentín, Navidades o el Black Friday) Por eso es bastante habitual ver infraestructuras donde se ha separado la parte de presentación en unos servidores optimizados para servir el front, complementados con un CDN para los estáticos (las imágenes, vídeos, etc), la parte que hace la lógica de operaciones en servidores de aplicación, y otra capa con la base de datos en alta disponibilidad.

El equipo Scrum hace sus dailies frente al Monolito

Sin embargo, dejadme que os diga que la primera referencia a patrón MVC se remonta a finales de los 70. Y la idea de crear una arquitectura en 3 capas para construir aplicaciones cliente / servidor es de mediados de los 90. Así que, ¿a qué nos referimos hoy en día cuando se habla de un Monolito? Porque es lógico suponer que la mayoría de los eCommerce Singulares, que es de lo que va esa serie de posts, se han construido bien sobre plataforma, bien a medida, siguiendo arquitecturas y patrones que desacoplan al menos las capas de presentación-negocio-datos.

Bien. En primer lugar, aunque la tienda como tal esté desarrollada en 3 capas, puede que la capa de lógica de negocio (o back-end) se haya construido como un Monolito. Significaría que es un bloque único que recibe las peticiones de la parte del cliente (web o móvil o por qué no, un botón IoT), hace cierta lógica (como una búsqueda de productos según un criterio, o añadir un elemento al carrito) y genera la información que se renderizará en la capa de presentación a modo de respuesta. Entendido de esta manera, el servidor puede estar construido de manera modular, con sus elementos desacoplados en paquetes y clases, de forma que tenga su componente de carrito, otro de catálogo, etc. Pero lo cierto es que al final todas importarán las mismas librerías con las mismas dependencias, compartirán el mismo modelo de almacenamiento de datos en sesión, y la misma política de persistencia.

También el back-end de la aplicación puede considerarse un monolito si se empaqueta como un único artefacto. Podría llegar a desplegarse en varios servidores, lo que le permitiría escalar en caso de aumento de peticiones. Pero es una única unidad lógica; de forma que en caso de ser necesario hacer una modificación, hay que volver a compilar, empaquetar y desplegar toda la parte servidora, haya o no sido actualizada. Y una vez que se empaqueta, la misma versión es la que se despliega (y por tanto se ejecuta) en todos los nodos de la infraestructura. Al hacer el despliegue, aunque sea por nodos, es necesario reiniciarlos. En la medida en que haya un entorno distribuido con alta disponibilidad y persistencia compartida de sesiones, los usuarios podrían no verse afectados; sin embargo, tareas programadas o procesos de sistema (como sincronizaciones de inventario, confirmaciones de pago, o envío de newsletters) que estuvieran ejecutándose, se perderían. Por eso muchas veces hay que hacer las actualizaciones de manera programada, lo que es una barrera para llegar al despliegue continuo.

Y el artefacto que se despliega en cada nodo, se ejecuta en un mismo entorno, compartiendo la misma configuración y el espacio de memoria y en general, los recursos del nodo. Cuanto más pesado sea, más tiempo tardará en arrancar y mayores recursos necesitará. Por tanto, todos los servicios o end-points del artefacto están replicados por igual en cada nodo y acceden a los mismos recursos del sistema, con independencia de la frecuencia con que se usen para resolver las tareas del sistema. En todos los servidores se ejecutan réplicas idénticas del back-end, capaces de hacer las mismas operaciones de lectura y escritura contra la base de datos; por tanto lo normal es que escalar la capa de negocio conlleve escalar la capa de datos.

Cuando alguna de las partes de tu sistema se ha convertido en un Monolito lo normal es que tengas algunas desventajas, que veremos a continuación.

Cosas malas que pasan cuando tienes un Monolito

Desde el punto de vista del desarrollo, cuando todo el back-end de una plataforma (y en este artículo estamos hablando de un eCommerce Top 100) está construido como un Monolito, se producen unos efectos indeseables que impactan en la productividad y eficiencia del equipo. ¿Por qué?

Porque todo el equipo de desarrollo del back-end trabaja sobre el mismo artefacto. Cuando hay demasiada lógica de negocio en la misma capa, es normal que se rompa la modularidad de los componentes con el paso del tiempo, conforme se van haciendo extensiones del producto, o se corrigen errores. Por ejemplo, añadir un nuevo medio de pago a un eCommerce puede afectar: al módulo desde el que se procesan los pagos, al que renderiza el selector de medios de pago durante el proceso de checkout, al que gestiona el medio de pago favorito en el perfil del usuario (necesario para los one-click-payments), etc. Eventualmente llega un momento en que el sistema es una maraña y es costoso tener una visión global de cómo funcionan las cosas.

Como además el back-end es un único componente que se carga completamente, los entornos de desarrollo son cada vez más costosos de arrancar, se tarda más tiempo en compilar y en ejecutar y depurar en local. Esto hace que cada vez los ordenadores para el desarrollo requieran mayores prestaciones; algo que no siempre es posible conseguir porque puede llegar a chocar con las políticas de actualización de los departamentos de tecnología, o los responsables de compras. ¿Alguna vez habéis visto a personas cronometrando cuánto tiempo tarda en arrancar el Eclipse, o cuántas horas pierde al día mientras espera en las compilaciones? Yo sí, y es muy lamentable.

Un back-end que acaba siendo un Monolito hace que todos sus componentes y módulos que se despliegan como un mismo artefacto, estén ligados a un lenguaje de programación específico, y a unas determinadas versiones no sólo del framework de desarrollo, sino de las librerías que se importan. Los cambios de versiones son más costosos, porque se hace necesario validar el impacto que puede tener el cambio de librería en todo el sistema como un conjunto (en lugar de en partes concretas donde el cambio puede tener más sentido). Eso por no hablar de cambiar de stack tecnológico. Un proyecto de refactorización de un sistema para ir aliviando la deuda técnica, puede ser una inversión en tiempo y dinero difícil de justificar ante el responsable de asignar recursos económicos a los proyectos.

Antes de levantar este monolito de 36m y 150 toneladas se rompió la build. Por eso se llama El Obelisco Inacabado de Asuán

A la larga, todo esto unido significa que se incrementa la curva de entrada de las nuevas incorporaciones al equipo, con lo que aumenta el tiempo que necesita una persona para hacer trabajo productivo. Cuando el tamaño del equipo de desarrollo alcanza un nivel importante, y estamos hablando de un eCommerce Top 100 (no de la demo de la tienda de mascotas), aumenta el esfuerzo de coordinación de los diferentes subproyectos / extensiones que se van haciendo en paralelo. Esto puede llegar a hacer difícil segregar las responsabilidades de los diferentes equipos, y por tanto su autonomía e independencia; y complicar el modelo de gestión de los diferentes proyectos / equipos. Podemos añadir a esta ecuación que las personas pueden estar distribuidas en diferentes localizaciones, cosa habitual en los tiempos que corren.

Desde el punto de vista del delivery, actualizar un sistema Monolítico requiere recompilar toda la aplicación, volver a empaquetarla y redespeglar. Al ser una sola pieza, hay que parar todo el sistema por completo para hacer la actualización.

Además, si llega el caso en que el sistema tiene que escalar, es necesario hacer que escale todo el monolito al completo; en lugar de aumentar la capacidad de aquella parte del proceso / operación que realmente lo necesita. Lo que lleva a aumentar la capacidad (procesamiento, memoria, almacenamiento) del servidor en el que corre, y podría no ser la estrategia de infraestructura más óptima en términos de inversión.

Finalmente, una vez que empiezan a dar servicio, en caso de que se produzcan errores, el proceso de depurarlos e identificar dónde se está produciendo el error puede llegar a ser complejo debido al acoplamiento. Es cierto que desde hace años (de cuando yo programaba) ya están inventados los IDE de desarrollo que se conectan a un servidor y permiten hacer depuración en tiempo real, y esto ayuda a encontrar los errores. Sin embargo, cuanto mayor sea el acoplamiento, y más pesado el entorno de desarrollo y sus dependencias, más implicaciones puede tener encontrar y depurar un error, corregirlo y validar la solución, por el efecto secundario que pueda tener en otros componentes.

Cuando existe fuerte acoplamiento entre los elementos de la aplicación, lo normal es que no se haya logrado separar operaciones y reutilizar código. De forma que cuando hay que modificar o corregir cualquiera de sus funcionalidades, se requiere primero entender cómo el cambio puede afectar a sus diferentes partes; y lo que es peor, identificar todos los puntos en los que se tendría que replicar la actualización.

¿Entonces?

Esta casuística la comparten centenares de plataformas y sistemas de software; y la extienden a los centenares de miles de sites de comercio electrónico por todo el mundo construidos sobre ellas. Podríamos pensar que tampoco pasa nada, que no van a morir niños de hambre en el Tercer Mundo, ni vamos a prolongar el Cambio Climático (y eso sí que son problemas de verdad).

Pues me siento más ligero sin mi Monolito

Recordemos: estamos hablando de construir un eCommerce Top 100, uno que se espera que sea referente de su sector porque lo va a construir una empresa líder. Si a tu eCommerce le vas a exigir facturar millones de euros al año; operar en decenas de países; recibir miles de peticiones concurrentes de personas de todo el mundo; conocer en tiempo real el stock de artículos y tallas; y cerrar procesos de compra con seguridad. Y por qué no, conseguir finalizar las transacciones en ese milisegundo que es la diferencia entre comprar o quedarte sin stock.

Hoy en día tiene cierta madurez y solvencia la aproximación tecnológica que permite dividir el back-end de la aplicación en partes más pequeñas, especializadas en hacer una única tarea, cada una con su propia capacidad de desarrollarse, desplegarse y escalar por separado. Con su propia arquitectura, consumiendo los recursos que necesita, y gestionando únicamente aquellos datos sobre los que tiene responsabilidad. Pero antes de hablar sobre cómo materializar este planteamiento en una arquitectura de microservicios, habrá que saber cuáles son los elementos que tiene que tener un eCommerce Top 100. Y eso lo veremos en el siguiente capítulo.

(Continuará…)

(Espero que antes de 6 meses)

Cómo construir un eCommerce Singular. Capítulo 1, El eCommerce Top 100

Publicado el noviembre 17, 2017 por carlosguardiola

Introducción

Comienzo aquí una serie de posts sobre cómo construir un eCommerce Singular, candidato a estar en un listado de Top 100, utilizando una arquitectura de microservicios. Son dos de los temas a los que dedico mi atención últimamente en Sngular. En cierta medida es normal: por una parte Sngular es una empresa que lleva construyendo tiendas online prácticamente desde sus orígenes como MediaNet, a mediados de los años 90. Algunos de los proyectos que hemos hecho son www.lolamarket.com , el caso de ModeloNow de Grupo Modelo (ahora https://www.pepedelivery.com/), https://www.cuidadoconelperro.com.mx/ y sus dos millones de fans en Facebook, cuando hicimos Planeo.com del Grupo PRISA, y por encima de todos ellos, el caso de BuyVIP y su posterior adquisición por Amazon. Por otra parte, porque los compañeros del área de Arquitectura llevan ya unos años construyendo soluciones basadas en microservicios. Empezamos en entornos de banca, pero la realidad es que se trata de una aproximación que cada vez tiene más adopción a la hora de construir grandes sistemas distribuidos, que gestionan miles de transacciones al día y que tienen que responder y escalar ante picos de carga.

Total, que me parecía interesante compartir algunas reflexiones. El hilo argumental que voy a seguir se materializa en los siguientes capítulos:

¿Qué es un eCommerce Top 100 y por qué hay que hacerlo a medida? Donde vamos a repasar los diferentes tipos de sites de eCommerce que construimos en Sngular, los criterios de cualificación con los que los clasificamos, y sobre todo, qué es lo que nosotros consideramos un eCommerce Singular. Aprovecharé para compartir algunos datos que me parecen relevantes a la hora de enunciar nuestra definición, y que además, son la clave de la argumentación de los 3 motivos por los que siempre vamos a recomendar hacerlos a medida.
El bloque Monolítico. Una de las principales áreas de trabajo y evolución de la disciplina de la Arquitectura de Software es la creación de sistemas desacoplados, que combinen la eficiencia en el consumo de recursos para producir resultados, la capacidad de escalar ante los picos de carga del sistema, y que puedan ser extendidos y mantenidos por un equipo de desarrollo. Desde los años 90 existe el patrón de 3 capas (presentación, negocio y datos) que aplican todos los eCommerce del mundo, pero un back-end puede terminar por convertirse en un Monolito, y eso podría ser una barrera para el crecimiento / rendimiento de un eCommerce Top 100. Por cierto, que hay empresas como Basecamp o Etsy que defienden sus arquitecturas de Monolito Majestuoso; también hablaremos sobre ello en los Apéndices.
Los elementos de un eCommerce. Para crear una arquitectura de referencia de microservicios sobre la que construir un eCommerce Singular, hay que tener una idea de los elementos estarán presentes en la tienda online. En este capítulo haremos un benchmarking de sites que servirá posteriormente como base para plantear la arquitectura. Me refiero a aspectos como la gestión de múltiples países, el registro de usuarios, el catálogo, las páginas de producto, las recomendaciones, el proceso de checkout, el pago en one-click, la integración de medios de pago, etc. Para escribir sobre esto intentaré engatusar a Farid Fleifel y Javier Cuervo.
Arquitectura de Microservicios de Referencia. Donde se presentará un modelo de arquitectura que contenga los elementos descritos anteriormente, y un planteamiento de muy alto nivel sobre qué tecnologías utilizar para construirlos. Se que muchos pensaréis que qué coño voy a contar sobre esto si la última vez que abrí un Eclipse fue en 2009, pero no os preocupéis porque en este capítulo espero contar con la visión de César Camargo, Eugenio Concepción, Iñaki Reta, Daniel Castilla, y el resto de compañeros del equipo de Arquitectura de Sngular. (Puede que os parezca un truco sucio dejar sus nombres por escrito, pero así es la vida¯\_(ツ)_/¯ )
¿Cómo hacer la transición? En el último capítulo haremos una pequeña revisión de diferentes estrategias para hacer la transición de un sistema a una nueva arquitectura de microservicios, sin pérdida de continuidad del negocio (sin dejar de vender, vamos). Lo que viene siendo el símil de cambiar el motor del avión en pleno vuelo.

En fin, es un reto ambicioso porque me salen unos cuantos posts. Pero bueno, lo mejor es empezar por el principio. Así que vamos a ello. Espero que os parezca interesante 😉

Capítulo 1. ¿Qué es un eCommerce Top 100 y por qué hay que hacerlo a medida?

Estoy en condiciones de afirmar, sin posibilidad de error (incluso con apuesta de pincho de tortilla y caña) que en todas las reuniones en las que he estado donde una o más personas querían crear un modelo de negocio de eCommerce, siempre ha salido la pregunta del millón. Y contra todo pronóstico, la pregunta del millón no es “¿qué tengo que hacer para vender mi primer millón de euros online?”, sino “¿esto se hace con una plataforma o se desarrolla a medida?” La siguiente pregunta es “¿y cuánto va a costar?”.

En Sngular, como somos gente muy práctica y además transparente, estudiamos cada caso y hacemos una recomendación basada en la necesidad, el escenario y en general todas las condiciones de contorno del caso del cliente. Esto siempre gira en torno a las dos Cs Elementales del eCommerce. La primera es la de la Cualificación del tráfico y la segunda la de Conversión. El propósito de cualquier plataforma que se construya debe ser la de convertir tráfico cualificado en ventas de productos de calidad, y eso se consigue a través del diseño de una experiencia de compra construida sobre una plataforma tecnológica. Hay otros elementos del círculo virtuoso del eCommerce, como es la capacidad de hacer la entrega de los productos, y el servicio post venta que se da al cliente. Todos son importantes para lograr el éxito.

Pero lo más importante desde nuestro punto de vista es que una tienda online, es un modelo de negocio de base tecnológica. Es decir, la tecnología es una condición necesaria (pero no suficiente) para el negocio: para que funcione y crezca. Dicho lo cual, en nuestro árbol de decisión, existen cuatro categorías de eCommerce.

En el escalón más básico está el eCommerce MVP (de Minimun Viable Product) que refleja aquellas situaciones donde se está creando un modelo de venta estándar que incluye las 3 Cs Básicas del eCommerce (Catálogo, Carrito y Check-Out), en una compañía 100% online (es decir, no hay venta física), que inicia una etapa exploratoria de la viabilidad de su idea con un catálogo de productos reducido. Aquí nuestra recomendación es concentrarse en validar la idea negocio lo antes posible, con una inversión acotada. Por eso apostamos por plataformas tipo Shopify (un eCommerce as a Service) o WooComerce (que por resumir, es una extensión de WordPress) En un eCommerce MVP el rango de inversión inicial empieza en torno a los 16 o 20K y puede llegar a los 50K sólo en tecnología (es decir, sin contar otras inversiones necesarias como el sourcing o campañas captación de tráfico, etc), y un time to market que no supera las 6 semanas. Es una inversión pequeña, como pequeño es también el control que se tiene sobre la solución. Lo importante en este caso es validar el modelo con una inversión que si no cubre la expectativa no suponga grandes pérdidas; pero que si se demuestra que el modelo de negocio es viable, se pueda tirar a la basura sin gran tristeza, y pasar al siguiente escalón.

Ese sería el de un eCommerce Standard, aquellos casos en los que existe un catálogo con más o menos cierta profundidad, en un modelo de venta que empieza a considerar las 2 Cs Adicionales (Consejos y Comentarios) para incrementar el ticket medio y la fidelización de los usuarios. En este escenario, el promotor no necesita validar la viabilidad de su idea, porque ya se sabe que lo es; y tiene prevista una inversión moderada en un horizonte temporal de medio plazo (1 o 2 años). Nuestra recomendación es ir o bien a una plataforma estándar tipo Magento / Prestashop o construir sobre nuestra plataforma Sngular Billionlabs basada en PHP Laravel. La decisión fundamentalmente depende de las integraciones a realizar, de cómo se espera abordar la omnicanalidad, y en general de hasta qué punto se quiere o necesita construir sobre la plataforma para lograr materializar el site. Cuanto más estándar sea, más fácil es que se pueda construir sobre una plataforma de mercado; sin embargo, la particularidad del modelo, o del diseño, o de las integraciones pueden marcar la diferencia entre construir sobre plataforma de mercado y re-construir una plataforma de mercado. Por lo general, re-construir la plataforma es una mala idea, se pierde la continuidad con futuras versiones, aumenta la complejidad del mantenimiento y la extensión, y se acaba con un bonito Frankenstein. Si en tu horizonte te ves con un Frankenstein, lo mejor es que te plantees un desarrollo a medida desde el principio. En este tipo de eCommerce, la inversión sólo en tecnología puede empezar en el rango de los 60K-80K anuales y llegar a los 100K-120K. En cuanto al time to market, ya varía entre usar plataforma o desarrollo a medida, sin embargo nuestra experiencia nos dice que a partir de la semana 8 ya es posible tener una primera versión lista para empezar a vender online, en un proyecto que con entregas iterativas puede llegar a las 16 semanas.

Estadísticas de plataformas de eCommerce según datos de https://trends.builtwith.com/shop

El tercer escenario es el eCommerce Pro, el de empresas en un importante nivel de madurez que apuestan por el online como una fuente de ingresos relevantes dentro de un plan de negocio en varios países. En este caso el nivel de adaptaciones específicas es cada vez mayor, sobre todo con la integración de otros sistemas corporativos. Este tipo de proyectos tienen previstos fuertes inversiones no sólo en tecnología, también en captación de tráfico para el site. El catálogo de productos es relevante, el modelo online incluye todas las Cs del eCommerce habidas y por haber; y otros aspectos como la gestión de inventario (que puede estar distribuido) y logística de entrega (donde puede haber diferentes proveedores) o medios de pago (incluyendo por ejemplo diferentes plataformas para cada país) tienen mayor peso. Hay además una necesidad fuerte de integración de sistemas existentes (propios o de terceros), y el site forma parte de una estrategia omnicanal donde el cliente puede llegar a interactuar con la marca y el producto en tiendas físicas, en el online, en el móvil, etc. En este caso, la recomendación de Sngular es ir con grandes plataformas como Hybris / Oracle ATG / IBM Websphere según lo aficionado que uno sea a dejarse guiar los Gartner y Forrester de turno, o hacer un desarrollo completo a medida.

En general, si la tienda online requiere integrar un elevado número de sistemas legacy para procesar las operaciones; o está concebido como una plataforma en la que acceden diferentes terceros; o el modelo de negocio no encaja al 90% con el estándar de una plataforma, nuestra recomendación es un desarrollo a medida.

En un eCommerce Pro, el rango de inversión empieza en los 120K-160K anuales sólo en tecnología, y puede llegar al millón de euros cuando empezamos a meter licencias e infraestructura. En estos escenarios hay mayor variabilidad en el time to market, si bien es razonable pensar que en el mes 4 puede haber una plataforma bastante parecida al resultado final, sobre que la que se puede seguir iterando ampliando funcionalidades hasta los meses 6-8.


Gartner Magic Quadrant to Digital Commerce, April 2017	Forrester Wave Report for B2C eCommerce, Q1 2017

eCommerce Singulares según Sngular

Por último tenemos la joya de la corona. Esos que llamamos los eCommerce Singulares. La clase de eCommerce que siempre recomendaremos construir a medida, porque nuestro cliente quiere entrar en el Top 100. Para lograrlo es posible que haya que dar respuesta la creación de un modelo de venta propio, clave para la ventaja competitiva y por tanto, no cubierto por ninguna plataforma estándar. En este caso estamos hablando de inversiones por encima de los 250K sólo en tecnología el primer año, que pueden empezar directamente en los 400K-500K.


DigitalCommerce360 Internet Retailer Top500 Report (USA y Europa)

Los datos que publica DigitalCommerce360 son muy interesantes, muestran que el 41% de los Top 100 eCommerce de Estados Unidos desarrollan a medida su tienda online. Este dato sube hasta el 58% si lo filtramos al Top 100 eCommerce en Europa. Amazon, Alibaba o Rakuten, los gigantes del eCommerce mundial, han desarrollado a medida sus plataformas (propias, que luego abren a terceros o incluso permiten que se construya sobre ellas). Si miramos la lista de los principales eCommerce de Estados Unidos, podemos comprobar que todos han desarrollado su propia plataforma de comercio electrónico, y de hecho en algunos casos como Amazon.com o Wal-Mart la han abierto a que otras empresas puedan construir con ellas.

Facturación del Top5 eCommerce US en 2016 (Fuente: WWD)

El eCommerce Singular siempre hay que hacerlo a medida

Nuestra recomendación para crear un eCommerce Singular es siempre el desarrollo a medida. Para conseguir un eCommerce que entre en el Top 100 tienes que mantener el liderazgo estratégico frente a tu competencia, tener el control sobre tu plataforma, y evitar el vendor lock-in;

Liderazgo estratégico. No se puede condicionar en ningún caso la implementación de una estrategia de comercio online a las capacidades o features de una plataforma, y mucho menos al roadmap de evolución que haya decidido un fabricante. Esto es fundamental: ser un eCommerce Top 100 significa innovar, liderar y estar por delante de los competidores. Construir sobre una plataforma implica tener los mismos niveles de libertad y las mismas funcionalidades que el resto de tus competidores que la usan. Crear tu propia plataforma te permite construir tu propio liderazgo.
Continuidad del producto. Construir extensiones o adaptaciones sobre una plataforma propietaria no evita una inversión elevada, por la especialización de las personas que tienen certificados los conocimientos para hacer las extensiones o adaptaciones sin que impacten en el rendimiento o escalabilidad. Sobre todo, tampoco garantizan que ante una nueva versión del core de la plataforma las extensiones vayan a seguir funcionando. Tu propia plataforma puede evolucionar y re-evolucionar según tu necesidad.
Vendor lock-in. Utilizar tecnología propietaria, es decir, no estándar, siempre tiene asociado el riesgo de convertirse en una relación asimétrica, en la que el proveedor tiene un papel dominante sobre el cliente, llegando incluso a coartar su independencia. El temido vendor lock-in. Construir una plataforma según tus propias especificaciones usando tecnología estándar y abierta te permite crear tu propio equipo de desarrollo in-house, o abrir el desarrollo de forma transparente a un amplio abanico de proveedores.

En general, una plataforma a medida permite tener el control absoluto sobre el modelo de negocio, la experiencia del usuario, la tecnología y su evolución.

Las cuatro categorías de eCommerce tal y como las concebimos en Sngular

De cualquier manera, supongamos que tienes un eCommerce Top 100 construido sobre una plataforma de terceros, que ha ido evolucionando con integraciones y extensiones. O que es un desarrollo a medida hecho entre 2010 y 2015 (me resultaría difícil pensar que a día de hoy alguien está vendiendo como churros algo en internet con un desarrollo de hace más de 8 años) Puede que esté desplegada en la nube de Amazon AWS o de Microsoft Azure; de cualquier manera, seguramente lo que tienes es, como se dice en el ámbito del software, un Monolito.

Y si estás en el momento de rehacer tu eCommerce, o tienes luz verde para crear un nuevo eCommerce Top 100, lo que deberías evitar es ponerte a construir un Monolito. Pero, ¿qué es eso del Monolito?

(Continuará…)

Operaciones, Innovación y la Guerra de los Mundos

Publicado el marzo 14, 2016 por carlosguardiola

Investigar es meter dinero y sacar conocimiento; innovar es meter conocimiento y sacar dinero (José Luis Vallejo, CEO de s|ngular)

Puede que algunos penséis que está feo citar al jefe de cada cual, pero esta frase que José Luis dijo en uno de los cursos de verano que organizamos en la Universidad Internacional Menéndez Pelayo resume a la perfección mi punto de vista al respecto (entended que quizá pueda estar condicionada porque trabajo en una empresa privada)

Las empresas tienen que innovar para sobrevivir

Bien, esto es algo que me gustaría que se me hubiese ocurrido a mí, pero por desgracia es algo universalmente conocido. Vivimos en un mundo en el que los cambios suceden cada vez más deprisa, principalmente de la mano de la tecnología. Efectivamente, en la última mitad del siglo XX, el avance en capacidad de computación y la conexión ubicua está fomentando cambios radicales en toda clase de industrias. Por ejemplo, a través del efecto de la desintermediación que está destrozando cadenas de suministro tradicionales y dadas por hecho. Como reflexionaba Tom Goodwin en Tech Crunch

Uber, la mayor compañía de taxis no tiene ningún coche
Airbnb, la empresa que más habitaciones pone a disposición de turistas, no tiene propiedades inmobiliarias
Facebook, el mayor proveedor de contenidos, no crea ni produce contenidos
Instagram, la empresa de fotografía más valiosa, no vende cámaras
Netflix, la mayor cadena de televisión, no tiene cables ni antenas
Y Alibaba, el distribuidor que llegó a sobrepasar a Amazon en valoración, no tiene inventario

Recordemos que Netflix arrancó sus operaciones en 1997 y Alibaba.com en 1999. La tecnología habilita la innovación, que a su vez propicia modelos de negocio exponenciales. Por lo general, una compañía de las que tradicionalmente formaban parte de la lista de S&P 500 necesitaban 20 años en conseguir una capitalización del billón (americano) de dólares (americanos). Sin embargo, Oculus, que se fundó en Junio de 2012, fue adquirida por 2 billones (americanos) de dólares (americanos) en marzo de 2014.

¿Velocidad absurda? Señor jamás hemos ido tan deprisa, la nave no la resistirá (Imagen de Yuri Van Geest)

La historia empresarial desde los años 40 se ha basado en el axioma de la Calidad Total: la ventaja competitiva se conseguía a través de la excelencia en los procesos productivos y en el servicio al cliente. Sin embargo, y por injusto que parezca, grandes empresas han sido barridas del mapa cuando sus competidores han roto las reglas tradicionales del juego. Y si todo el mundo estamos viendo estas clase de cosas pasar a nuestro alrededor, ¿por qué muchas empresas y modelos de negocio siguen condenados a extinguirse?

Operaciones vs Innovación ¡FIGHT!

Principalmente, porque estadísticamente la mayoría de las empresas no consiguen combinar la Gestión de las Operaciones y la Gestión de la Innovación. Y esto es básicamente porque el Mundo de la Implementación y el de la Creación son dos mundos diferentes, con escenarios, necesidades, personas y mapas mentales diferentes. Algo muy parecido al tema del hemisferio derecho y el hemisferio izquierdo, solo que aplicado a la empresa.

En un combate entre Operaciones e Innovación, pierde la Empresa

Podríamos decir que las personas que trabajan en el Mundo de las Operaciones trabajan con «certezas»: sus datos son objetivos, y sus procesos están documentados. Hay reglas. Se puede predecir lo que va a pasar. Si A entonces B. Etc. En general, en el Mundo de Operaciones se invierte (tiempo, esfuerzo y dinero) en hacer cada vez un poco mejor algo que ya se sabe cómo hacer (lo que está muy bien y es muy necesario). Por resumir las características del Mundo de las Operaciones:

Visión del corto plazo. Se trabajan para los ingresos del hoy y en las cuentas de resultados del año en curso, por tanto se toman Decisiones Ejecutivas, a partir de la observación o medición y evaluación. Además, el resultado de estas decisiones tienen resultados igualmente medibles en el corto plazo.
Procesos conocidos. La forma de trabajar es conocida, por eso está claramente definida, delimitada, documentada y compartida. No sólo eso, sino que seguramente haya sido certificada con alguna norma de Calidad. De esta forma, se conocen los resultados esperados ante determinadas situaciones, existen reglas y se trabaja para evitar los errores.
Objetivos definidos. La mezcla de los dos anteriores. Las áreas de Operaciones tienen sus objetivos de crecimiento, facturación, rentabilidad, etc. definidos a principio de año.
Equipos consolidados. Por lo general, los departamentos de Operaciones tienen su estructura y composición. Los puestos están definidos y se conocen sus características. En caso de crecimiento, los perfiles profesionales son conocidos por el área de selección.
Búsqueda de la eficiencia. El proceso de mejora del área de Operaciones por lo general tiene que ver con hacer los procesos más eficientes, bien porque se reducen los costes o porque se mejorar los resultados. Además, existen métricas claras para medir la productividad, y datos históricos que permiten el análisis.

Sin embargo, el Mundo de la Innovación es completamente diferente: se trabaja con la incertidumbre y la subjetividad, experimentando con nuevas formas de trabajo. Vivir en el Mundo de la Innovación supone:

Tener una visión a largo plazo. Se trabaja para buscar los ingresos del mañana. A partir de tendencias, patrones o investigación, las áreas de innovación intentan definir nuevos productos y servicios que signifiquen éxitos comerciales o fuentes de ingresos del mañana. Puede conseguirse o puede que no. Pasa hasta en las mejores familias. A menudo las decisiones se toman en forma de apuesta, con incertidumbre y sin un historial previo de acierto.
Procesos por descubrir o definir. Dado que se está trabajando en nuevos productos o servicios, la forma en que se construyen o se prestan todavía no está consolidada ni optimizada. Eso significa que muchas veces el proceso se construye sobre la marcha, como parte de la innovación, o peor aún, como resultado de la misma entendiendo cómo se ha conseguido. Lo importantes que tener procesos por definir supone que no están claros los pasos, ni los entregables, ni las responsabilidades.
Objetivos inciertos. Crear un nuevo producto o servicio implica la mayor parte de las veces inventarse también cuáles van a ser sus objetivos, y cómo se van a medir.
Equipos incipientes. Quizá uno de los aspectos más complicados del Mundo de la Innovación es la necesidad de romper esquemas de trabajo habituales para crear equipos de trabajo multi-disciplinares y transversales a la organización. Es algo complicado precisamente porque muchas empresas fomentan las unidades o direcciones estancas, y cuando llega el momento de trabajar en equipo en el Mundo de la Innovación surgen los roces, fricciones e ineficiencias.
Búsqueda del aprendizaje. Teniendo en cuenta que el error es una parte esencial del aprendizaje. Y que el aprendizaje no es lineal, de la misma forma que la innovación tampoco lo es. La exploración a menudo supone que muchas veces hay que deshacer un camino que parecía prometedor pero que termina por no llevar a ninguna parte. Como se está creando algo nuevo, no hay un histórico de resultados sobre los que hacer análisis.

¿Quién invade a quién?

Por desgracia, la división entre ambos mundos no es tan evidente. Más bien al contrario. Cuesta mucho darse cuenta que no se puede aplicar una mentalidad, forma de trabajo y modelos de toma de decisión del Mundo de Operaciones en el Mundo de la Innovación. Tampoco se puede hacer a la inversa.

Las empresas son para el verano

Una forma muy gráfica de representar este planteamiento es la metáfora de la bicicleta: que tiene una rueda delantera desde la que se controla la dirección (Estrategia e Innovación) y unos pedales y una cadena que proporciona tracción a la rueda trasera (las Operaciones)

Hay bicicletas que se adaptan mejor a unos terrenos o entornos que a otros (así existen bicicletas de montaña, de carreras, de contrarreloj…) lo cierto es que hay algunas que no son prácticas y tienden a dejar de usarse:

Bicicletas de Equilibrio.La forma de avanzar es costosa, ya que requiere de la capacidad de aguante del niño que va subido encima empujando. Sin pedales ni cadena se puede avanzar, pero nunca se llega demasiado lejos. Hay empresas en las que las áreas de innovación y operaciones no se entienden y por tanto no se comunican. Cada una va por su lado.
Velocípedo. Famosas a finales del siglo XIX, este tipo de bicicletas se caracterizaban por tener los pedales directamente en una gran rueda frontal, de manera que la tracción es directa a la rueda. Aunque alcanzaban gran velocidad incluso por calles adoquinadas, eran peligrosas por su peso, equilibrio y esfuerzo necesario. Quedaron obsoletas tras la invención de la cadena y los piñones, que aportaban mayor velocidad a las bicicletas. Este mismo paralelismo ocurre empresas en las que las Operaciones dirigen la Innovación. Pueden llegar a optimizar sus costes y procesos, pero son desbancadas por las innovaciones de su competencia.
Monociclo. Para poder desplazarse en monociclo hace falta tener muy buen equilibrio y mucha práctica. Aunque uno pueda desplazarse por la calle, es difícil subirse una cuesta o recorrer largas distancias. Del mismo modo, las empresas donde no hay innovación sobreviven a base de músculo financiero y no suelen llegar muy lejos.

Freak Show! Alive on our Stage!

La realidad es que cada Mundo tiene que tener su espacio: el Mundo de las Operaciones debe ser el sustento del Mundo de la Innovación, y el Mundo de la Innovación a su vez debe ser el que garantice la continuidad del Mundo de las Operaciones, en un entorno cada vez más competitivo y cambiante.

Yo, robot

Publicado el noviembre 15, 2015 por carlosguardiola

Aunque se estima que en el mundo vivimos más de 7 billones y medio de personas, en realidad la mayoría no existimos. Al menos en Internet. Queridos amigos, reconoced conmigo que el captcha no es suficiente, vamos a acabar implantando el test de Voight-Kampff para cualquier click, like o submit que se precie (sí, el de Blade Runner) Veamos 3 ejemplos de negocios exitosos que alimentan ecosistemas emprendedores basados en el fraude.

1. El restaurante mejor valorado que no existía

Imagina que estás pasando unas apacibles vacaciones en el paradisíaco entorno del Lago de Garda y no sabes dónde ir a comer. Abres TipAdvisor y buscas los restaurantes mejor valorados de la zona, siguiendo la promesa de la red social de que son las personas como tú, con sus puntuaciones y comentarios, los que hacen los rankings (y no la maldita propaganda, o la inversión en publicidad). La verdad es que te llevarías una decepción, porque irías de cabeza al «Ristorante Scaletta» que no sólo no existía, sino que estaba en lo alto de un monte 😦

Ristorante Scaletta, vaya jeta

En efecto, todo era una invención de un diario italiano, que quería demostrar que TripAdvisor no sólo no valida ni comprueba las valoraciones de los usuarios, sino que le daba igual que los locales existiesen. En un mes, este restaurante se convirtió en una referencia de la zona. Puedes leer el experimento aquí (no hace falta italiano nivel Dante, se entiende por el contexto)

Precisamente en Italia, la autoridad Antimonopolio fijó una multa para TripAdvisor por la falsedad de sus reviews, de nada más y nada menos que de 500.000€ Al final, un juez resolvió este verano el caso, admitiendo la apelación de la empresa y desestimando la denuncia. El motivo:

«TripAdvisor never asserted that all the opinions were real, even mentioning that verification was impossible and to consider the trend rather than each comment one by one»

TripAdvisor tiene más de 250 millones de reviews. ¿Cuántas de ellas corresponden a personas que han pagado realmente por un servicio? NPI (No Puedo Intuirlo) Recientemente se ha lanzado una campaña en twitter (#noreceiptnoreview), en la que los hosteleros que no pagan por sus reviews (o sus bots amaestrados) quieren concienciar a TripAdvisor de la necesidad de que se verifique que los usuarios realmente están valorando servicios que han consumido. La empresa ya ha comunicado que de momento lo descarta.

Todo esto tiene que ver con que un estudio de la Harvard Business Review concluyó que una, una miserable estrella más en Yelp hacía que el volumen de ingresos de un restaurante independiente subiese entre un 5 y 9%.

Se lo que estás pensando: hagamos un ejército de bots y gestionemos esas reviews a cambio por ejemplo del 30% de aumento de facturación.

2. No te libras de tu cuñao ni en Amazon

Al igual que en TripAdvisor, también Amazon es un nido de cuñaos. Entendiendo como tal el término cariñoso con el que nos referimos a personas que opinan de cosas de las que no saben y sin tener el contexto. Y lo que es peor, a muchos les pagan y hay varias empresas que viven de ello.

¿Por qué? Porque por ejemplo en España 2 de cada 3 consumidores leen las recomendaciones antes de comprar, y en su día, la plataforma de revisión y valoración Reevoo estimó que los productos con más de 50 reviews incrementaban su tasa de conversión en un 4,6% Es más, la propuesta de valor de Reevoo a los retailers es aumentar sus ventas un 18%

Hago reviews por cerveza

Algunos datos que pueden interesar:

En internet te hacen por 5$ una valoración de 5 estrellas de tus artículos en la tienda de Amazon; por ejemplo en el sitio de micro empleos Fiverr (que por cierto levantó 30 millones de $ en rondas de financiación en 2014). Hay sitios, como BuyAzonReviews que te las venden por 22€, pero ojo, porque son revisiones de calidad
Precisamente Amazon acaba de demandar a 1.114 personas que desde Fiverr se ofrecían a escribir valoraciones falsas, alegando que están incumpliendo los términos de servicio. Si alguno tiene interés, puede leerse la demanda porque está subida a scribd. Ya lanzó otro proceso de demanda en abril contra cuatro empresas que ofrecían este servicio.

De hecho, Amazon anunció en junio que empezaría a usar sus modelos de Machine Learning desarrollados a medida para detectar recomendaciones falsas, preocupados por ese ecosistema que surge a su alrededor de gente que se lucra con las reviews falsas, y el impacto que esto tiene en la credibilidad que perciben los clientes. El objetivo del sistema es aprender qué reviews han sido útiles y valiosas para los usuarios, y se aplicará tanto a las estrellas como a los comentarios de texto; dando peso a las valoraciones de usuarios validados, tomando en cuenta las valoraciones de 5 estrellas de productos mediocres, etc.

¿Cuánto puede haber invertido Amazon en sus motores de ML? Ojalá lo supiera. Lo suficiente como para haber llegado a paquetizarlo y ofrecerlo como Machine Learning as a Service.

3. Nadie clickea en tus banners

Aunque algunos expertos de la cosa parece que acaban de darse cuenta, el modelo de pago por impresiones está robotizado que se sepa al menos desde marzo del año 2004.

Por aquél entonces, un señor llamado Michael A. Bradley intentó extorsionar a Google: si no le pagaban 100.000$ abriría masivamente un software de su inversión en el que había trabajado durante 5 años, capaz de generar 3.000$ al mes de ingresos para todos aquellos que quisieran montar modelos de estafa en publicidad. Entre los testimonios de su web, alegres apandadores reconocían haber generado 30.000$ al mes con sólo 10 cuentas de AdSense, con el irrisorio coste de 250$ en concepto de licencia.

Quizá el problema pase de castaño a oscuro cuando son los propios intermediarios del modelo de publicidad online quienes crean los esquemas de fraude. En 2013, The Wall Street Journal publicó que el 54% del tráfico publicitario que redes de anunciantes, brokers y agencias vendieron (y cobraron) entre Mayo de 2012 y Febrero de 2013 no lo vio ningún ser humano.

La Association of National Advertisers (ANA) publicó en Diciembre de 2014 datos demoledores sobre el dinero que se están gastando los anunciantes en conseguir que haya bots que vean sus anuncios. En particular, 6,3 mil millones de $. El estudio, que tuvo en cuenta las campañas online de 36 grandes empresas (como Ford, Nestlé o Pfizer) analizó 3 millones de dominios durante 60 días, contabilizando 5,5 mil millones de visitas. Algunos de los datos:

El 11% de las impresiones en display son generadas por bots
Lo que se dispara hasta el 23% en el caso de vídeos. Vamos, que si te quieres hacer Youtuber, monta una botnet
Por la noche todos los gatos son bots. El 28% del tráfico nocturno lo generan las máquinas
Hay dominios en los que el % de bots se sale de la media, relacionados con finanzas (22%), familia (18%) y hogar (16%)
En el caso del sourced traffic el % de bots llega hasta un deslumbrante 52%, cuando debería ser una garantía de mayor calidad de la visita

En fin, es un negocio redondo. La siguiente imagen os podrá dar una pista de toda la gente que puede llegar a lucrarse gracias a una sencilla red de bots.

Chain of fools

Como veis, el único que no sale es el anunciante, o como a muchas personas les gusta decir, «el que paga la fiesta»

4. Arañas contra Bots

Si estás pensando montar una estafa de publicidad en internet, ten en cuenta que los principales esquemas de fraude se simplifican en dos:

Creas una red de bots en sólo 15 minuos, te pones a infectar ordenadores y te acercas a algún eslabón de la cadena a vender tráfico. Siempre que alguien considere que puede meterle un markup a tu coste y vea los grandes números, hay mercado seguro.
Montas una red de sites donde coloques los anuncios, inviertes en SEO para justificar lo bien posicionado que estás, y sobre esos, generas tu propio tráfico.

Pero esto no es todo vino y rosas, hay gente ahí fuera que te va a intentar cazar. En Febrero de 2014, Google compró spider.io una startup con sede en Londres en la que un equipo de 7 personas llevaban 3 años desarrollando herramientas que detectasen esquemas de click fraud. Aunque los detalles de la operación no son públicos, el movimiento de Google iba encaminado a luchar contra la principal lacra de su negocio de publicidad. Las redes de bots perjudican la credibilidad de todos los actores de la cadena, afectan a los precios, pervierten el modelo y sobre todo, es una estafa para el paganini. Un año después de la compra de Google, el equipo Antifraude está formado por 100 personas. No es de extrañar si tenemos en cuenta que según la consultora Evidon (hoy Ghostery), Google sirvió más de 316 mil millones de impresiones de anuncios en 2013.

Precisamente, en 2013 spider.io desveló la red Chamaleon, una botnet de más de 120.000 equipos infectados que costaba a los anunciantes del orden de 6 milones de dólares al mes gracias a 9 millones de visitas ficticias. Estamos hablando de un CPM de 0,66$ El informe había detectado además que la red estaba entrenada para simular tráfico en 200 servidores diferentes.

Lo interesante, al menos para mí, era el por aquél entonces refinado funcionamiento de la botnet, cuyo primer rastro se remonta a 2012. Porque los ordenadores infectados simulaban comportamientos y patrones de navegación humanos.

Es su cumpleaños y le regalan una cartera de piel

Cada una de las máquinas de la red simulaba sesiones concurrentes en diferentes sitios web, creando peticiones de navegación que haría un ser humano. Por ejemplo, para no despertar sospechas, los bots eran conservadores: hacían click según patrones aleatorios en varias zonas de la página, hacían movimientos del cursor también al azar, mantenían el ratio de click through en los anuncios por debajo del 0,02%, y generaban patrones de movimiento de ratón sobre los banners del 11%.

Detectar el fraude no es sencillo, y muchas veces tiene que ver con la comparación estadística de la navegación y comportamiento de sesiones, zonas en las que se producen los clicks, la detección de operaciones masivas de destrucción de sesiones y creación de las mismas, etc. Aunque también incluye meterse en los foros del mercado negro, donde donde se compra y vende tráfico, y se gestionan rankings de reputación. Una vez que se identifica un patrón de una botnet, se sube a los servidores PowerDrill de Google, capaces de procesar medio trillón de datacells en menos de cinco segundos, de forma que procesan cantidades masivas de tráfico recibido en un site buscando esos patrones.

El patrón de comportamiento de Chamaleon que detectó spider.io

Cuando se identifican patrones de navegación robóticos, Google echa el freno: deja de pagar al publisher que publicó el anuncio, y no cobra al anunciante.

PS. Bot Data

Teniendo en cuenta que el 61,5% del tráfico de Internet es cosa de bots, a veces me pregunto cuántos data scientist hay por ahí analizando pautas generadas por máquinas.

PPS. Los bots de LinkedIn

Y en LinkedIn ¿también hay bots y cuentas fake?

Pues claro, ¿qué os habéis creído? Tened en cuenta que como dice el título del post, al contrario que en muchas redes sociales, en LinkedIn existimos de verdad. Y desde vuestra lista de contactos podéis exportar una bonita hoja Excel de direcciones de correos validadas de personas validadas.

Oro en paño para los reyes del spam. O las reinas.

Solamente di NO

Tech Trends to ignore in 2015 (ft. Led Zeppelin)

Publicado el diciembre 8, 2014 por carlosguardiola

Improve your reading listening to the playlist of this post! (powered by Spotify)

The Song remains the same

Dear friends, maybe you have noticed we are getting closer to New Year’s Eve. We should be out there shopping our Christmas gifts, but instead, we are about to be buried by Tech Predictions and Trends for 2015. Predictions made by Business Analysts, Market Researchers, Innovation Gurus… that dozens of LinkedIn members, hundreds of blog writers, and thousands of twitter users are anxiously waiting to comment and share. Sounds scary, doesn’t it?

This is one of my favourite Paleofuture pics. To hell with email, I want my jet pack (Rocket Mailmen, by Arthur Radebaug)

The best part is you can avoid it, by making a little research. If you invest 5 or 6 minutes in Google, you’ll find that most tech ‘predictions’ are like that Led Zeppelin’s song: they remain the same. Year after year. Of course, from time to time you’ll find these ‘predictions’ somehow presented in a different order (random). I bet you one pincho of Spanish omelette coupled with a caña of beer that the following 5 topics will be covered on most posts and articles of technological trends in 2015.

Communication Break Down

We are going to connect every single object to the Internet. There are enough IP addresses available to do it. Processors are as small as needed, and we can insert a mini SIM card in any possible object. So again, 2015 is going to be the year of the IoT. Like it was 2014, 2013, and 2012. Please, I just want to ask for a favour: be creative. Stop talking about the connected pacifier, the connected diaper or the connected fridge. We’ve been reading about the connected fridge since June 2000 when LG launched the first one. Do you own one? Do you actually know anyone who owns one? Exactly.

Babe, I’m gonna leave you

Companies are tired of buying servers. And they don’t want to maintain them neither. So this year we are going to invest more and more money in virtualization and cloud computing. I made my first talk about cloud computing 4 years ago, trying to break 10 common objections shared by my clients. Sometimes I still hear them 😦

Good Times, Bad Times

The way people interact with contents is no longer the same, it’s changing every day. This topic includes ‘we are going to buy better and bigger smartphones’ (although some Marketing Wizard coined the term phablet to refer a smartphone as big as a tablet), and ‘we are going to download more apps’, so there’s a lot of money in building phones and building apps. It doesn’t matter if (according to Nielsen) the average person uses each month only 26.8 of the million apps in each marketplace (1,2M in iOS, 1,4M in Android). It doesn’t matter that Canalys discovered years ago that 50% of the incomes generated in marketplaces are made by the 0.009% of the publishers (farewell Mr. Pareto). ~~Damn it~~, I’ve read a week ago that apps are going to kill freedom in the Internet. I thought it was related with Net Neutrality and FCC, but it was the apps

Kashmir

Applications and services are going to be connected. Big deal. I remember being in a training course about Services Oriented Architectures in 2008 when a Evangelist of one of the biggest ICT companies in the world dared to say that by 2013, all the software was to be built using SOAP protocols. I was about to be late to my company’s Christmas Party for listening this kind of ~~bullshit~~. With time, the debate on this topic evolved to micro services, open APIs, and API management.

Whola Lotta Love

Let’s do something with all the data we are gathering. Twitter is creating more content during a week, than the whole World during the Renaissance (I wonder which will have more impact in mankind) The point is: do we need all this digital garbage? The answer is plainly easy! We don’t need it at all 🙂 But once you are spitting data to a storage, you can identify patterns, learn something, and make choices. Don’t go to a meeting talking about Business Intelligence, or your partners are going to believe you are a time traveller from 2005. But remember: it’s not about the quantity, it’s about the quality.

Stairway to Heaven

Just tell me you have not been listening this tracklist for the last three years (at least). I have left behind ‘Security Concerns‘ intentionally, as it’s being a issue since the invention of the Internet.

Ey, Mr. Tambourine Man, play a song for me (Imagen de Heinrich Klaffs)

Once we agreed in being tired of ‘Predictions’ and ‘Trends’, what I’d really like to know is what are going to do (or how are going to innovate) the people I know. So if you don’t mind, I’ll start by sharing my own Top 5 Innovation Trends for 2015.

Workforce Gamification. Using game elements to provide awesome experiences that engage employees in learning/ transmission of company’s culture / etc. I find gamification to be an interesting technique to promote behavioral change, and companies are places where people want their colleagues to behave in a different way. Yet the truth is grown people never change, unless they find good reasons to do it. Tags: #gamification #digitaltransformationmanagement
Behavioral targeting outside eCommerce. Businesses based on eCommerce and online sales are focused (I’d say, obsessed) with conversion. Since their very beginning. But there are a lot of sectors where using data to predict client’s activity and enhance conversion is not being used, when it would be a good way to achieve growth! I’m aware there’s a lot of space to apply these techniques in FinTech. Tags: #bigdata #conversion #personalization
Online loves Offline. It’s good to know online sales are growing each year, but the truth is offline purchases provides people a meaningful experience of service, caring and support. Many companies invest a lot of effort by taking offline customers to online sales, but would it be possible to stop canibalizing the offline experience? What if we use technology to make it better instead? Tags: #bigdata #wearables #beacons #ecommerce #personalization
People wear the power. It doesn’t matter if you don’t want to: smartphones, bracelets, watches, glasses… you are going to wear them, and they can monitor what you do. So use them wisely! For example, to understand where you are, what you are doing, how you are doing it, identify patterns and help users promoting healthy habits Tags: #wearables #mHealth #gamification #beacons
Sustainability. Let’s make something useful with all the data available from your car, your house, and the energy you are using. The goal is not create a dashboard, but to provide people instant feedback on the impact that their actions have in environment and nature. Thus, to create a culture of sustainability and efficiency. Tags: #bigdata #internetofthings #energy

For me, it means Innovation because neither me nor the people I work with are doing it. And yet these are real projects that I’m planning to embrace in 2015.

What will be yours?

La Cúspide del Diseño Centrado en el Usuario

Publicado el mayo 25, 2014 por carlosguardiola

La Cúspide del Diseño centrado en el Usuario

Hace unos días compartía en la entrevista con los organizadores del Gamification World Congress que en mi opinón, la Gamificación debería considerarse la cúspide del Diseño Centrado en el Usuario.

Si echamos la vista atrás, veremos que el desarrollo de sistemas de usuario ha ido evolucionando desde que empezaron a hacerse masivas las aplicaciones en Internet en los años 90. La primera revolución fue la del diseño: los sites empezaron a diferenciarse de los demás dejando de tener ese aspecto Frontpage que todos recordamos. Para que los usuarios eligieran tu site frente al de los demás parecía que bastaba con que fuese “más bonito” que el resto. Luego vino la revolución de la arquitectura de información y la experiencia de usuario. No bastaba que tu site fuese más bonito: tenía además que lograr que los usuarios entendiesen cómo debían interactuar con él, y que esta interacción fuese lo más “natural” e intuitiva posible. Después llegó la revolución de la relevancia y los contenidos: con el exceso de información y la gran cantidad de sites que hay en el mundo, hemos tenido que luchar por el posicionamiento para captar la atención del usuario y por ofrecerle un contenido relevante.

Gracias a la Gamificación, entramos en una nueva forma de interacción con el usuario: ya sabemos cómo lograr que nos encuentre ante nuestra competencia, sabemos ofrecerle contenidos que le aportan valor, y sabemos mostrarle cómo consumirlo de una forma que le resulte intuitiva y estéticamente atractiva. La siguiente frontera es entender que más allá del valor que pueda aportar nuestro sistema en sí mismo (por su utilidad, contenido, etc) está nuestra capacidad como diseñadores para ofrecer al usuario una experiencia de interacción que responda a aspectos motivacionales: es decir, a aquellas interacciones que el usuario realiza porque realmente quiere hacerlas, porque hacerlas le aporta un valor psicológico intangible, relacionado con el sentimiento de diversión, de logro, de desafío, de superación, de compartición, etc.

Como la Gamificación se basa por tanto en el comportamiento del usuario y en aquello que le motiva, creo que es la disciplina de diseño más profunda, y por eso la considero en la cúspide de esa pirámide imaginaria del diseño de sistemas de información.

Veamos con más profundidad el detalle de este razonamiento .

Evolución del Diseño Visual y Arquitectura de Información

Los que somos un poco más viejunos sabemos que hubo un tiempo (lejano y feliz) en el que se navegaba por Internet en modo texto. Cuando entré en la Facultad de Informática (~~en el año 93~~), en el mítico Centro de Cálculo usábamos terminales que nos permitían acceder a la red usando Lynx. Lynx, que nació en el año 92, era un navegador en modo texto. Los sites, principalmente BBS, se veían por tanto como recopilaciones de contenidos en texto plano y enlaces que se podían seguir.

Lynx, el navegador en modo texto del año 92

Las imágenes por ejemplo, tenían que descargarse como cadenas de caracteres que luego debían volver a codificarse. Eso no impedía que en aquellos incipientes años, la Red fuese un ~~hervidero de porno~~ (o eso me han dicho)

Pero enseguida alguien (concretamente en el National Center for Supercomputing Applications) se dio cuenta de que esto no iba a ninguna parte, y se puso a desarrollar el que se considera primer navegador basado en interfaz gráfica. Se llamaba Mosaic y la versión 1.0 salió al mundo en Noviembre de 1993. Antes de Mosaic hubo algún otro navegador, pero en general se asocia Mosaic como uno de los hitos en la masificación de Internet. Empezamos por tanto con la historia del diseño de sites. Según las estadísticas de Internet Live Stats, en 1995 se considera que había 25.300 sitios web. Como podréis ver a continuación, en aquella época la estética de los sitios era la que era, había que tener en cuenta lo incipiente de los estándares, el peso de las imágenes, la velocidad de conexión por módems, y demás. De cualquier manera, aunque muchos nos hagan creer que se han inventado el concepto de marketing de contenidos, fue en 1996 cuando Bill Gates dijo «Content is King»

Apple en 1997, cortesía de la Máquina del Tiempo de Internet en web.archive.org

Pese a lo rupestre que nos pueda parecer, podemos identificar una cierto diseño en el site: la marca está presente, se separan las secciones, se utiliza un árbol de navegación con diferentes secciones de contenido, elementos destacados de diferente peso, se identifican claramente los enlaces… En la captura de pantalla no se ve, pero hay un footer con secciones de contenidos empresariales, información corporativa, contacto. En definitiva, ya se tiene en cuenta un diseño pensado para ser consumido desde un navegador. Han pasado 17 años y muchos de estos conceptos siguen aplicándose.

Pero Internet sigue creciendo y masificándose. En el año 2000 ya hay más de 17 millones de sitios web. Las empresas tienen que evolucionar, la estética y el diseño pasan a ser elementos diferenciadores del mensaje de una compañía, tanto en offline como en online. La imagen de Apple en el 2000 incluye cambios sustanciales en el diseño visual y en la forma de estructurar los contenidos.

Apple en el año 2000, cortesía de la Máquina del Tiempo en Internet de web.archive.org

Podemos apreciar la transformación del site en el año 98 y 99, muy ligada a la Arquitectura de Información y la Experiencia de Usuario. En general, la evolución de los sitios web está íntimamente ligada a la creación de un cuerpo de conocimiento y maestría en ambas disciplinas. Su ámbito de aplicación está ligado a la ventaja que supone para una organización frente a su competencia la capacidad de que un usuario pueda acceder a la información que desea e interactuar con ella de forma natural e intuitiva. Por resumir discretamente y sin ánimo de ofender a los expertos :

La Arquitectura de Información trata sobre la construcción de estructuras que sean fáciles de entender por parte de los usuarios de un sistema. Es decir, trabaja en el contenido que se consume .
Mientras que la Experiencia de Usuario se centra en las interacciones que realiza el usuario con el sistema para consumir el contenido. Es decir, trabaja en cómo se consume el contenido.

Precisamente en el año 2000 se publica la primera edición de “Don’t make me think”, escrito por Steve Krug, y que 14 años después se sigue considerando un libro de referencia.

En 2005 se lanza el servicio Google Analytics. Desde entonces vivimos obsesionados con la importancia de la medición del tráfico, de las tasas de rebotes, de la conversión de visitantes en clientes, del tiempo de permanencia en las páginas. En 2009 se estima que hay más de 238 millones de sites en el mundo. Llegamos a una época en la que se vuelve precioso el tiempo que pasa un usuario en tu web. Como cada vez se hace más difícil mantener la atención del usuario en un site, la experiencia de usuario evoluciona hacia la simplicidad. Los diseñadores de sitios web se centran en los comportamientos esperados de los visitantes, en qué es aquello esencial para el usuario, que no queremos que se pierda. Se reducen los elementos de interacción, los clicks necesarios, se estandarizan elementos comunes de referencia como mapas de web, buscadores arriba a la derecha, los caminos de regreso con migas de pan, etc.

Apple en 2009, cortesía de la Máquina del Tiempo de Internet en web.archive.org

De un tiempo a esta parte, vivimos en una época dominada por el SEO. Nos guste o no, Google se ha convertido en una herramienta que puede determinar el éxito o el fracaso de un site: no hay vida más allá de la segunda página de Google. Google nos ha enseñado que si algo no aparece en la primera página es que hemos hecho mal la búsqueda. Pero ¿tiene eso sentido cuando resulta que hay más de 990.000.000 webs? Ya hemos aprendido a organizar la información que mostramos al usuario, ya sabemos cómo proporcionarle una experiencia de uso del sistema sencilla e intuitiva. Pero ¿cómo asegurarnos de que los usuarios nos eligen? Surge la necesidad de trabajar permanentemente en cómo Google nos muestra, cómo nos posiciona cuando los usuarios nos buscan, y cómo tenemos que responder a las actividades de nuestra competencia.

Cuando todos aplicamos las mismas técnicas, el resultado tiende a ser el mismo.

Busca las diferencias

Se espera que haya 1 billón de sitios web en Junio de 2014. Todos comparten tendencias en diseño visual, todos saben cómo estructurar la información, cómo ofrecer una interacción intuitiva y cómo hacer que los usuarios les encuentren.

La Pirámide del Diseño centrado en el Usuario

¿Y qué tiene que ver esto con la Gamificación? La Gamificación es una disciplina que se basa en el uso de técnicas de juego en entornos no lúdicos, para conseguir el compromiso de los usuarios con el sistema.

La característica principal de los juegos es la voluntad del jugador, que participa en la experiencia del juego porque haciéndolo se lo pasa bien. Ese “pasarlo bien” es algo relativo, no a todo el mundo le gusta pasarlo bien de la misma forma. En general, se considera que hay una serie de factores que hacen que un juego sea divertido:

Proporciona feedback constante
Permite espacios para el fracaso
Contempla un camino de aprendizaje y maestría, basado en la dificultad para hacer determinadas acciones
Combina pequeñas y frecuentes victorias, con grandes retos que proporcionan sensaciones de victorias épicas
Incluye múltiples tipos de recompensas
Existe una coherencia entre las acciones con sus resultados

Las mítica galería de jugadores de Mr. Toledano

Para que funcione, el motor de un sistema Gamificado busca encontrar los aspectos de motivación de la persona que interactúa con el sistema, frente a la aproximación habitual de diseño basado en las funcionalidades que expone la aplicación. La historia de la evolución de Internet muestra los diferentes ejes sobre los que han ido construyendo los sistemas en la web: la apariencia, la sencillez de uso, la información, la utilidad del servicio proporcionado, la rapidez para la venta, la relevancia, la retención… Todos ello orquestado sobre una serie de requisitos o funcionalidades de un sistema: mostrar información o contenidos multimedia, vender productos y servicios, hacer operaciones financieras, etc.

Sin embargo cuando se construye un sistema Gamificado el eje central es el jugador. Para tener éxito, un sistema Gamificado debe diseñar las experiencias que el jugador quiere vivir porque responden a aspectos psicológicos de motivación. Al fin y al cabo, la Gamificación se centra en la psicología del jugador, debe dar respuesta a sus intereses, a lo que le divierte y le apetece, pero también a lo que puede hacer, o al conocimiento que debe adquirir para poder hacerlo; debe combinar un mecanismo de refuerzo de sus acciones, y también una forma de mostrarle rápidamente el resultado de las mismas. Primero se identifican estos aspectos, y luego se diseña cómo debe ser el sistema.

En resumen, hasta ahora las técnicas de diseño de sistemas de información se centran en la capacidad que tiene un usuario para interactuar con un sistema para obtener unos resultados. Mientras que la Gamificación se centra en los resultados que obtiene un jugador como consecuencia de la interacción con un sistema. De hecho, los propios términos ya dejan entrever esta diferencia. La Experiencia de Usuario se aplica a «personas» y usuarios, mientras que la Gamificación se aplica a jugadores, algo que ya de por sí tiene una connotación relacionada con la psicología y el comportamiento.

Por tanto, si existiera una pirámide que ordenase de mayor a menor la profundidad del conocimiento que se necesita del usuario, y la importancia que se da a sus intereses a la hora de hacer el diseño de un sistema de información, sin duda la Gamificación ocuparía la cúspide.

Atrapados en la Gamificación, entrevista en OndaCRO

Publicado el abril 26, 2014 por carlosguardiola

Boris Quijada y Sandra de Miguel, conductores del programa «Atrapados en las Redes» de OndaCRO, me entrevistaron el pasado 23 de Abril, dentro de su espacio temático sobre Gamificación. OndaCRO (iniciales de Chief Reputation Officer) es una emisora en internet de PR Noticias, cuyo objetivo es proporcionar contenidos relevantes dirigidos a la gestión integral de todo lo relacionado con marca, reputación, relaciones públicas y en general, la comunicación de una empresa. «Atrapados en las Redes» es el primer magazín enteramente social media, 4 horas de contenido 2.0,

Entramos en 3, 2, 1… (Imagen de Elger van der Wel)

A lo largo de 20 minutos tuvimos ocasión de tratar muchos temas, desde la misión de la Asociación Nacional de Gamificación & Marketing Digital (ANAGAM) a la visión de MediaNet Software sobre la Gamificación; nuestros casos de éxito y principales servicios; los riesgos de la Gamificación; lo que nos puede deparar este año, etc.

Si tuviera que resumir los aspectos más destacados de la misma, me quedaría con estos:

ANAGAM está formada por profesionales que nos dedicamos a esto [la Gamificación]; y al tratarse de una asociación lo que intentamos es transmitir el valor, el adoctrinamiento, la cultura y los objetivos. Qué se consigue con la Gamificación, cómo se tiene que hacer, cómo deberían hacerse los proyectos, o cómo deberían planificarse… de una forma independiente.

La Plataforma de Gamificación de BBVA Game (…) es un proyecto que [MediaNet Software] lanzamos en el año 2012 (…) Es un proyecto muy interesante y muy bonito, y ha sido el proyecto con el que nos hemos metido en el mundo de la Gamificación; pero también es un proyecto muy goloso que se está atribuyendo mucha gente. Eso es algo que a mí particularmente me gusta, que mi competencia quiera hacer mis proyectos.

Somos una empresa que nos aplicamos a nosotros mismos lo que vendemos a nuestros clientes: no hablamos desde el desconocimiento, si recomendamos aplicar una serie de tecnologías, o recomendamos aplicar una serie de principios de negocio, es porque a nosotros internamente nos funciona.

[En MediaNet Software] pensamos que los problemas no se resuelven por ser intensivos en mano de obra, y por poner a mucha gente; sino que se resuelven poniendo a gente que sabe lo que está haciendo, por su conocimiento y capacidad.

Están empezando a surgir casos de éxito de empresas muy grandes y también empresas muy pequeñas, que están empezando a descubrir que aplicando técnicas de motivación (que es de lo que va la Gamificación), encontrando lo que a la gente le gusta hacer o lo que le divierte (como competir, como cumplir desafíos, como compararse con sus amigos, como explorar y descubrir cosas…) se consiguen resultados de negocio.

[MediaNet Software] se debe a los compromisos de confidencialidad con sus clientes. Porque muchas veces, nosotros estamos ayudando o liderando la innovación en empresas (…) En ningún caso vamos a ser una empresa que rompa o ponga en peligro el negocio de nuestros clientes.

Mi intervención empieza a partir del minuto 57 al aunque podéis leer a continuación el contenido íntegro de la entrevista (algo editado, todo hay que decirlo)

La necesidad de ANAGAM

Boris Quijada– Como decíamos, vamos a hablar de Gamificación, y una de las últimas entradas que escribía nuestro siguiente invitado se refería al Año que Gamificaron Peligrosamente. Estamos hablando de Carlos Guardiola, Director de Desarrollo de Negocio de MediaNet Software. Carlos, muy buenos días.
Carlos Guardiola– Hola, buenos días, ¿qué tal?
BQ- ¿Tan peligroso ha sido este año de la Gamificación para vosotros?
CG- ¡Ah! No, no, no, para nosotros no ha sido peligroso en absoluto. De hecho, llevamos unos años de Gamificación muy interesantes. Un poco la idea era, retomando esas expectativas que habían generado los analistas de Gartner, Brian Burke (que estará en el Gamification World Congress este finales de Mayo) comentaba que este año, su estimación era que entre el 70 y el 80% de los proyectos de Gamificación pues serían un fracaso; y este sería el año en que se veríamos si esa predicción se cumplía o no se cumplía. Y ese era un poco el propósito de aquel artículo que escribimos.
Sandra de Miguel – Bueno, un artículo que escribiste para ANAGAM, ahora te preguntaremos qué es exactamente esta asociación, y en el que revindicas un poco la independencia de los proyectos de Gamificación, y en este sentido, ¿a qué te refieres?
CG- A ver, lo que nos referíamos, o lo que queríamos transmitir, es que la gente muchas veces tiene una sensación, o se queda con la copla, de que la Gamificación es algo sencillo, algo trivial, que consiste en repartir puntos y medallas. Y que además consiste en conseguir que la gente haga cosas que no quiere, y no se, me da un poco de miedo que se transmita ese mensaje, porque realmente es un tema bastante serio. Estamos hablando al final de motivación, de motivación intrínseca. De gente que quiere hacer cosas porque les aporta un valor. Y si lo que estamos diciendo es que vamos a pagar a gente por hacer cosas, pues eso no es Gamificación, es otra cosa. Hablando con Alfonso Alcántara, el CPO de MediaNet, decíamos que eso es Moneyficación, que es un término que estamos intentando acuñar y que no tiene mucho que ver con la Gamificación.
SM – Bueno, antes de menternos en materia en MediaNet Software, y todos los servicios y los proyectos que realizáis, como decía hace algo más de un mes, un mes aproximadamente, eres miembro de ANAGAM, la Asociación Nacional de Gamificación y Marketing Digital. Cuéntanos un poquito en qué consiste esta asociación y por qué quisiste ser miembro de ella.
CG- Bueno, es una asociación que en España es pionera, por así decirlo, en generar esta cultura de Gamificación independiente; en el sentido de que al final está formada por profesionales que nos dedicamos a esto; y al tratarse de una asociación lo que intentamos es transmitir el valor, el adoctrinamiento, la cultura y los objetivos. Qué se consigue con la Gamificación, cómo se tiene que hacer, cómo deberían hacerse los proyectos, o cómo deberían planificarse… de una forma independiente, que es lo que comentaba. No es una empresa privada la que te dice cómo lo tienes que hacer, sino que es una asociación de personas que estamos trabajando en esto (de manera profesional obviamente), que hablamos desde nuestra experiencia. Si habéis visto un poco los miembros de la asociación, la mayoría de las personas son los que están liderando la cultura de la Gamificación y la implementación de procesos de Gamificación en España. Y ese es el valor que ANAGAM aporta a la sociedad: transmitir una cultura de Gamificación, un conocimiento y un saber hacer a gente que quiere aprovechar una expectativa creada en los últimos años. Que usando la Gamificación se pueden conseguir objetivos de negocio, pero hay que saber cómo, esa es un poco la gracia.

La Trayectoria de Gamificación de MediaNet Software

BQ – En vuestro caso Carlos, desde MediaNet Software habéis desarrollado precisamente un proceso de Gamificación para el BBVA, la plataforma tecnológica de BBVA Game, ¿cómo ha sido este proyecto?
CG- La verdad es que es un proyecto que… tiene una faceta que nos duele mucho. Ayer precisamente estuve hablando en una de las compañías más grandes de Telecomunicaciones de este país, y la gente con la que hablamos se sorprendía de que este proyecto lo hubiéramos hecho nosotros, que lo hubiese hecho MediaNet Software… Porque habían hablado con otra empresa que les habían dicho que lo habían hecho ellos. Es un proyecto que nosotros lanzamos en el año 2012 con BBVA. Fíjate que MediaNet Software trabaja con BBVA desde que eran Argentaria, osea, estamos hablando del año 99 cuando empieza nuestra relación. En el 2012 empezamos a trabajar en la plataforma de Gamificación de BBVA Game. Toda la parte tecnológica, todo el sistema que gestiona las campañas de Gamificación que realizan, pues lo estamos construyendo desde el año 2012. Y es un proyecto muy interesante y muy bonito, y ha sido el proyecto con el que nos hemos metido en el mundo de la Gamificación; pero también es un proyecto muy goloso que se está atribuyendo mucha gente. Eso es algo que a mí particularmente me gusta, que mi competencia quiera hacer mis proyectos, pero también me da un poco de pena que no se reconozca el equipo de trabajo liderado por profesionales de la casa como la copa de un pino que están haciendo un trabajo muy interesante.
SM – Bueno, hablabas que estáis trabajando con ellos desde hace mucho tiempo, porque lleváis desde hace 20 años en este sector y con estos proyectos; desde el punto de vista de la Gamificación ¿cómo han ido cambiando los proyectos que lleváis a cabo?
CG – Pues mira, efectivamente, MediaNet Software nace en el año 95, somos una empresa de tecnología y con Gamificación empezamos a trabajar en 2012. Somos una empresa que nos aplicamos a nosotros mismos lo que vendemos a nuestros clientes: no hablamos desde el desconocimiento, si recomendamos aplicar una serie de tecnologías, o recomendamos aplicar una serie de principios de negocio, es porque a nosotros internamente nos funciona. Tenemos nuestro propio proyecto de gamificación interna, y aunque esperamos hablar de él con más detalle en el congreso de Barcelona, la última iniciativa que hicimos a principios de año fue para comunicar internamente nuestra nueva Web (www.medianetsoftware.com), y para que se instalasen los compañeros nuestras apps de Directorio Corporativo. Nos han dado unos ratios indicadores de éxito impresionantes. Estamos hablando de una media de 12 minutos de permanencia en la web, o de un 180% de visitas desde la empresa. Que dices, «es imposible, el 180% de la plantilla no puede ver la página»; ya bueno es que la ven desde diferentes ubicaciones, que es un poco lo que mide el Google Analytics. O no «puede ser que el 250% de la plantilla haya instalado las apps corporativas”, bueno es que se han instalado en varios dispositivos. Y así es como medimos el éxito. Ahora lo comentaba en el twitter, este mes de Mayo vamos a hacer un proyecto de Gamificación corporativa para redecorar un poco la oficina; que la gente participe, aporte ideas y las vote internamente cómo le gustaría que su espacio de trabajo fuese más agradable. Vamos a hacer otro proyecto de Gamificación interna, que también estamos empezando, para que incentivar que la plantilla, que son principalmente técnicos, completen su perfil. Que a parte de tenerlo en LinkedIn, que también lo tengan en nuestras herramientas internas. Para que cuando formemos un equipo de trabajo, pues podamos tener la gente más adecuada a los desafíos tecnológicos a los que respondemos. Osea, que somos una empresa que Gamifica y somos una empresa Gamificada. Perdonad si me extiendo mucho, como no me decís nada…

«Buscamos Medianos»

BQ- (risas) No, no, te estamos aquí escuchando muy atentos, Carlos. En realidad, todo este universo de Gamificación nos tiene bastante atrapados, sobre todo por ver las aplicaciones que tiene. Te queríamos preguntar, además de la banca, ¿en qué otros sectores trabajáis y Gamificáis?
CG- Pues Gamificar, Gamificar, gamificamos en todos los sectores. Nosotros estamos muy ligados al mundo de la banca, porque son nuestros principales clientes. Pero ahora mismo, por ejemplo, en el mundo del B2C pues también nos movemos mucho. Por ejemplo, tenemos varias iniciativas en marcha que todavía son confidenciales, pero precisamente para hacer user acquisition y hacer campañas de Gamificación para captación de usuarios en empresas que operan en el mundo del B2C. Y ahí nos viene el posicionamiento en el sector porque el CEO de MediaNet, José Luis Vallejo, es una de las 3 personas que fundó BuyVIP. Entiendo que alguna vez habéis comprado en BuyVIP y sabéis que aquello se vendió a Amazon Inc. en el año 2010. Aunque la gente nos identifica con la banca, porque es donde principalmente trabajamos, en el mundo del B2C y en el mundo del eCommerce tenemos una trayectoria muy larga; y a muchas empresas les estamos ayudando a generar campañas de captación y registro de usuarios utilizando Gamificación.
SM- Carlos, vosotros decís en MediaNet que buscáis Medianos y que sois Medianos, ¿a qué os referís con este término y con esta forma de definiros?
CG- Pues fíjate, es que llevamos desde el año 95 y sólo somos 200 personas. Somos una empresa que pensamos que los problemas no se resuelven por ser intensivos en mano de obra, y por poner a mucha gente; sino que se resuelven poniendo a gente que saben lo que están haciendo, por su conocimiento y capacidad. Y como todos somos ingenieros y nos gusta pensar que somos frikies, y nos hemos leído los libros de La Tierra Media, pues sabemos que al final para destruir el Anillo estaban por allí los elfos, los enanos, tal; pero al final los que tuvieron que llevar el Anillo y tirarlo al monte no-se-qué pues fueron los medianos. Que eran los que nadie pensaban que lo harían, los pequeños, que parece que no pintaban nada; pero que ellos fueron los que hicieron la tarea. Y esa es la filosofía que nos gusta. Sabemos que hay empresas que tienen más presencia o mucho más renombre, pero al final los que acabamos sacando los proyectos adelante somos los Medianos. Y ese juego de palabras Medianet-Medianos pues parece que a la gente le gusta y le hace gracia.

¿Qué veremos en 2014?

BQ – Comentabas al principio en relación al artículo que habías escrito Carlos, “El Año que Gamificamos Peligrosamente”, que no se estaban cumpliendo las previsiones que había de cara a este 2014 y que la Gamificación iba a caer, digámoslo así, en desuso. ¿Cómo crees que va a ir evolucionando este término de Gamificación en los próximos años? ¿Crees que las empresas van a ir adquiriendo procesos de Gamificación como estrategia de negocio?
CG- Si analistas internacionales como Forrester, como Gartner, están dando esta relevancia a la Gamificación, es porque la tiene. Hay algunos casos de éxito que ya los recogía un poco, tampoco me quise extender mucho, pero lo que está haciendo Nike con su plataforma de corredores, independientemente de que vaya a dejar de fabricar pulseras, lo que está haciendo Endomondo… Es que Endomondo… a veces se nos olvida que Endomondo es una empresa que fundaron unos amiguetes hace nada, que son muy poquitos pero tienen millones de usuarios, millones de dólares en capital riesgo que han levantado, y millones de kilómetros registrados. Están empezando a surgir casos de éxito de gente, empresas muy grandes y también empresas muy pequeñas, que están empezando a descubrir que aplicando técnicas de motivación (que es de lo que va la Gamificación), encontrando lo que a la gente le gusta hacer o lo que le divierte (como competir, como cumplir desafíos, como compararse con sus amigos, como explorar y descubrir cosas…) se consiguen resultados de negocio. Y eso es lo que mide el Hype Cycle de Gartner: los analistas lo que dicen es que en el punto en el que estamos hay mucha expectación; y habrá gente que le ha ido muy bien y tendrán casos muy sonados, como el de BBVA Game por ejemplo (que es un caso de éxito que tiene premios internacionales), y también habrá gente que fracase porque no sabrá cómo aplicarlo. Estamos en ese ciclo de la adopción tecnológica: hay expectación. Nosotros somos una empresa de tecnología, nuestra aproximación a la Gamificación viene de la tecnología, pero la gente con la que hablamos, tiene interés. Nos están pidiendo muchas propuestas. La gente quiere hacer Gamificación porque cree que es una forma de llegar a sus objetivos de negocio, y estamos en el punto en que lo que habrá que ver es si la gente acierta o falla con sus proyectos. Mi mensaje, tanto como MediaNet como ANAGAM, es que te tienes que dejar aconsejar por la gente que sabe y por la gente que está teniendo éxito, o que está consiguiendo objetivos de negocio. Porque al final, la Gamificación se hace con un objetivo de negocio y te interesa dejarte asesorar por las personas que lo están haciendo. Esto es mucho más complicado de lo que a primera vista puede parecer. Entonces, ¿lo que veremos este año qué será? Pues veremos muchas iniciativas que se lanzan, y veremos algunas que se contarán el año que viene como casos de éxito, y veremos gente que se habrá pegado un batacazo, como pasa en cualquier ciclo de adopción tecnológica. No sé si contesta eso a tu pregunta..
BQ- Sí, sí, lo que está claro Carlos como decías es que hay terreno todavía y que es una oportunidad para las empresas… Y de proyectos como el de la Plataforma de BBVA Game, en cuanto a envergadura, ¿tenéis alguno ya entre manos?
CG- Pues entre manos (risas) tenemos alguno, como te puedes imaginar somos una empresa que se debe a los compromisos de confidencialidad con sus clientes. Porque muchas veces, nosotros estamos ayudando o liderando la innovación en empresas, y como comprenderéis, anticipar lo que están haciendo unos es lo que permite que otros les copien. Entonces, tampoco te puedo dar ahora mismo muchas pistas… Tú fíjate un poco lo que te comentaba al principio con el proyecto de BBVA Game. Hasta Noviembre del año pasado no pude contar oficialmente que esa plataforma la había hecho MediaNet. Con los problemas que tuve, porque había otras empresas que sí que decían que la habían hecho ellos, cuando era mentira. Pero yo me tuve que deber a mis compromisos, y eso es un poco por lo que llevo trabajando en BBVA desde el año 98 o 99. Porque en ningún caso vamos a ser una empresa que rompa o ponga en peligro el negocio de nuestros clientes. Y por eso tenemos muchas iniciativas super interesantes que espero poder contarte el año que viene… Si quieres nos emplazamos a dentro de una año por estas fechas.
BQ- Claro que sí.
CG- De momento te puedo contar las que hago yo internamente; de ellas te puedo hablar abiertamente de los objetivos, y de los resultados; pero las que hago con mis clientes, son confidenciales.
BQ- Bueno, nos quedamos emplazados como decía Carlos para el año que viene. Posiblemente coincidiremos antes, veremos a ver si es en Gamification World Congress que se va a celebrar a finales de Mayo podemos cubrirlo de alguna manera. Bueno, Carlos Guardiola, recuérdanos por favor alguna dirección donde conocer un poco más vuestros trabajos, una dirección de correo o de twitter.
CG- Pues nada, www.medianetsoftware.com es la web oficial de nuestra empresa, y nuestra dirección de twitter es @medianet. Cualquiera que quiera contactar conmigo, a mí me tenéis ahí en el twitter: @carlosguardiola yo prometo que siempre contesto. Otra persona interesante de conocer dentro de MediaNet Software es José Luis Vallejo @jlvallejo que es el CEO, y una persona muy activa dentro del mundo del emprendimiento. El Director de Recursos Humanos de MediaNet Software, Alfonso Alcántara, @yoriento que es una persona de sobra conocido. Todos son gente con la que podéis interactuar si queréis conocer un poco más de nosotros.
BQ- Bueno, pues ya sabéis, algunas direcciones de estos Medianos que llevan dando guerra desde finales de los años 90. Carlos Guardiola, muchísimas gracias.
CG- A vosotros

El Año que Gamificamos Peligrosamente

Publicado el marzo 26, 2014 por carlosguardiola

El Año que Gamificamos Peligrosamente

Desde hace unas semanas soy miembro de ANAGAM, la Asociación Nacional de Gamificación & Marketing Digital. Es normal, MediaNet Software es la empresa que ha desarrollado la plataforma tecnologíca de BBVA Game, uno de los casos de éxito de Gamificación a nivel mundial. Así que después de dos años metido en el mundillo ya iba siendo hora de empezar a compartir todo lo que hemos aprendido.

Los ciclos de las tendencias de mercado están muy estudiados, aunque uno acaba teniendo la sensación de que cada vez son más cortos: el paso de la fase de Hype a la de desencanto es cada vez más rápido. Al final he llegado a la conclusión de que parte del problema es la venta de humo (vaporware) y la generación de expectativas infundadas (cantos de sirena).

Por eso veo fundamental que las empresas se acerquen a la innovación de la mano de profesionales de referencia, con trayectoria contrastada y casos de éxito, y ese es el papel de una asociación profesional como ANAGAM: servir de referencia y punto de encuentro. Y además, hacerlo de manera independiente.

Para ANAGAM he escrito el artículo «El Año que Gamificamos Peligrosamente«, en el que precisamente hago un repaso de aspectos esenciales a tener en cuenta a la hora de que una empresa aborde un proyecto de Gamificación, con independencia de cuáles sean las dinámicas de juego que finalmente se implementen.

Os dejo a continuación el texto completo del artículo.

Jugad, jugad, malditos

En los años 90 todo era más difícil. Para saber si algo era una tendencia en el mundo de los negocios había que esperar a que se publicasen los estudios de Forrester Research o de Gartner Inc. o de IDC, que por lo general tardan meses en hacerse porque se basan en encuestas a decisores y demás, que luego unos analistas muy sesudos se pasaban otros meses revisando y sacando conclusiones, y al final se publicaba un informe que costaba un dineral. Ahora no hace falta: cualquiera con una herramienta de monitorización de hashtags o con Google Trends puede darse cuenta que hay un run-run en el ambiente, una especie de promesa, un Bálsamo de Fierabrás que va a solucionar todos los problemas de las empresas. Y se llama Gamificación.

Precisamente, los adivinos de Gartner dijeron en Noviembre de 2011 que este año, en 2014, más del 70% de las empresas del Global 2000 están trabajando en iniciativas de Gamificación. Recordemos que el Global 2000 es la lista que elabora la revista Forbes. Una empresa que sale en el Global 2000 de 2013 debía tener unas ventas mínimas de 3,89 billones de $ o unos beneficios de más de 230 millones de $. Lo cierto es que las empresas del Global 2000 suman una facturación de más de 38 trillones de dólares. Así que es normal que se genere cierta inquietud, si esa clase de empresas se han lanzado a gamificar sus procesos de negocio es porque la cosa va en serio.

Por ejemplo, Nike. Es una empresa que está en el número 343 de la lista Global 2000. Tiene más de 40.000 empleados, y unas ventas anuales de más de 25 billones de $. El caso Nike+ es un ejemplo claro de gamificación existosa. Nike+ es el resultado de una colaboración entre Nike y Apple; fue lanzada en el año 2006, y se integraba con el iPod. En 2010 salió el App, y se incluía preinstalada de serie en el sistema operativo iOS. A lo largo de diferentes versiones, Nike+ ha ido incorporando mecánicas de gamificación. Con Nike+ es posible definir objetivos de entrenamiento, recibir feedback, contrastar tu evolución a lo largo del tiempo, interactuar con amigos y otros corredores, etc. En Agosto de 2013 se estimaba que había más de 18 millones de usuarios registrados en Nike+. Por eso no es de extrañar que haya surgido un ecosistema de wearables en torno a Nike+ (FuelBand, SportWatch…) Y que los analistas de negocio estimen que sólo en 2011, las ventas de artículos de la categoría Running de Nike subieron un 30% (telita)

Es normal, dirás. Es Nike. Es una empresa del Global 2000. Su tagline es «Just Do It»: estaban condenados a lograrlo. Bueno. Endomondo es una empresa de 20 empleados, que se fundó en 2007, con un producto parecido. Con una mayor oferta de deportes, en Octubre de 2013 Endomondo tenía más de 20 millones de usuarios registrados, más de 1 billón de millas recorridas y en 2011 recibió 2,3 millones de dólares de VC

Parches, medallas y pines siempre han servido para demostrar intereses comunes, pertenencia, estatus o desafíos superados (Imagen de jjay69)

Starbucks (Global 2000 número 605), Coca Cola (número 79), SAP (la 211), Accenture (la 318).. todas estas empresas han publicado casos de éxito de sus iniciativas de Gamificación. Hasta en España, como el caso de BBVA (número 91 del Global 2000) ¿Que los visitantes a tu web no se registran? Gamificación. ¿Que tus clientes no compran? Gamificación. ¿Que quieres potenciar el canal online? Gamificación. ¿Que tu call center no presta la atención que tus clientes merecen? Gamificación. Como dirían en el 1,2,3 «Aquí hemos venido a jugar«

Pues no.

Los peligros de la Gamificación

Un año después de enseñarnos las visiones de la Tierra Prometida del negocio de la Gamificación, los adivinos de Gartner hicieron una pequeña revisión de su predicciones. En 2012 afirmaban que este año, en 2014, el 80% de los proyectos de Gamificación estaráncondenados al fracaso. ¿Y qué más da lo que diga la gente de Gartner o de Forrester?, te preguntarás. Pues hombre, dar, no da lo mismo. Al fin y al cabo, un informe de un analista independiente es un arma terrible. Permite justificar cualquier necesidad de presupuesto, y lavarse las manos en cualquier fracaso («Eh, Gartner dijo que tal herramienta estaba en el Cuadrante Mágico arriba a la derecha» o «Eh, Gartner dijo que este año el CTO tenía que ahorrar llevando aplicaciones a la nube»). Además, un informe de un analista alimenta todo tipo de artículos en la prensa especializada. Que a su vez llevan a columnas de opinión de los gurús de la tribu. De las que acaban haciéndose eco en la prensa generalista. Y se convierten en cientos de miles de tweets, post en Facebook, artículos en LinkedIn…

Los puntos ayudan a saber qué tal lo estamos haciendo, miden el progreso del jugador y permiten mantener marcadores (Imagen de CraigOppy)

Lo cierto es que todos estamos rodeados de aplicaciones que nos gamifican. Seamos o no «jugadores», quién más quién menos está familiarizado con los elementos externos de la Gamificación. Tenemos una tarjeta con la que acumulamos puntos cuando viajamos, y los puntos los podemos canjear por descuentos. O pasamos una tarjeta cuando pagamos en una cafetería, y sabemos que hasta que no acumulamos determinados puntos, la tarjeta no sube de nivel y se convierte en Oro. O hemos recibido invitaciones exclusivas con las que podemos invitar a que nuestros amigos se registren en un site de ventas privadas. Vemos que los puntos, las medallas y los rankings son elementos que nos resultan conocidos, que suelen formar parte de los sistemas de Gamificación que habitualmente se usan como ejemplo, y tendemos a reducir toda la solución a eso. ¿Que los visitantes a tu web no se registran? Dales algunas medallas que poner en su perfil y unos cuantos puntos por página que visitan y en dos meses estás conviertiendo al 15%. Si alguien te dice eso, huye.

De hecho, piensa en una aplicación que haya nacido con la Gamificación por bandera. Piensa en Foursquare. Con todas esas badges tan coloridas. Y todos los Majors que pululan por ahí. Y toda la gente haciendo checkins. Foursquare ha sido muchos años un ejemplo de Gamificación exitosa citado por analistas, opinólogos y profesores, hasta que el CEO de Foursquare, Dennis Crowley en persona, salió y dijo que en realidad estaba resultando un fracaso para su negocio. Porque los usuarios habían interpretado que Foursquare iba de hacer checkins, convertirse en Major y acumular medallas, y casualmente ese no era el objetivo de negocio de la empresa. Que precisamente esas mecánicas habían liquidado por completo el modo con el que Foursquare esperaba hacerdinero, que era conocer los interesesreales de sus usuarios para que locales, comercios y anunciantes pagasen por datos de calidad y segmentados. Y que los usuarios pudieran descubrir nuevos lugares de interés en lugar de quedarse siempre en el mismo para ser el Major.

¿Cómo fracasar en tu proyecto de Gamificación?

En general, fracasar en un proyecto de Gamificación es igual de fácil que fracasar en cualquier otro tipo de proyecto. Para ~~cagarla~~, sólo tienes que seguir algunas reglas básicas:

Olvídate de tus objetivos de negocio. «Lo importante es que esto sea colorido y la gente se divierta. ¿Para qué definir cómo esperas que impacte el proyecto en los objetivos de tu empresa o departamento? Si haces un proyecto de Gamificación los usuarios vendrán como la miel, tus empleados trabajarán felices, todo el mundo se divertirá y cuando la gente se divierte, las cosas funcionan por sí mismas.» La realidad es que como cualquier inversión empresarial, tu proyecto se hace con un motivo que puede traducirse en términos tan poco abstractos como «aumento de ventas», «reducción de costes», «incremento de usuarios registrados», «reducción de plazos de entrega», «notoriedad de la marca» y demás. Es más: si trabajas en una empresa privada y tienes un presupuesto a tu cargo seguro que ya estás acostumbrado a explicar el ROI de tu proyecto.

No definas métricas, ni tengas claro cómo medirlas. «Reconócelo: medir es aburrido. Es para los contables. Definir indicadores que te permitan relacionar cómo impacta el desarrollo del sistema en tus objetivos de negocio es algo inherentemente girs. Ni que estuviésemos montando un ERP. Si la gente se divierte y juega es señal de que las cosas funcionan, y si las cosas funcionan esto acabará por tener sentido.» Por desgracia hace más de 60 años que escuchamos el mantra de que hay que medir para sacar conclusiones y poder mejorar. No tiene sentido definir unos objetivos para un sistema si no tienes claro cómo vas a comprobar si los estás o no consiguiendo. Así que define unas métricas, y asegura que el sistema va a recolectar los datos inequívocos que te permitirán calcular tus indicadores. Por ejemplo, si crees que un proyecto de Gamificación va a permitirte reducir el coste de adquisición de usuarios (CAC), necesitas poder calcular cuánto te cuesta cada usuario que entra a través de la campaña.

No adaptes tu sistema a los resultados de las métricas. «Puede que hayas definido cómo esperas que el sistema gamificado impacte en tus objetivos de negocio. Puede que tengas un puñado de métricas y te hayas asegurado que el sistema obtiene los datos que necesitas para calcularlas. Pero lo que no tiene sentido es andar rehaciendo esto cada dos por tres para ajustar aquello que no funciona, menuda pérdida de tiempo.» Nada más lejos de la realidad. ¿Recordáis que Foursquare había decido dar un giro a cómo aplicaba la Gamificación a su negocio? Pues entre Diciembre de 2013 y Febrero de 2014 ha recibido 40 millones de $ de VC, incluyendo 15 millones de Microsoft.

Los niveles son una forma de medir la progresión del jugador, y hacer que mantenga su compromiso a través de la evolución del juego (Imagen de Khem)

Sin embargo, tener claros los tres puntos anteriores son condición necesaria pero no suficiente. Recordemos que la Gamificación consiste en aplicar técnicas de juego en ambientes no lúdicos para potenciar el compromiso de los usuarios. Es posible que un proyecto perfectamente definido desde un punto de vista de negocio falle a la hora de implementar los aspectos relacionados con el juego:

Tiraniza a tus usuarios. «Gamificar es conseguir que las personas se diviertan haciendo tareas rutinarias y aburridas que no les aportan valor». Bueno, eso lo que es es un milagro. Si eres consciente de que esas tareas rutinarias y aburridas no aportan valor a las personas ¿te has planteado que quizá el problema no sean las personas sino las tareas?

Convierte el juego en el negocio. «El juego es un fin en sí mismo». Recuerda que el juego no es un fin, es el medio con el que conseguir unos objetivos de negocio. Adquisición de clientes, por ejemplo. Si tu juego no está consiguiendo usuarios registrados, puede que tus jugadores se lo estén pasando muy bien y vivan experiencias memorables pero no estás consiguiendo usuarios registrados.

Mete a tus jugadores en la Thermomix. «A todo el mundo le gusta ser el número 1″. En realidad no, en realidad cada persona tiene formas difererentes de comportarse, y de encontrar los motivos por los que realiza las actividades que realiza. Cualquier sistema dirigido a personas (ya sea una nueva serie de televisión o una app para el móvil) requiere un estudio de su audiencia. ¿A quién se dirige tu juego? Conoce a tus usuarios, sus motivaciones y cómo les aportas valor a la hora de diseñar tus dinámicas de Gamificación.

Improvisa con las recompensas. «Cuando el juego no avanza, siempre podemos crear otra chapa». Convertir tu sistema en una máquina de incentivos y recompensas es un riesgo. Significa que los jugadores sólo están encontrando la motivación para implicarse en él por factores externos (hago esto porque me dan aquello). Pero bueno, en un determinado contexto es posible que puedas correr ese riesgo. Eso no quita para que si estructuras un sistema en torno a recompensas, tienes que definir claramente el valor que aportan a los jugadores. Y ese valor puede ser intangible, pero también tangible. El equilibrio entre ambos es delicado, y jugar a la improvisación pueder terminar por hundir tu sistema.

Abandona a tus jugadores. «Si se van, que se vayan, que ya volverán». No es cierto. Una de las mayores preocupaciones de los que nos dedicamos a los negocios digitales es la facilidad con la que las personas se caen por el camino del túnel de compra. Arquitecturas de información difíciles de entender, navegación confusa, costes ocultos, todo eso acaba por hacer que una oportunidad de venta se convierta en un carrito abandonado. Con tu proyecto de Gamificación pasa exactamente lo mismo, aunque en otro nivel. No lo vas a llamar conversión, lo vas a llamar compromiso; pero el concepto es el mismo. Requiere que pienses en cómo vas a conseguir que los jugadores participen, y cómo vas a reaccionar si no lo hacen.

Clasificar a los jugadores en un ranking permite que puedan comparar su progreso con el de otros, conocidos o no (Imagen de archangel 12)

El Año que Gamificamos Peligrosamente

Sin embargo, entre todos los aspectos que pueden poner en entredicho tu iniciativa de Gamificación, yo destacaría dos. Por un lado, la incapacidad de definir el Retorno de la Inversión: básicamente, no saber para qué se está haciendo el proyecto, ni el impacto en el negocio que va a tener. Garantía de fracaso total. Y por otra parte, no ser capaz de hacer el diseño del juego adecuado.

Desde mi punto de vista, el éxito de un proyecto de Gamificación pasa por lograr los objetivos de negocio porque los jugadores participan en dinámicas que les aportan un valor en sí mismas, y utilizar factores de motivación externa para mantener su compromiso con el juego.

Por eso es clave involucrar en el proyecto personas que puedan conjugar ambos mundos: expertos en el negocio y expertos en el diseño de dinámicas de Gamificación. Aunque parece una trivialidad, por desgracia para el 80% de las empresas 2014 será El Año que Gamificamos Peligrosamente.

Desde Android se compra más

Publicado el mayo 2, 2013 por carlosguardiola

Hay muchas formas de orientar el lanzamiento del canal móvil de tu e-commerce; en general, depende de lo que busques: captación de usuarios, dirigir tráfico a tu web, proporcionar información y datos de ayuda a la toma de decisión.. Pero si lo que quieres es crear un nuevo canal de venta, no lo dudes, empieza pensando en adaptar tu App al público de Android.

Cada plataforma móvil tiene sus propias recomendaciones de usabilidad, arquitectura de información y diseño, es algo a lo que los usuarios están acostumbrados y condicionados por los fabricantes, por tanto, mi recomendación es siempre proporcionar la experiencia de uso que los clientes esperan de su plataforma.

Así que a la hora de elegir, si sólo pudieras hacer un App para el canal de venta en una plataforma, esa plataforma es Android.

Está claro: según comScore, el 20,8% de los usuarios de Apple compran algo desde el móvil una vez al mes; considerando este «algo» desde ropa a entradas, pero excluyendo las compras en el marketplace (osea, las IAP) En Android, ese porcentaje es menos de la mitad; es el 9,4%.

Are ther any questions before we proceed? (Foto de Sveden)

Exacto. ¿Qué hay detrás de esos porcentajes? Hay que poner esos números en valor, y por tanto, buscar los datos de penetración de iOS y Android en España y ver qué hay detrás de ese dato.

comScore también nos dice que en España había en Noviembre de 2012 22,6 millones de smartphones, supongamos que esa cifra se ha mantenido constante. No lo es, porque habrá crecido, pero no he encontrado un dato más reciente 🙂 Gracias a Kantar WorldPanel sabemos que más del 90% de los teléfonos que se vendieron entre Diciembre y Febrero de 2013 eran Android; ese dato nos da una idea de la tendencia, pero necesitamos hacernos una idea de la base instalada.

Para ello vamos a consultar las estadísticas de StatCounter, comprobamos que el 70,17% de los terminales son Android (tendencia ascendente) frente a un 24,86% que son iOS (tendencia descendente). Llevando la proporción, hay 15.858.420 terminales Android y 5.618.360 terminales iOS.

Los romanos no inventaron el móvil porque con el ábaco no podían hacer estos cálculos (Foto de Wikipedia)

Que el 20,8% de los terminales iOS hayan hecho alguna compra por Internet el último mes, nos da un total de 1.168.618 personas; mientras que el 9,4% de terminales Android supone 1.490.691 personas.

Como decía, este dato parte de un número de terminales de Noviembre de 2012; 6 meses más tarde la tendencia es que el 90% de los terminales que se venden en España son Android, así que la diferencia será mayor.

Otra cosa son los datos de compras desde las Apps usando In-App Purchases. Ahí los datos son diferentes, pero eso será otro post.

Frankenstein, o el Nuevo Monolito

¿Qué hace aquí este Monolito?

Cosas malas que pasan cuando tienes un Monolito

¿Entonces?

Cuéntaselo a otros

Me gusta esto:

Introducción

Capítulo 1. ¿Qué es un eCommerce Top 100 y por qué hay que hacerlo a medida?

eCommerce Singulares según Sngular

El eCommerce Singular siempre hay que hacerlo a medida

Cuéntaselo a otros

Me gusta esto:

Las empresas tienen que innovar para sobrevivir

Operaciones vs Innovación ¡FIGHT!

Las empresas son para el verano

Cuéntaselo a otros

Me gusta esto:

1. El restaurante mejor valorado que no existía

2. No te libras de tu cuñao ni en Amazon

3. Nadie clickea en tus banners

4. Arañas contra Bots

PS. Bot Data

PPS. Los bots de LinkedIn

Cuéntaselo a otros

Me gusta esto:

The Song remains the same

Communication Break Down

Babe, I’m gonna leave you

Good Times, Bad Times

Kashmir

Whola Lotta Love

Stairway to Heaven

Cuéntaselo a otros

Me gusta esto:

La Cúspide del Diseño centrado en el Usuario

Evolución del Diseño Visual y Arquitectura de Información

La Pirámide del Diseño centrado en el Usuario

Cuéntaselo a otros

Me gusta esto:

La necesidad de ANAGAM

La Trayectoria de Gamificación de MediaNet Software

«Buscamos Medianos»

¿Qué veremos en 2014?

Cuéntaselo a otros

Me gusta esto:

El Año que Gamificamos Peligrosamente

Jugad, jugad, malditos

Los peligros de la Gamificación

¿Cómo fracasar en tu proyecto de Gamificación?

El Año que Gamificamos Peligrosamente

Cuéntaselo a otros

Me gusta esto:

Cuéntaselo a otros

Me gusta esto: