procedimientos recomendados de Real-Time Signals Service (RTSS)

Los siguientes procedimientos recomendados le ayudarán a usar RTSS correctamente.

Límites de velocidad de API

Para evitar el abuso de los servicios de API, todas las cuentas suelen estar limitadas a 10 lecturas y escrituras por segundo. La API aplica este límite mediante programación en un nivel de miembro.

Para evitar superar los límites de velocidad, use el servicio de carga masiva RTSS para cargar varios registros. Si el archivo de carga masiva tiene más de un millón de registros, espere entre 10 y 15 minutos antes de intentar la siguiente carga. Para obtener más información sobre los límites de velocidad de API, consulte la documentación de limitación de API .

Nomenclatura de segmentos

Al crear objetos de segmento para destinos RTSS, es una buena idea incluir rtss en el nombre del segmento o agregar esta cadena como código de segmento. El etiquetado de los segmentos RTSS facilita la identificación de los segmentos que tienen destinos rtss en tiempo real (IP, OLC o lat/longs), en lugar de audiencias (cookies/MAID). La nomenclatura clara también ayuda a solucionar problemas de objetos de segmento.

Por ejemplo, podría usar la siguiente convención de nomenclatura:

rtss_kind_of_target(IP/OLC/Lat-Long)_segmentName

Ejemplo: un segmento donde hospedará destinos de OLC y quiere asignarle el nombre myOLCsegment podría denominarse rtss_OLC_myOLCsegment.

Construcción de segmentos

Para obtener los mejores resultados, no mezcle las cookies y los destinos RTSS en el mismo segmento; guárdelos siempre en segmentos independientes. Esta separación facilita la administración y solución de problemas de segmentos futuros.

Expiración de destino

Al cargar destinos en RTSS, asegúrese de realizar un seguimiento de su TTL. Asignamos una expiración predeterminada de 180 días por destino a menos que se especifique lo contrario. Realizar un seguimiento de qué destinos expirarán pronto ayuda a evitar lo siguiente:

  • Las campañas en ejecución no sirven, porque tienen como destino segmentos RTSS con destinos expirados.
  • Cargar archivos innecesariamente grandes, en lugar de solo los destinos que expirarán pronto.

Si necesita actualizar los segmentos o crear otros nuevos con frecuencia, es probable que los 180 días predeterminados sean demasiado largos. Por ejemplo, si usa OLC para dirigirse a los datos de movimiento de datos lat/long, puede crear un destino que solo sea válido durante un breve período de tiempo. En este caso, debe establecer un TTL más corto para evitar los costos de recursos del almacenamiento de destinos no utilizados.

Puede establecer TTL mediante seg_ttl, pero este valor incluye el tiempo de procesamiento y puede que no sea exacto. El procedimiento recomendado consiste en usar expiry, que establece la fecha y hora precisas en que deben expirar los segmentos. expiry se establece en el nivel de archivo, aunque los segmentos cuyo valor explícito seg_ttl daría lugar a una expiración anterior a la configuración de expiración seguirán expirando antes de la expiry fecha.

En la tabla siguiente se muestra la relación entre seg_ttl y expiry en los posibles casos en los que se especifica uno o ambos.

