Si solo siguiéramos las reglas de Facebook, tal vez nos perdamos algunas cosas en el camino, y varios desarrolladores de aplicaciones para Facebook vimos una oportunidad en éste botón.

Facebook lanzó los perfiles para las aplicaciones hace ya varios meses, lo cual básicamente significa que la gente puede volverse fan de tu aplicación. Anteriormente a ésto había solo Fan Pages, y uno debía crear una fan page antes de lanzar una nueva aplicación para poder utilizar el page id que permitía poner el botón de Fan dentro de la aplicación. Todo éste asunto de conseguir fans en las páginas creció muy rápido, y al día de hoy incluso hay compañías que se especializan solo en conseguir mas fans en las pages.

Pero, ¿Porqué es tan importante éste pequeño botón? Para comenzar, una de las primeras cosas con las que tuve que lidiar desde que me involucré con las aplicaciones de Facebook fue “Cómo Generar Engagement”, como mantener a la gente comprometida con la aplicación. Algunas aplicaciones tienen su belleza natural porque son muy divertidas, porque fueron pensadas para que el usuario vuelva a usarlas regularmente, y porque con la cantidad de contenido logran de alguna manera enamorar al usuario, pero hay otras aplicaciones que no tienen esa belleza natural, y sus desarrolladores han de vivir con el hecho de que los usuarios siempre se aburren de todas las aplicaciones, mas tarde o mas temprano, pero lo harán y uno debe pelear contra ello.

En Altodot hemos tenido el placer de desarrollar la aplicación de Facebook para los MTV Awards de Latinoamérica y, como confirmación a éste post, algunas semanas atrás mientras estudiábamos algunas métricas encontramos que a la Fan Page de MTVLA le tomó mas de 5 meses ganar 60.000 Fans (Aún cuando posteaban regularmente noticias, eventos y notas relacionadas en la misma), pero también descubrimos que luego de que lanzáramos la aplicación, en tan solo 4 semanas incrementamos dicho número a 100.000, lo cual significa que tener un Fan Button en tus apps se ha convertido en un deber.

Pero… una vez que tenemos los fans en la page de tu app, qué podemos hacer con ellos?

Para comenzar, cada vez que posteas algo en el profile de tu app eso aparece en el Live Stream de cada uno de tus fans, lo cual se convierte en un poderoso canal de comunicación para presentar nuevas mejoras, nuevos features, correcciones a bugs, estadísticas, e incluso nuevas aplicaciones que lanzás, y créanme, es un concepto probado. Nosotros empujamos una nueva aplicación desde una Fan Page con 1000 fans, y la nueva app consiguió 300.000 usuarios en solo un día. 1000 fans pueden generar por lo menos 10.000instalaciones, lo cual desde mi perspectiva es la cantidad mínima de personas para que una aplicación se vuelva viral (sin importar cuantos canales virales hayas utilizado en tu aplicación).

Dicho ésto, quiero compartir con ustedes algunas buenas prácticas que he usado y visto por ahí sobre cómo colocar un botón de fan en tu aplicación, que sin duda tendrá un gran impacto en la cantidad de fans que conseguirás. Podrán encontrar éstas prácticas en muchas aplicaciones por ahí…

La forma mas fácil es agregar un link hacia el profile de la aplicación, por ejemplo:

<a href=“http://www.facebook.com/apps/application.php?id=YOUR_APP_ID“ target=“_blank”>Hazte Fan</a>

Pero recuerden agregar el atributo target=”_blank” a la etiqueta anchor para permitirle al usuario seguir viendo la app.

La segunda opción es agregar un pequeño iframe de 20 píxeles de alto y 112 de ancho que solo contendrá las librerías de Facebook Connect (Correctamente inicializadas), y el tag de XFBML “fb:fan” que es lo que genera el Fan Button. En nuestro ejemplo hemos removido algunos elementos que genera el tag, como el nombre de la app y la imagen para que quede solo el botón y no rompa con el diseño de nuestra app (ésto se hace mediante hacer override de las clases de estilos .name_block and .profileimage como se muestra en el ejemplo).

Por lo tanto, si estas trabajando en una aplicación en FBML entonces debes agregar un tag fb:iframe como se indica a continuación:

