Señales de criptomonedas en redes sociales: creación de un pipeline de datos reproducible

Alcance y el modelo mental central

La expresión criptomonedas en redes sociales abarca dos cosas diferentes que es fácil confundir. La primera son las redes sociales descentralizadas, plataformas basadas en blockchain donde la identidad, el contenido o las recompensas viven on-chain. La segunda, y en la que se centra este artículo, es el uso de plataformas sociales convencionales como fuente de datos sobre activos cripto: volumen de publicaciones, interacción, sentimiento y actividad de bots que se desea relacionar con el comportamiento del mercado o de la red.

El modelo mental es una unión de tres tablas. La tabla uno son las publicaciones: autor, marca de tiempo, texto y recuentos de interacción. La tabla dos son los datos de mercado: precio y volumen en marcas de tiempo coincidentes. La tabla tres es la actividad on-chain: transferencias, direcciones activas o eventos de contrato en las mismas marcas de tiempo. Cualquier afirmación del tipo «el ruido social predice rendimientos» es una declaración sobre cómo covarían estas tres tablas dentro de una ventana definida. Si no puede reconstruir las tres tablas, no puede auditar la afirmación.

Trate cada métrica como una definición, no como un hecho. «Interacción» puede significar me gusta más reposteos, o puede significar una tasa de interacción normalizada por seguidor. La investigación publicada ha utilizado modelos de interacción basados específicamente en la interacción para evitar las debilidades del volumen bruto de publicaciones y la puntuación ingenua de sentimiento, así que elija una definición y manténgala fija durante todo el estudio.

• Ventana de observación: las marcas de tiempo exactas de inicio y fin de la recopilación.
• Resolución de entidades: cómo se asigna una publicación a un ticker de activo o a una dirección de contrato.
• Clave de unión: normalmente un intervalo de tiempo UTC, a veces también una dirección de contrato.
• Línea base: contra qué compara la señal, como una ventana de control emparejada por volumen.

Supuestos, requisitos previos y lo que debe medir usted mismo

Este procedimiento supone que tiene acceso legal a una API de plataforma social o a un conjunto de datos exportado, una fuente de datos de mercado con marcas de tiempo y un endpoint RPC para la cadena donde reside el activo. No supone ningún proveedor en particular. Para la selección de endpoints, el Asistente RPC cubre opciones concretas como la mejor API RPC de Ethereum y las opciones de proveedor RPC de BNB Chain; esta página se mantiene en la metodología.

Comportamiento documentado en el que puede confiar: las llamadas RPC de blockchain devuelven datos en una altura de bloque, y las alturas de bloque se asignan a marcas de tiempo. Eso le proporciona una clave de unión determinista para los datos on-chain. Todo lo demás, incluida la representatividad de su muestra social y si la interacción predice algo, es una medición que debe ejecutar.

Antes de recopilar, escriba la hipótesis, la lista de activos, la ventana y las definiciones de métricas en un archivo versionado. Si cambia alguno de ellos a mitad del estudio, reinicie la ventana en lugar de parchearla.

• Una fuente de datos sociales con marcas de tiempo por publicación y recuentos de interacción.
• Una serie de precios con una granularidad no más gruesa que sus intervalos de publicaciones.
• Una RPC_URL para la cadena correspondiente, mantenida fuera del control de código fuente.
• Una capa de almacenamiento que conserve las cargas útiles sin procesar junto con las métricas derivadas.

Recopilación de publicaciones con un esquema estable

Recopile primero las cargas útiles sin procesar y derive las métricas después. La retención de datos sin procesar le permite recalcular la interacción después de descubrir que una definición era incorrecta, lo cual es común. El ejemplo de Python a continuación escribe una línea JSON por publicación con una marca de tiempo UTC normalizada y conserva el objeto original en raw para que no se pierda nada.

Los límites de velocidad y la paginación son las dos restricciones operativas. Persista un cursor por consulta para que una ejecución interrumpida se reanude en lugar de duplicar. Deduplique por el identificador de publicación de la plataforma, no por el texto, porque el texto idéntico se repite con frecuencia.

import json, os, time, datetime as dt
import requests

API_BASE = os.environ["SOCIAL_API_BASE"]
TOKEN = os.environ["SOCIAL_API_TOKEN"]
QUERY = "$EXAMPLE"
OUT = "posts.jsonl"