Escenario Expiración no especificada Expiración especificada
TTL no especificado TTL efectivo = TTL predeterminado: processing_delay
Por ejemplo, si el archivo se envía en 3/1/2022 00:00:00 y el procesamiento se inicia el día después, el TTL efectivo es 29 días y la expiración se produce en 3/31 00:00:00.		 TTL efectivo = expiración especificada – (submission_time + retraso de procesamiento)
Por ejemplo, suponga que el archivo se envía en con la fecha y hora de expiración explícita establecida en 3/1/2022 00:00:004/1 00:00:00. Si el procesamiento se inicia en 3/2, el TTL efectivo es 30 días y la expiración se produce en 4/1.
TTL especificado TTL efectivo = TTL especificado: retraso de procesamiento
Por ejemplo, si el archivo se envía con 3/1 00:00:00 los días especificados seg_ttl90 = y el procesamiento comienza el día después, el TTL efectivo es 89 días y la expiración se produce en .5/30 00:00:00		 TTL efectivo = explícito expiry o explícito seg_ttl, lo que resulte en una expiración anterior.
Por ejemplo, supongamos que el archivo se envía en 3/1 , 00:00:00con expiry establecido (en el nivel de archivo) para 6/1 en 00:00:00. Si algunos registros del archivo no incluyen un TTL explícito, algunos lo establecen 60 en días y otros en 120 días; a continuación, suponiendo que el procesamiento se inicia inmediatamente, el TTL efectivo y la expiración serán:
- Los registros sin seg_ttl tendrán un TTL de 92 días y expirarán en 6/1.
- Los registros con seg_ttl = 120 también tendrán un TTL de 92 días y expirarán en 6/1, porque el valor de expiración da como resultado una expiración anterior y, por tanto, tiene prioridad.
- Los registros con seg_ttl = 60 tendrán un TTL efectivo de (60 días - tiempo de procesamiento) y una fecha de expiración cerca de 5/1. En este caso, seg_ttl tiene prioridad (pero todavía se ve afectado por el tiempo de procesamiento), porque 60 < 90.

OLC y segmentación geográfica

Las cargas RTSS aceptarán cualquier cadena que represente un OLC válido. Al acortar el código OLC proporcionado, puede especificar un área menos precisa y aumentar la zona de destino. Se recomienda usar un mínimo de 4 símbolos para códigos OLC (un bloque de aproximadamente 110km y un máximo de 8 símbolos (un bloque de aproximadamente 275 m)).

RTSS usará Lat/Long para la ubicación cada vez que se proporcione en el momento de la impresión y volverá a la dirección IP en caso contrario. Lat/Long normalmente solo se proporciona a través de impresiones desde la aplicación, cuando el usuario ha concedido explícitamente permiso a la aplicación para identificar la ubicación del dispositivo.

En la mayoría de los casos que implican un explorador de escritorio o móvil, la dirección IP se usa para aproximar la ubicación de la impresión. La precisión de direcciones IP suele ser suficiente para identificar un código postal para el escritorio, pero en algunos casos puede identificar con precisión un edificio, por ejemplo, cuando una oficina tiene un intervalo IP explícito. En el caso de las conexiones de operadores móviles, la dirección IP le proporcionará de forma eficaz la ubicación de la torre de celdas a la que está conectado el dispositivo.

Cargas masivas

Para garantizar un buen rendimiento durante las cargas masivas:

  • Cargue solo deltas. Se recomienda cargar solo los cambios en el conjunto de datos en Xandr, en lugar de en todo el conjunto de datos. Por ejemplo, si tiene un archivo con 100 000 puntos de datos, pero solo 2000 de esas filas han cambiado desde la última carga, cargue solo las 2000 filas de registros que cambiaron. Esto reduce el tiempo de carga, así como el tiempo necesario para procesar los datos y hacer que estén disponibles para la selección de destino.
  • Archivos grandes GZIP. Use GZIP para comprimir los archivos para reducir los tiempos de carga.
  • Use el formato de archivo correcto. Los archivos deben guardarse en la codificación UTF-8 estándar (sin BOM). Use finales de línea de estilo Unix (caracteres de avance de línea, no retornos de carro) y asegúrese de que el archivo no contiene un final de línea final.

Reintentos de API

En ocasiones, puede recibir un 422: too many queries to the database error de RTSS durante períodos de carga pesada en nuestro sistema. Esto ocurre porque RTSS prioriza las solicitudes de búsqueda de nuestros licitadores en lugar de las llamadas API, de modo que los segmentos se agregan correctamente en las solicitudes de puja. Se recomienda compilar la funcionalidad de suspensión/reintento en el proceso. Si ve un 422 error, haga que el proceso espere entre 3 y 5 segundos antes de intentarlo de nuevo. La emisión de un reintento de llamada API de 1 a 2 veces funciona en la mayoría de los casos.

Si ve estos errores con frecuencia, también debe emplear un retroceso aleatorio en la limitación de API.

  • Last updated on