<fb:iframe

frameborder=“0″

scrolling=“no”

width=“113″

height=“25″

src=“http://yourcallbackurl/iframe.html“>

</fb:iframe>

Nota: Si estás trabajando en una aplicación en un iframe, puedes poner directamente el control dentro del código, siempre y cuando agregues las librerías de facebook y las inicialices apropiadamente).

Ahora, éste es el código que se necesita dentro del Iframe (en el caso del fbml), o dentro de la página en caso de que ya estés trabajando dentro de un Iframe:

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd“>

<html>

<head>

<meta http-equiv=“Content-Type” content=“text/html; charset=UTF-8″>

<title>Los MTV Awards 2009</title>

<style type=“text/css”>

body {

margin:0px;

padding:0px;

}

.profileimage {

display: none !important;

}

.name_block {

display: none !important;

}

div {

margin: 0px !important;

padding: 0px !important;

}

</style>

</head>

<body >

<script type=“text/javascript” src=“http://static.ak.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php“>

</script>

<div style=“width:113px;”>

<div style=“float: left;”>

<fb:fan profile_id=“189458570399″ stream=“0″ connections=“0″ width=“113″ ></fb:fan>

</div>

</div>

<script type=“text/javascript”>

FB.init(“yourapikey”);

</script>

</body>

</html>

Algunas otras aplicaciones, especialmente aquellas que están basadas en Flash, usualmente colocan el boton de fan dentro de un div escondido (flotando en el centro de la pantalla), y desde flash llaman a alguna función Javascript para mostrarlo cuando el usuario clickea en algún botón dentro de la animación Flash. En el próximo post veremos como manejar la comunicación entre Flash y Javascript.

Los entornos de testeo en las compañías de tecnología son diseñados para hacer la programación mas segura y rápida, pero los mismos también nos permiten correr tests para checkear la infraestructura de una app y a descubrir posibles problemas de escalabilidad que no pueden ser testeados en servidores de producción, o podríamos poner dichos servidores en riesgo de caerse cuando gente real esté usando la aplicación.

En casi todas las aplicaciones, usualmente tomamos información de los perfiles de los usuarios lo cual claramente debe ser hecho bajo una sesión activa. Ésta es la razón básica por la cual no podemos usar un entorno de testeo al desarrollar para Facebook, no podemos pasar sobre facebook porque necesitamos al usuario logueado para conseguir esa sesión lo cual vuelve imposible por ejemplo correr un apache benchmark para testear tiempos de respuesta, tiempo de latencia, etc…

Ni hablar del tiempo que toma para cargar todas las librerías de Facebook cada vez que necesitamos refrescar una app corriendo en Facebook. Cada vez que cambiamos una pequeña parte del código todo el site se cargaría nuevamente y eso tomaría otros 15 segundos de nuestro precioso tiempo, cada vez que apretamos F5! (los 15 segundos salen de el tiempo de carga de FB mas el tiempo de parsing del fbml, y render del html, podría ser aun mas y generalmente no toma menos de 8 a 10 segundos).

Así que, luego de haber estado trabajando con desarrollo de apps para Facebook durante un largo rato quiero compartirles algunas cosas que aprendí en el proceso que quizás puedan ayudarlos a ahorrar algo de tiempo, y algunos dolores de cabeza también.

