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). 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 “Canvass” de la aplicación activo, para volver a utilizarlo cuando se haga otra campaña, ya que los usuarios se instalan un “Canvass” 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 (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, Ususarios Activos Mensuales, y Cantidad de Usuarios que Instalaron la Aplicación.
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
Manejando los problemas de la plataforma de Facebook.
Algunos días atras comenzamos a recibir un error del estilo “The URL … did not respond.” en algunas aplicaciones que estabamos 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 encontamos 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 cláramente 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 companía 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 aplicacieon estaba hecha en php no podiamos 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 habian 3 ideas:
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
Cambiar todo el codigo de nuestra aplicación para que corra dentro de un iframe reemplazando todo el codigo FBML y FBJS (obviamente esto sería lo último que hubieramos hecho)
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 multiples llamados simultaneos 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.
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:
- 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
- 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)
- 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é.
Como probablemente sepan, Facebook anunció dos semanas atrás un enorme roadmap sobre lo que se viene para el FB Platform en los próximos 6 meses. La noticia rápidamente se volvió inquietante para el millón de desarrolladores de facebook (de acuerdo con las estadísticas reveladas en el último FB Garage en San Francisco).
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.
Por segundo año consecutivo MTV y AltoDOT llevan a las redes sociales Los Premios MTV. Para los premios del año 2008 lanzamos una aplicación en Facebook y otra en MySpace con el objetivo de lograr mayores votos.
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!
Ya pasaron más de dos meses desde que junto a Matías Paterlini y Claudio Cohen empezamos a darle vida a lo que hoy es Altodot, y ya era hora de dar a conocer lo que estuvimos haciendo !!!
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”
January 26th, 2010 | Autor: Antón Chalbaud | 