def fetch_page(cursor=None):
    params = {"q": QUERY, "limit": 100}
    if cursor:
        params["cursor"] = cursor
    r = requests.get(
        f"{API_BASE}/search",
        params=params,
        headers={"Authorization": f"Bearer {TOKEN}"},
        timeout=30,
    )
    r.raise_for_status()
    return r.json()

cursor = None
with open(OUT, "a", encoding="utf-8") as f:
    while True:
        page = fetch_page(cursor)
        for post in page.get("items", []):
            record = {
                "id": post["id"],
                "author_id": post["author"]["id"],
                "created_at": dt.datetime.fromisoformat(
                    post["created_at"].replace("Z", "+00:00")
                ).astimezone(dt.timezone.utc).isoformat(),
                "text": post.get("text", ""),
                "likes": post.get("like_count", 0),
                "reposts": post.get("repost_count", 0),
                "raw": post,
            }
            f.write(json.dumps(record) + "\n")
        cursor = page.get("next_cursor")
        if not cursor:
            break
        time.sleep(1.0)

Obtención de actividad on-chain mediante RPC

Los datos on-chain anclan su línea de tiempo. La señal confiable más simple es la propia producción de bloques: obtenga las marcas de tiempo de los bloques para que cada intervalo social se asigne a un rango de bloques. A partir de ahí, puede ampliar a recuentos de transferencias o eventos de contrato para el activo específico.

El ejemplo de curl a continuación utiliza JSON-RPC sobre HTTP. Reemplace RPC_URL con su propio endpoint. Si necesita ayuda para elegir uno, la guía de endpoints RPC explica la forma de la solicitud, y la guía de endpoints RPC multicadena cubre la ejecución del mismo patrón en varias cadenas.

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBlockByNumber",
    "params": ["0x134fd90", false]
  }'

Unión de datos sociales, de mercado y de cadena en intervalos UTC

Elija un tamaño de intervalo antes de ver los resultados. Los intervalos horarios son un valor predeterminado razonable para activos líquidos; los intervalos diarios reducen el ruido pero ocultan picos de corta duración. La unión es una unión izquierda desde los intervalos sociales a los intervalos de mercado y de cadena, de modo que los períodos tranquilos permanezcan en el conjunto de datos como ceros en lugar de desaparecer.

El ejemplo de JavaScript calcula una puntuación de interacción simple por intervalo y adjunta el rango de marcas de tiempo de los bloques. Deliberadamente no calcula rendimientos; eso pertenece a un paso separado para que la unión pueda probarse de forma independiente.

const BUCKET_MS = 60 * 60 * 1000;

function bucketKey(iso) {
  return Math.floor(new Date(iso).getTime() / BUCKET_MS) * BUCKET_MS;
}

function buildBuckets(posts, blocks) {
  const map = new Map();
  for (const p of posts) {
    const k = bucketKey(p.created_at);
    const b = map.get(k) || { key: k, posts: 0, engagement: 0, authors: new Set() };
    b.posts += 1;
    b.engagement += (p.likes || 0) + 2 * (p.reposts || 0);
    b.authors.add(p.author_id);
    map.set(k, b);
  }
  for (const blk of blocks) {
    const k = bucketKey(blk.timestampIso);
    const b = map.get(k) || { key: k, posts: 0, engagement: 0, authors: new Set() };
    b.blockNumber = blk.number;
    map.set(k, b);
  }
  return [...map.values()]
    .sort((a, b) => a.key - b.key)
    .map(b => ({ ...b, uniqueAuthors: b.authors.size, authors: undefined }));
}

module.exports = { bucketKey, buildBuckets };

Medición de la proporción de bots antes de confiar en la interacción

Una alta interacción puede significar interés genuino o actividad automatizada. Los trabajos publicados sobre coeficientes de interacción encontraron que los valores extremos en cualquier dirección correspondían a rendimientos futuros más bajos, y los valores muy altos a menudo indicaban actividad impulsada por bots. No necesita reproducir ese estudio para aplicar la lección: mida un proxy de bots y repórtelo junto a la interacción.

Un proxy práctico es la proporción de publicaciones de cuentas creadas recientemente, la proporción de textos casi duplicados dentro de un intervalo y la relación entre publicaciones y autores únicos. Ninguno de estos es definitivo. Su valor es que son baratos, deterministas y recalculables a partir de datos sin procesar.

