ADVANCED COMMUNITY MANAGEMENT Y GROWTH HACKING

¡Buenos días a todos! Hace tiempo que quería escribir este artículo, sobre todo para animar a aquellos a quien interese el marketing online y las posibilidades que ofrece la difusión en las RRSS, ya que son profesiones al alza y con grandes cotas de reclutamiento. Así que voy a aclarar un poco ciertos conceptos y luego pasaremos a hablar de un caso práctico de cosecha propia en Twitter ¿me acompañas?

Vamos con el glosario en primer lugar: ¿A qué llamamos Community Manager? Un CM es según Wikipedia un “Responsable de comunidad de internet”, es decir, quien maneja las redes sociales y ejecuta el plan de marketing en ésta. También de facto, se convierte en una especie de servicio al cliente online resolviendo dudas o consultas y contacto de post-venta para muchas marcas. Otra especie de “canal online” que se ha demostrado mucho más efectivo que los chat-window de las propias website de cada empresa. ¿Algo va mal? Se lo digo a la empresa por Twitter. ¿Busco algún dato de la empresa? Pues se lo pregunto por Facebook.

Existe un nivel superior dentro de ser CM que es lo que se suele denominar Advanced Community Manager. Un ADV debe saber extraer métricas y analíticas de las campañas que se realizan. Medir datos objetivos, consultando impresiones, visitas y vistas y plasmar eso en informes de repercusión. Normalmente para esta tarea se utilizan herramientas especializadas para RRSS, muchas de pago, y su uso se convierte en fundamental para un buen ADV. Es esa la principal diferencia: puede cuantificar los resultados de la estrategia de marketing.

¿Y qué tenemos por encima? Pues el growth hacking aplicado a redes sociales. El growth hacking intentará utilizar medios automatizados para bien en base a resultados, o bien por pura inundación (flood) el captar la mayor atención y repercusión en redes sociales. Es el uso de programas que interactúan con las RRSS ahorrando horas/hombre, lo que marca la diferencia. Bien recolectando datos o estadísticas de impresión (big data) y/o aplicando machine learning, bien simplemente volcando datos a las RRSS desde otras fuentes para así mantener una línea de información constante, o bien con cualquier otra forma que haga nuestro canal más atractivo y por ende, sume más seguidores para la empresa que se quiere promocionar. A estos programas que emulan perfiles humanos, solemos llamarlos bots.

Las RRSS tienen unos interfaces para desarrolladores llamados API, de manera que programas pueden interactuar con ellas. La mayoría, tienen ciertos límites, que pueden ser eliminados previo pago, y no barato precisamente: En el caso de Twitter anda por 110.000$ si queremos tener acceso ilimitado a su base de datos.

Veamos un ejemplo práctico de esto último:

Puse mi blanco en Twitter y el primer mandamiento de cualquier growth hacker: Examinar límites. Si queremos aprovechar la funcionalidad al máximo de cualquier RRSS para maximizar la repercusión, deberemos tener claro dónde están los límites.

No fue difícil encontrar muchas webs en las que contrastar que límites había para la API de Twitter de usuario. Me resultó muy llamativo que pudiese hacerse hasta 1000 FAV’s al día (me gusta). Caí en la cuenta que cada FAV por defecto envía una notificación a la app del móvil del usuario por defecto (esto se puede configurar pero el “por defecto” es la clave). ¿Qué tengo un método para interactuar con 1000 móviles al dia? Como diría DUKE NUKEM: ‘Let’s Rock!’

Siguiente paso, usar Python y encontrar librerías que me permitieran interactuar con la API. En primer lugar, use TWITTER LIBRARY (website).

Mi primera aproximación como prueba fue usar la STREAMING API. Twitter tiene 2 modos de API: Streaming API y REST API. Básicamente la primera es un “chorro” en tiempo real con todos los resultados, donde después podríamos filtrar, y la segunda es un modo de búsqueda al uso, p.ej: Devuélveme los últimos 10 twits con la palabra “gaming”.

Pues probé a recibir twits desde la streaming api, e ir marcando twits al azar. El resultado fue bastante mediocre: Llegué a interactuar con 990 cuentas por día, pero apenas 3 o 4 me hacían follow, que era mi objetivo: fomentar mi perfil personal en twitter. He de decir que en mi primera prueba usé mi perfil personal real. Es altamente recomendable nunca hacer eso con tu cuenta y probar con una cuenta de test. Si, lo sé, vivo al límite….

