Artículos

Automatiza tus redes sociales sin que tu cuenta quede inactiva.

A circuit loop passing through a bright renewal gate

La automatización de redes sociales falla de una manera inusualmente fácil de pasar por alto. La cuenta no se bloquea con ninguna notificación. Deja de aceptar publicaciones discretamente, el proceso continúa ejecutándose y, tres semanas después, alguien pregunta por qué el feed ha desaparecido.

Casi todo se reduce a las credenciales, y las credenciales son la parte que todos los tutoriales omiten.

De larga duración no significa permanente

El malentendido más costoso en este ámbito es la frase "nunca caduca".

Un token de acceso de larga duración suele durar unos sesenta días y se puede renovar. Sin embargo, existe otro plazo: la ventana de acceso a los datos, que es de aproximadamente noventa días desde la última vez que una persona autorizó la aplicación. Renovar el token no reinicia dicha ventana. Solo se reinicia si una persona vuelve a completar el proceso de autorización.

Así, un sistema puede actualizarse diligentemente, informar que está en buen estado todos los días y, aun así, detenerse en seco en una fecha que nadie ha anotado en ningún sitio.

Anota la fecha límite real en un calendario con el nombre de una persona. Es la única parte de esto que no se puede automatizar, por diseño.

Actualiza periódicamente y comprueba la actualización.

El patrón que funciona no es emocionante.

  • Actualiza mensualmente, mucho antes de que caduque (a los sesenta días). No esperes a que falle para activarlo.
  • Almacena el nuevo token y la nueva fecha de vencimiento juntos, para que el sistema conozca su propia fecha límite.
  • Alerta cuando falla la actualización. Este es el paso que la gente suele saltarse. Un repaso que falla silenciosamente es peor que ningún repaso, porque crea la creencia de que el problema está resuelto.
  • Avisar cuando queden catorce días, independientemente de lo que haya indicado la última actualización.

Hemos observado cuarenta y seis intentos de publicación consecutivos que fallaron debido a credenciales caducadas, y todos ellos finalizaron correctamente porque el fallo fue detectado, registrado a nivel de depuración y tratado como un resultado normal.

No todos los fracasos son el símbolo

Dos de ellas nos costaron tiempo real, y ninguna era una credencial.

Incompatibilidad de la pila de red. Una serie de fallos de publicación parecían errores de autenticación. El token era correcto. El host tenía un registro IPv6, el servidor solo usaba IPv4 y las conexiones fallaban antes de que se produjera la autenticación. El API devolvía un error tan parecido a un error de autenticación que nos hizo buscar en el lugar equivocado durante todo un día. Al configurar el servidor para que usara IPv4, se solucionó el problema.

La tarea excedió su propio tiempo de espera. Un carrusel de varias imágenes tardó más de lo previsto en ejecutarse. La ejecución se interrumpió a mitad de camino, tras haber publicado en una red pero no en la otra, y el reintento comenzó desde el principio, publicando de nuevo la primera imagen. Una interrupción, dos síntomas: una publicación faltante en un canal y una publicación triple en el otro.

La solución consistió en permitir la reanudación independiente de cada plataforma, de modo que al reintentar se retome la ejecución desde donde se interrumpió, en lugar de empezar de nuevo. Si publica en más de una red en una misma tarea, compile esta funcionalidad antes de necesitarla.

Los límites de velocidad son un dato de entrada para el diseño.

Cada plataforma limita la cantidad de publicaciones y la velocidad de publicación. Considera esos límites como parte del diseño, no como errores que debas corregir.

Distribuye las publicaciones a lo largo del día en lugar de publicarlas todas a medianoche. Reduce la velocidad de respuesta a un límite de solicitudes de forma exponencial en lugar de reintentar inmediatamente, lo que en la mayoría de las plataformas prolonga el bloqueo. Y ten en cuenta qué cuentas comparten un límite, ya que en varias redes una cuenta comercial y su página vinculada utilizan el mismo conjunto de recursos.

Lo que el monitoreo tiene que responder

En lo que respecta a lo social, cuatro preguntas. Todas se refieren a resultados, no a resultados puntuales.

  • ¿Apareció la publicación en la plataforma? Consulta la plataforma y confirma que el objeto existe. El registro del propio trabajo no constituye prueba suficiente.
  • ¿Cuántos días faltan para que caduque la credencial y para que se cierre el plazo de autorización? Dos números distintos.
  • ¿Cuándo fue la última vez que cada canal publicó correctamente? Por canal. Un agregado oculta el que se detuvo.
  • ¿Se publicó algo dos veces? La detección de duplicados detecta el error de reanudación mencionado anteriormente, que de otro modo parecería exitoso en ambos intentos.

La versión realista

La automatización social funciona bien y vale la pena implementarla. Sin embargo, no es un sistema totalmente automatizado. Aproximadamente una vez al trimestre, algo requerirá la intervención humana: una reautorización, un cambio de dispositivo o una actualización de políticas.

Si se diseña teniendo en cuenta ese ritmo, el coste de mantenimiento será pequeño y predecible. Si se asume que funcionará indefinidamente sin interrupciones, se descubrirá el horario real de la peor manera, tres semanas después de que la señal de internet deje de funcionar.

Sigue leyendo