• Publicaciones por autor único por encima de un umbral que establezca de antemano.
• Proporción de texto duplicado calculada con un hash normalizado del texto.
• Distribución de antigüedad de las cuentas, si su fuente expone fechas de creación.
• Interacción por autor, que colapsa cuando unas pocas cuentas dominan.

Procedimiento de tabla de resultados y verificación esperada

Produzca una tabla de resultados antes de sacar conclusiones. Cada fila es una variante de señal; cada columna es una métrica calculada sobre la misma ventana. Rellénela solo con números que su pipeline haya emitido, nunca con valores ilustrativos. Una tabla defendible se ve así:

La verificación es procedimental, no numérica. Vuelva a ejecutar el pipeline desde las cargas útiles sin procesar y confirme que la tabla es idéntica byte a byte. Si no lo es, su unión o su manejo de marcas de tiempo no es determinista. Solo después de esa comprobación debe interpretar la correlación, e incluso entonces trátela como descriptiva dentro de la ventana en lugar de predictiva fuera de ella.

Solución de problemas comunes del pipeline

La mayoría de las conclusiones erróneas se remontan a un pequeño conjunto de errores mecánicos. Revise estos antes de cuestionar la hipótesis.

Si sus llamadas RPC fallan intermitentemente o devuelven bloques obsoletos, la unión eliminará filas de cadena de forma silenciosa. Registre la altura de bloque que realmente recibió y compárela con la altura esperada para la marca de tiempo. Para cuestiones de confiabilidad a nivel de proveedor, la guía de alojamiento de nodos blockchain y las opciones de nodo dedicado explican las ventajas y desventajas entre infraestructura compartida y dedicada.

• Desfase horario: mezclar marcas de tiempo locales y UTC desplaza los intervalos por horas.
• Colisiones de tickers: dos activos que comparten un símbolo se fusionan en una sola serie.
• Sesgo de supervivencia: los activos que fueron retirados de la lista desaparecen de las ventanas posteriores.
• Fuga de información futura: usar el recuento final de me gusta de una publicación en un momento anterior a que esos me gusta existieran.
• Brechas de paginación: un rastreo interrumpido deja huecos que parecen períodos tranquilos.

Limitaciones y compensaciones

Los datos sociales son una muestra de una muestra. Las plataformas cambian las API, eliminan publicaciones y alteran lo que significan los recuentos de interacción, por lo que un pipeline que es reproducible hoy puede no serlo el año que viene a menos que conserve las cargas útiles sin procesar. Incluso con retención de datos sin procesar, las publicaciones eliminadas se pierden.

Los datos on-chain son más duraderos pero no están exentos de interpretación. Los recuentos de transferencias incluyen movimientos internos de exchanges, y las métricas de direcciones activas pueden ser infladas por un solo actor. Combinar las dos fuentes reduce la dependencia de cualquiera de ellas, pero no elimina la confusión: un movimiento amplio del mercado puede impulsar tanto el volumen social como la actividad on-chain sin que ninguno cause al otro.

Por último, las métricas de interacción son sensibles a la definición. Cambiar el peso de los reposteos, o pasar de sumas a tasas por autor, puede invertir el signo de una correlación. Esa sensibilidad es en sí misma un hallazgo que vale la pena reportar.

Próximos pasos para un estudio de nivel de producción

Una vez que el pipeline sea determinista, extiéndalo en tres direcciones. Primero, agregue un activo de control que no esperaba que se viera afectado, para que pueda ver si su señal es específica o simplemente de todo el mercado. Segundo, ejecute el mismo procedimiento en múltiples ventanas y reporte la estabilidad en lugar de un único resultado. Tercero, pase de la correlación a una regla de decisión explícita y preinscrita, y evalúela fuera de muestra.

Para la infraestructura, separe el nivel de recopilación social del nivel de consulta de cadena para que un límite de velocidad en uno no detenga al otro. Revise los precios de RPC antes de escalar el volumen de consultas, y considere un nodo dedicado si su carga de trabajo de escaneo de bloques se vuelve continua. El directorio de redes enumera las cadenas a las que puede apuntar, y el Asistente RPC puede ayudarle a elegir un endpoint concreto una vez que su metodología esté fijada.

• Versione el archivo de hipótesis junto con el código.
• Almacene las cargas útiles sin procesar y las tablas derivadas por separado.
• Vuelva a ejecutar desde los datos sin procesar de forma programada para detectar desviaciones.
• Reporte los proxies de bots junto a cada cifra de interacción.