Mi segunda opción fue intentar que las cuentas con las que interactuara fuesen bajo unos criterios a los que mi cuenta pudiese ser afín. Empezando obviamente por el idioma: ¿Por qué me iba a hacer follow un filipino que no habla ni inglés ni español? Una vez situado en este punto, decidí rehacer todo el código y pasarme a la API de búsqueda. Por ejemplo, los gamers es de suponer que mostrarán más interés en mi perfil que los aficionados a la pesca. Con lo que la consulta anterior (Devuélveme los últimos 10 twits con la palabra “gaming”) me haría interactuar con un FAV con 10 cuentas distintas que habían publicado algo con ese término. Decidí usar una lista de términos y lanzar pruebas al azar con mis intereses personales: Hacking (y ciberseguridad), cine, series, tecnología, etc…

Aquí empezaron los problemas, la consulta empezó a devolverme varias veces el mismo tuit, y al detectar twitter que ya había hecho FAV a ese twit, detectó “comportamiento sospechoso” y me anularon las credenciales OAuth para esa APP, lo que dejaba inservible el bot. Aparte el límite de 990 al día empezó a contabilizar mal y a veces me excedía (ERROR 429). Lo cual supongo que también levantaba alguna alerta en el servicio de la API, y también me costó algunas credenciales.

Había 2 opciones para solventar esto:

  1. Consultar el estado del twit antes de hacer FAV para no repetir la operación
  2. Guardar el log de los twits que ya había “FAVeado” para eso mismo.

Llegado a este punto me decidí a hacer pruebas múltiples: Usé 4 cuentas diferentes con las credenciales en .json y una lista de términos en txt que adquiría en cada ejecución. Probando con la solución 2: Mantener yo un registro de log con los twits que ya no me interesaban por estar en FAV.

Debo decir que esta aproximación me pareció mucho más correcta. Cada cuenta interactuaba bajo unas listas de términos con cuentas afines a los intereses y el resultado en crecimiento empezó a hacerse mucho más ostensible: Incluso 20-25 follows por día. Y manteniendo un log de los twits con los que interactuaba, de paso que extraía inteligencia sobre los mismos, me ahorraba consultas a la Api.

Pero este método tiene un pequeño problema de caducidad: Al cabo de 3000 o 4000 twits, puede que la lista de un término esté agotada y no se produzcan nuevos favs casi apenas varios al día (aquí me fue especialmente valiosa la información del log). Por tanto, el crecimiento se vio severamente afectado.

¡Hora de probar más cosas! He aquí la verdadera esencia del hacking: Descubrir posibilidades y hacer pruebas de concepto sobre ellas. ¿Qué términos podría buscar que me produjeran siempre resultados nuevos? Pues a la vista lo tenía: Los Trending-Topic. ¿Qué mejor manera que usar los términos más populares? ¿jugamos?

Bien, pues como ya tenía claro la relevancia del idioma, la API permite consultar la lista de TT en base a una localización. Era tan fácil como buscar por la lista de España y liarme a hacer FAV’s, y repetir cada 24h.

Como prueba estuvo bastante bien, pero el resultado no era tan bueno. Me veía en la necesidad de seguir en la línea de los términos que me permitían contactar cuentas que publicaban cosas acerca de esos términos afines a cada cuenta.

De modo que volví a la solución de términos y uní esa dinámica a la API en Stream de nuevo, como solución híbrida. La API solo devolvería tuits nuevos, e iría marcando todos los que yo decidiera que incluían un término de mi interés. El resultado era más modesto al principio, pero era constante en el tiempo: Marcaba por ejemplo todos los twits (o hashtag IMPORTANTE!) que yo quisiera, y podría lanzar uno por cada término vía línea de comando:

C:>Python autofav.py gaming -> lanzaba un bot que marcaba todos los twits con la palabra ‘gaming’

Añadí la posibilidad de guardar un log como vía de debuggin, pero tras esta última aproximación decidí haber disfrutado y aprendido unas cuantas buenas cosas acerca de cómo interactuar con tuits o almacenar big-data sobre ellos. Debo aclarar que igual que esta operación podría haber hecho RT, haber contestado a todos los tuits con chistes de Chuck Norris por ejemplo (también hay una API que los devuelve) o cualquier otra acción.

Véase que las posibilidades son casi infinitas y el consecuente ahorro de coste humano también, así que espero que esto os anime un poco a investigar y aprender en el proceso a experimentar con los límites y posibilidades. Seguro que se os han ocurrido un montón de posibles aplicaciones de estas interacciones según estabais leyendo este artículo, a mí, alguna maldad también….

Salu2 y feliz 2019!
Andrés Naranjo @TheXXLMAN
info@xxlman.es