1. No realices pequeños tests, en cambio, dedica mas tiempo a desarrollar sin testear online el resultado constantemente, programa todo lo que puedas y cuando sientas que estas listo para probar, hazlo. Vas a descubrir que en ocasiones podes programar un montón sin un solo error en el camino. Si haces pruebas cada un minuto, en 1 hora habrás perdido 15 minutos.
2. Si estas desarrollando una página en FBML, una de las tentaciones que automáticamente surge es la idea de desarrollar un html aparte y luego convertirlo en fbml quitando los headers, etc. SIEMPRE hay algunas pequeñas diferencias entre una página en fbml y un html standard que usualmente toman mucho tiempo en ser resueltas, (esto es producto de los distintos doctypes y estilos que facebook hace override por default). Por lo cual, si vas a armar una página en fbml, escribí el código directamente en fbml y probalo directamente en Facebook.
3. Si tu aplicación esta live (en producción), trabajá en una app secundaria (Sin importar que facebook diga que no lo hagas…). Tests a la ligera, o falta de test representa largo debugging, y muchos clientes o usuarios finalmente podrían quejarse si los bugs aparecen. No importa cuan pequeña parezca la tarea, probala tranquilamente en una app de pruebas y luego subila a producción una vez que confíes en lo que acabas de codear.
4. Construye una wiki o algo similar que contenga todos los “well known issues” (errores mas conocidos) que encuentres mientras programas tus apps. Nunca sabes cuando o quién volverá a dar con el mismo problema, tener una base de conocimiento es clave para la productividad de un team!
5. Genera código reusable. Yo desarrollé aplicaciones enteras arrojando feeds, notificaciones, con fbjs, fbml, ajax, servicios web, etc. en solo uno o dos días…. Construye todo orientado a objetos, declarando todo en scopes grandes sin hacer que solo satisfaga la necesidad de ese cliente.

Éste tipo de prácticas que llevamos adelante en Altodot probablemente te harán ahorrar algo de tiempo, y como el tiempo es dinero, estoy segurao que probarás algunos de éstos puntos .

Espero que se haya entendido ! Y sino, pregunten

A partir de distintas conversaciones con gente de agencias y marcas, y tras ver que Facebook muy pronto va a estar dando datos más detallados sobre la interacción de los usuarios en las Fan Pages (ver artículo), surgió la idea de escribir este post para que se entiendan mejor algunos “números”  involucrados en una acción de Marketing en Facebook. En este primer post la idea es repasar los números más básicos que un profesional del marketing debería entender a la hora de evaluar la performance de una campaña.

Fans: el número de FANS (o SEGUIDORES) que tiene una página en Facebook, es la cantidad de personas que hicieron “click” en el boton “Hacerme FAN” vinculado a esa página. Este botón no solo esta en la página misma, sino que tambien se puede embeber en cualquier aplicación de facebook, e incluso en un sitio web externo mediante un widget (y recientemente incluso en los anuncios internos que uno puede pautar en Facebook).

¿Para qué sirve tener FANS? Además de que esta bueno que mucha gente de alguna forma “siga” a nuestra marca o producto, lo interesante en la práctica es que los Fans reciben en su newsfeed, todos los posts que realizamos en el Wall de la Fan Page. Esto nos permite tener un canal de comunicación abierto, y con “permiso” de la persona. Es una suerte de OPT IN hacia el newsfeed de los usuarios.

Pregunta: ¿Facebook me permite mandarle un mensaje directo a todos mis fans?

Respuesta: No, Facebook no permite esto (no hay forma técnicamente de hacerlo). Facebook solo brinda esta posibilidad en los GRUPOS menores a 5.000 personas.

Usuarios Activos Mensuales (en una aplicación): este número es la cantidad de personas que accedieron a la aplicación en los ultimos 30 días. (Este es el número que se muestra a la izquierda en la Fan Page asociada a una aplicación.

Importante: La cantidad TOTAL de usuarios que instalaron la aplicación, no es el número que se ve en el margen izquierdo de la aplicación, sino que es un número que sólo esta disponible para el administrador/developer de la aplicación (Facebook brinda bastantes métricas sobre las aplicaciones, estas están disponibles solo para los administradores de la aplicación. Se puede acceder en www.facebook.com/developers/). Por lo general el número de usuarios que instalaron la aplicación es bastante mayor al número de usuarios activos.

Pregunta: ¿Sirve para algo un usuario que no es activo?   Respuesta: ver siguiente pregunta.

Pregunta: Si ya termino mi campaña, ¿para qué me sirve mantener la aplicación?

Respuesta: Es importante mantener el “Canvas” de la aplicación activo, para volver a utilizarlo cuando se haga otra campaña, ya que los usuarios se instalan un “Canvas” en realidad, no una “Aplicación”. Osea… si en la misma URL donde habia una app antes, instalo una nueva, ya tendré todos los usuarios que se instalaron la App para comenzar a viralizar la aplicación. ¿Porque? Porque Facebook SI nos permite enviarle mensajes o notificaciones a los usuarios que instalaron nuestra aplicación anteriormente, sean estos usuarios activos o no hoy en día (esto se hace programando, no hay una interfaz para hacerlo desde el sitio propiamente dicho).

Bueno, básicamente el objetivo del post es ayudar a entender 3 números muy importantes: FANS (o SEGUIDORES), Ususarios Activos Mensuales, y Cantidad de Usuarios que Instalaron la Aplicación.

Espero que se haya entendido ! Y sino, pregunten

Algunos días atrás comenzamos a recibir un error del estilo “The URL … did not respond.” en algunas aplicaciones que estábamos desarrollando en simultaneo. Pensamos que podría ser causado por un problema en el servidor y no prestamos mucha atención, pero ayer comenzó a suceder todo el tiempo, y no había manera de encontrar un patrón que causara ésto.

Así que dedicamos algunas horas con Atha Kouroussis, nuestro partner de hosting en Altodot ( CTO y Co-Founder de Vurbia Technologies) analizando qué estaba pasando realmente, si era un problema de servidores, de código defectuoso, o si era un problema de la plataforma, y finalmente encontramos una manera de solucionar este eterno error arrojado por Facebook.

Una de las cosas que encontramos fue que aquellas aplicaciones que estaban embebidas en un IFRAME para correr dentro de Facebook estaban funcionando algo lentas, pero sin fallar en términos generales. Por lo tanto nos enfocamos en resolver por qué  una aplicación en FBML falla cuando una en IFRAME no falla.

Para confirmar el post publicado por el blog “Inside Facebook” anunciando algunos problemas con la latencia de la API de Facebook, cuando comenzamos a debuggear la aplicación vimos que el tiempo de ejecución de las consultas de FQL era muy distinto cada vez, generalmente tardaba entre desde menos de un segundo hasta 3 segundos, pero de repente la misma consulta tomaba hasta 10 o 20 segundos en ejecutarse.

Otro error que observamos fue que muchos de estos requests estaban devolviendo resultados vacíos cuando se suponía que devolvieran cierta información. Lo interesante aquí es que ésto no tenía nada que ver con el tipo de consulta que se estaba corriendo, o la cantidad de registros que esta devolvía.

Eso solo explicaba por qué estaba tomando tanto tiempo para ejecutar las aplicaciones que corrían dentro de iframes, pero porqué las aplicaciónes en FBML fallaban de esa manera?… Dimos una mirada en profundidad al tiempo que tomaba en ejecutar las consultas de FQL, y encontramos que cuando toda la ejecución del código de nuestra aplicación era menor a 12 segundos, entonces la aplicación en fbml no fallaba, pero si el tiempo de respuesta de cada consulta de FQL (mas el tiempo que tomaba la ejecución de dicho script) era mayor a 12 segundos, fallaba nuevamente.

Lo interesante aquí es que aun cuando Facebook arrojaba el error “URL did not respond” la ejecución del script no mostraba ninguna excepción y los logs del servidor mostraban una entrega sin problemas, en vez de frenarse la ejecución siempre finalizaba correctamente!! sin importar cuanto tiempo tardara la API de Facebook en responder a los requests.

Hasta ese momento solo teníamos el diagnóstico, la demora de las respuestas de la plataforma de Facebook era muy grande, específicamente mas de 12 segundos lo cual es el límite de tiempo por el cual Facebook esperará por el output del script antes de comenzar a parsear los tags de FBML en el código fuente.

Aun cuando claramente no era nuestra culpa, no había explicación alguna que dejara a nuestros clientes contentos o que los hiciera sentir seguros (principalmente cuando somos una compañia especializada en aplicaciones sociales), así que hicimos un brainstorming durante unas horas buscando un workaround.

Nos dimos cuenta que necesitabamos hacer una redirección a la misma página si la ejecución del script tomaba mas de 10 segundos en correr, pero dado que nuestra aplicación estaba hecha en php no podíamos checkear que el tiempo que tomara cada consulta fuera menos de 12 segundos, porque solo una consulta podría tomar hasta 20 segundos y facebook hubiera mostrado el error antes que nosotros pudieramos redirijir la página

La lista de las posibles soluciones (luego de intentar todo lo que encontramos en los foros de desarrolladores de Facebook) era muy corta, solo habían 3 ideas:

1. Rezar porque Facebook tomara cartas en el asunto de su latencia en la respuesta, o porque aumentara el tiempo de espera del output de nuestros servidores
2. Cambiar todo el código de nuestra aplicación para que corra dentro de un iframe reemplazando todo el código FBML y FBJS (obviamente esto sería lo último que hubieramos hecho)
3. Paralelizar las consultas de FQL a la API.

Finalmente, la forma en la que resolvimos el problema fue simulando php threading a travez de hacer llamadas mediante CURL a un archivo de procesos que se ocupa de realizar las consultas de FQL hacia Facebook, y mientras que todas las consultas son realizadas por múltiples llamados simultáneos a travez de CURL, en el script principal nos mantenemos loopeando y revisando que el tiempo de ejecución de todas las queries sea menor a 10 segundos.

Si ese es el caso, nosotros solo dejamos al script terminar su ejecución, pero si facebook demoraba al menos una de las consultas por mas de 10 segundos automaticamente redireccionamos la pagina a si misma pasando los mismos parametros por url nuevamente. De esa manera (y por que Facebook usualmente no fallaba dos veces consecutivamente) solo tomaría entre 5 y 15 segundos en entregar el contenido de la aplicación (no los 35 segundos que podía llegar a tomar en el caso de las aplicaciones con iframes en el caso de que facebook demorara 20 segundos una respuesta).

Dicho ésto, dejenme compartir con ustedes un ejemplo de código PHP funcionando (comentado) similar a lo que usamos en nuestra aplicación para evitar dicho error, el cual pueden descargar aquí. Siéntanse libres de realizar cualquier consulta o aclaración al respecto y con gusto les responderé.

No solo la gran mayoría de las 350.000 aplicaciones lanzadas en los últimos 2 años dejará de funcionar, sino que también los desarrolladores de dichas aplicaciones ahora tendrán que aprender como reemplazar las funcionalidades originales de cada aplicación por otra cosa similar, utilizando los nuevos canales virales, las nuevas implementaciones de la API, los nuevos métodos, nuevos parámetros, etc…

Sin mencionar los clientes que ahora tienen que pagar un extra por proyectos ya finalizados, para poder mantener las aplicaciones funcionando, TODO esto en menos de 6 meses, pero ojo! solo dos semanas a partir del anuncio ya hay cosas que no funcionan mas, como la registración de templates de feeds

Dicho ésto, Creo que (en cierto punto) hay una buena razón de porqué Facebook está haciéndonos ésto. Hay un par de puntos interesantes que yo veo como un gran resultado de esta reformulación de la plataforma que estamos viviendo, y quiero compartir uno de ellos con ustedes.

Para empezar, lo que yo llamo “comments linking”. Supongamos que tenemos algún tipo de contenido en nuestra aplicación, digamos que tenemos un juego de trivia que guarda los resultados de los ganadores. La forma en la que funcionaba hasta ahora, básicamente podíamos tener una caja de comentarios asociada a un “Id de comentario” relacionado con algún comentario (por ejemplo el resultado de una jugada por un usuario). En adición a ésto, también teníamos una funcionalidad que nos permitía publicar un Feed Story (relacionado a alguna acción que el usuario realizara dentro de la aplicación) en el wall de los usuarios, anunciando por ejemplo que Juan venció a Martín en tal desafío.

Ambos, la caja de comentarios y el publicador de feeds son herramientas fantásticas, pero todas las acciones involucradas con ambos controles como por ejemplo dejar un comentario en un feed, marcarlo como “Me gusta”, compartirlo con otros, etc. no se reflejaban con las cajas de comentarios y viceversa… eso era realmente decepcionante.

Con los nuevos cambios que se vienen, nosotros podremos relacionar esas herramientas a un mismo id de contenido, que creo que será un boom en la viralidad de la aplicación, absolutamente mas provechoso que las notificaciones (que ya se estaban convirtiendo en muy spammers). Si tenemos la posibilidad de unir todos los comentarios, votos, shares, etc. bajo un mismo contenido, definitivamente tomará menos esfuerzo poder aparecer como highlight en el newsfeed de nuestros usuarios ayudando a que recuerden nuestra app, y permitiendo que sus amigos la conozcan.

Quizás necesitaremos comenzar a pensar en hacer aplicaciones cada vez mas serias basadas en el contenido generado por los usuarios, en vez de aplicaciones que spamean los canales virales ( lo cual era el modelo de aplicación preferido por muchos desarrolladores durante el último año).

La forma en la que los desarrolladores estaban haciendo dinero cuando la plataforma fue lanzada era utilizando “virtual currencies”, o sea monedas virtuales que se ganaban a través de micro pagos, pero difícil y costoso desarrollar aplicaciones de ese tipo. Hace un año y medio atrás la gente empezó este nuevo modelo basado en generarle millones de visitas a la aplicación (explotando los canales virales) para conseguir mas dinero de los Ad networks.

Creo que detrás de éstos cambios hechos por Facebook, básicamente ellos están buscando volver al primer modelo de aplicación el cual les proveía a ellos de aplicaciones de alta calidad, con un alto indice de retorno por los usuarios, en vez del modelo de aplicaciones construidas en tan solo 1 día…

Se que la viralidad es la clave para el éxito, pero una vez que tenes millones de usuarios en tu aplicación, que harás para conseguir mas page views?

En Altodot desarrollamos una aplicación viral que le tomó menos de 3 semanas en llegar a 2 millones de usuarios, y luego le tomó 4 a 5 semanas para perder la tracción que había ganado durante las primeras 3 semanas.

¿Cómo es eso posible? porque la aplicación básicamente no te dejaba hacer mas que clickear en un boton para conseguir mas amigos, y publicar feeds en el wall del usuario, pero aun así encontramos algo interesante, las “aplicaciones de una acción” es un concepto provado! Créanme, hay cierta gente ahí afuera que se siente sobrepasada cuando uno le ofrece muchas cosas para hacer dentro de la app, por lo que cuando ellos encuentran que lo único que pueden hacer dentro de tu aplicación es publicar algo en su muro, bueno… ellos sentirán bastante ganas de hacerlo, porque no hay otra cosa por hacer, es claro como el cristal!

Ese fue nuestro modelo de aplicación. Nosotros ganamos viralidad porque cada uno de ellos publicó el Feed Story, pero justo después de que apretaban en el botón Publicar, ellos se estaban empezando a aburrir!

Por lo tanto, nosotros ganamos viralidad, pero donde fue todo eso a parar? A ningún lado, los perdimos! Alguien dijo alguna vez: “Solo hay una oportunidad de dar una primera buena impresión…”.

Lo bueno en ésta ecuación es un beneficio colateral que declara que cerca del 5% de los usuarios que usaron la aplicación y que se aburrieron de ella, ANTES de que se olvidaran de nosotros nos dejaron un regalo, ellos presionaron el botón rojo (por así decirlo), ellos se volvieron fans de nuestra aplicación!. Usted se debe estar preguntando cuál es el placer de tener usuarios aburridos en el profile de su aplicación… y yo digo, Probablemente no los tengas comprometidos contigo, pero si los tienes enganchados! porque ahora tu puedes compartir con ellos todas las nuevas aplicaciones que vayas a lanzar! y todos los updates que realizarás sobre la aplicación, etc…

Como conclusión, las aplicaciones basadas solo en la viralidad usualmente no tienen una relación a largo plazo con sus usuarios, pero definitivamente son un un gran canal de marketing para las nuevas aplicaciones lo cual lo mantiene como un interesante negocio para algunas empresas. En la otra mano, las aplicaciones comprometidas son claramente lo que Facebook está buscando, y los desarrolladores cada vez encontrarán mas y mas herramientas para mantener la comunicación con sus usuarios fluida, mientras la comunidad de la plataforma de facebook crece día a día.

Para los premios de este año, trabajamos en conjunto en una estrategia que permitiera por un lado, llevar la plataforma de votación a las redes sociales y por otro, generar viralidad dentro del mismo entorno. Para ello decidimos lanzar una aplicacion “paraguas” en Facebook, donde podiamos lograr estos objetivos.

Los premios MTV 2009 permitió a todos lo usuarios de Facebook votar  y apoyar a sus artistas favoritos. De esta forma no hacia falta ir al sitio de los premios para poder participar. Asi mismo, podian encontrar contenido de notas y videos los cuales podian compartir con sus amigos.

Para lograr la tan famosa y deseada “viralidad” incluimos dos aplicaciones complementarias dentro de la aplicacion “paraguas”. Parte de la estrategia fue acompañar  la votación con la primera y luego de un tiempo lanzar la segunda. Eso ayudo a generar mas interaccion entre los usuarios. Esas aplicaciones fueron (en orden de aparición): Premia a tus amigos y Nomina a tus amigos.

Con Premia a tus amigos podías enviar lenguas blancas y negras a tus amigos en diferentes categorías. Hasta el momento se enviaron mas de 250.000 lenguas! En cambio con Nomina a tus amigos tratamos de simular los premios MTV, donde el creador de la nominación podía elegir a los nominados y los amigos de todos ellos podían elegir al ganador. Se crearon mas de 40.000 nominaciones donde el mínimo de participantes son 3 amigos, por lo que la exposición se multiplica mínimo por 3!

Ahora bien. ¿Como se logra tener 250.000 usuarios activos por mes y tanto engagement con los usuarios? ¿Como se logra tanta viralidad sin gastar un solo peso en medios? La respuesta es sencilla, pero a la vez compleja.

Si bien la idea es importante, lo principal es entender como funcionan los canales virales. Como se generar las relaciones entre los amigos, que clase de contenido es relevante para el usuario y como todos estos factores juegan en conjunto y generan una sinergía que impulsa, tanto a la marca como a la aplicación.

Por todo esto la aplicación de Los Premios MTV 2009 fue todo un éxito y esta en lo mas alto!

Desde el primer día estuvimos con muchísimo trabajo. Al mismo tiempo que armabamos la compañía, contratabamos a los primeros miembros del equipo, etc., teníamos que estar entregando los primeros desarrollos, y corríamos para empezar a lanzar los primeros productos de lo que después llamaríamos  “Altodot Labs”.

En  este corto tiempo de vida de Altodot, ya contamos con clientes directos como MTV, Turner Televisión, GranTV (Discovery Channel), y  hemos sido la compañía detrás de muchas de las aplicaciones lanzadas en este último tiempo por diversas agencias, para muchas de las marcas más importantes en América Latina.

Además de esto, como nos parecía que era poco, lanzamos los primeros experimentos de Altodot Labs. Uno de ellos, una aplicación para Facebook, logró llegar a los casi 2 millones de usuarios en menos de 3 semanas. ¿Casualidad? No creo… Tenemos un equipo con más de 2 años de experiencia tanto en marketing y comunicación sobre plataformas sociales, como en el área técnica, y para tener este tipo de “hits” hace falta que las dos areas trabajen de la mano, y tengan muy claro lo que están haciendo.

En los próximos posts iremos contando un poco más sobre lo que hacemos. La idea hoy, es presentar Altodot en sociedad, y explicar para qué creamos esta compañía.

Vemos que la mayoría de las organizaciones y empresas que intentan “entrar” en el mundo de la web 2.0, no tienen muy claro como hacerlo, o lo hacen mal. Ahí es donde entra Altodot, para ofrecer soluciones integradas al negocio de nuestros clientes. No pensamos en una campaña, en una promoción. Queremos ir más allá de eso, sabemos que se puede ir más allá, y en muchos casos, ni siquiera es una restricción presupuestaria la que lo impide, sino una restricción paradigmática sobre como se debería comunicar un producto, servicio, idea, o concepto.

Nos gusta encarar los proyectos pensando como consultores, comunicadores, y técnicos. Todo junto. Creemos que es la forma de ofrecer soluciones reales, que realmente se pagan “solas”. Que se desarrollan pensando en el negocio de nuestros clientes, no solo en la campaña del mes que viene.

Además de trabajar para terceros, Altodot desarrolla proyectos propios sobre plataformas sociales. Esto nos brinda la posibilidad de experimentar, saber escalar una aplicación, y entender mejor la dinámica de las redes sociales, en carne propia.

Como empezaba esa canción de Deró años atras … “Bienvenidos, a lo mas alto”