13 recomendaciones para usar la API de informes eulerianos

13 recomendaciones para usar la API de informes eulerianos



1. Principio clave de la API de informes por lotes

La API de informes por lotes le permite extraer datos de informes eulerianos de las vistas disponibles en la interfaz.
Debe utilizarse para automatizar la extracción de informes ya disponibles en la interfaz euleriana. No debe considerarse una herramienta para crear, mediante una sola consulta, un nivel de granularidad o una combinación de datos que no existan en los informes.
Por ejemplo, si un análisis requiere combinar varias fuentes o vistas, se deben realizar varias solicitudes a la API y, a continuación, los resultados deben agregarse en el lado de la inteligencia empresarial, el almacén de datos o el script de procesamiento.


2. Momento recomendado para lanzar trabajos de API

Para recuperar los datos completos de J-1, se recomienda iniciar las exportaciones a partir de las 06:00 am .
Durante la noche, Eulerian sincroniza la base de datos inactiva para integrar los datos del día anterior. Una consulta realizada muy temprano por la mañana, por ejemplo alrededor de las 5:00, puede fallar durante esta sincronización y provocar que la base de datos no esté disponible o que los datos queden incompletos.
Por lo tanto, la recomendación operativa es programar las tareas de la API a partir de las 06:00 .


3. Recuperar los parámetros correctos para una solicitud de API.

Un método sencillo para crear una solicitud de API consiste en comenzar con el informe deseado en la interfaz euleriana y, a continuación, observar la solicitud generada por la interfaz.
Pasos recomendados:
    Abra el informe deseado en la interfaz euleriana.
    Abre las herramientas para desarrolladores del navegador con F12 .
    Ve a la pestaña Red .
    Identifique la consulta de informes generada por la interfaz.
    Recuperar los parámetros necesarios para construir el cuerpo de la API.
Los elementos útiles que se pueden recuperar incluyen:
Élément observé dans la requête réseau
Utilisation dans l’API
view-id
ID de vista de atribución
ea-datasource
Valor del kind , con el prefijo rt# en el cuerpo de la API
path
Valor que se utilizará en el campo path del cuerpo JSON.
Identificadores presentes en la path
Identificadores de editor, influencia, plan de medios o campaña según la vista visualizada
La path visible en la consola ya contiene los ID correspondientes al nivel de datos que se está visualizando: editor, palanca, plan de medios, campaña, etc.


4. Punto final de consulta

El punto final utilizado para consultar la API de informes por lotes tiene el siguiente formato:
POST /ea/{site}/report/{batch}/query.json
El cuerpo JSON normalmente contiene una matriz
Content-Type: application/json
reports , en los que definimos:
Élément
Rôle
dateRanges
Período de análisis
dimensions
Puntos clave a considerar en el informe
kind
Fuente de datos / tipo de informe
metrics
Indicadores para extraer
path
Nivel o alcance de la información de los medios
segmentFilterClauses
Filtros opcionales, por ejemplo, en tipos de ventas.
Ejemplo sencillo:
{
"reports": [
{
"dateRanges": [
{
"range": "YESTERDAY"
}
],
"dimensions": [
{
"field": "ope_name",
"name": "campaign"
}
],
"kind": "rt#insummary",
"metrics": [
{
"field": "scartvalid",
"name": "sales"
}
],
"path": "mcMEDIAINCOMING[?].mcMEDIAAD.mcOPE"
}
]
EL
}

kind , path , las dimensiones y las métricas deben adaptarse a la proporción que deseamos reproducir.


5. Filtrar por tipo de venta

Los filtros en los tipos de ventas se gestionan a través de segmentFilterClauses .
En el caso de los tipos de venta, el campo a utilizar es:
Ejemplo de consulta con un filtro por tipo de venta:
"field": "ordertype_id"

{
"reports": [
{
"dateRanges": [
{
"range": "YESTERDAY"
}
],
"dimensions": [
{
"field": "ope_name",
"name": "campaign"
}
],
"kind": "rt#insummary",
"metrics": [
{
"field": "scartvalid",
"name": "sales"
}
],
"path": "mcMEDIAINCOMING[?].mcMEDIAAD.mcOPE",
"segmentFilterClauses": [
{
"field": "ordertype_id",
"operator": "IN",
"value": [
1,
2
]
}
]
}
]
Les IDs à ​​renseigner dans
}

value debe recuperarse en la interfaz Eulerian a través de la búsqueda en la Lista de tipos de ventas .
Retener: No debe utilizar directamente el método libellé del tipo de venta en la solicitud API. Faltó utilizar la técnica de identificación de hijo.


6. Recuperar los ID de los tipos de ventas

Para recuperar los ID de los tipos de ventas:
    Aller dans l'interface Eulerian.
    Utilice la barra de búsqueda en lo alto de la derecha.
    Busqueda en la lista de tipos de ventas .
    Identificador de los ID correspondientes a los tipos de ventas souhaités.
    Utilice estos ID en segmentFilterClauses.value .
Ejemplo:
"segmentFilterClauses": [
{
"field": "ordertype_id",
"operator": "IN",
"value": [
117,
135,
159
]
}
Les valeurs ci-dessus sont données à titre d'exmple. Es necesario adaptarlos al perímetro del cliente y a los tipos de ventanas visibles en la interfaz.
]




7. ID de los leviers média Eulerian

Los principales ID de leviers média son los siguientes:
ID
Levier
2
ENVÍO
3
PUBLICIDAD / Anuncios
4
AFILIACIÓN
5
ENLACE PATROCINADO / Gravámenes patrocinados
6
SOCIO / Partenariat
7
INTERNO
8
FUENTE DE CONFIANZA
10
HERRADA
16
DESCONECTADO
17
SOCIAL
20
GENÉRICO
Estos identificadores se pueden utilizar para comprobar o crear path relacionadas con las visualizaciones de contenido multimedia.


8. Identificadores de modelos de atribución aumentados

En el caso de los algoritmos de atribución, los identificadores son visibles en la interfaz euleriana, a través de la página Crear y editar mis modelos .
Esto le permitirá identificar el modelo de atribución utilizado en las vistas de informes.


9. Mejores prácticas para la integración de BI/almacenamiento de datos

Para industrializar el uso de la API de informes eulerianos, se recomienda lo siguiente:
  • partir de una vista existente en la interfaz euleriana para construir la solicitud de API;
  • recuperar el kind , path y los ID a través de la pestaña Red del navegador;
  • Programar las llamadas a la API a partir de las 06:00;
  • Utilice identificadores técnicos en lugar de etiquetas comerciales;
  • Utilice segmentFilterClauses para aplicar filtros específicos;
  • ejecutar varias consultas cuando la vista deseada combina varios perímetros;
  • agregar los resultados en el lado de BI, el almacén de datos o el script de procesamiento;
  • Conserve una marca de tiempo de extracción para facilitar la auditoría de datos.


10. Resumen Operativo

Sujet
Recommandation
Punto final
POST /ea/{site}/report/{batch}/query.json
Formato
JSON
Hora de lanzamiento recomendada
A partir de las 6:00 AM
Construcción de consultas
Partiendo de una vista existente en la interfaz
Recuperando el kind y path
A través de la pestaña Red del navegador.
Filtro de tipo de ventas
segmentFilterClauses con field: "ordertype_id"
Identificadores de tipo de venta
Para ser recuperado de la lista de tipos de venta
Identificadores de palanca de medios
Utilice esto para comprobar las path
Identificadores de modelos MTA aumentados
A través de la página de Creación y Edición de Plantillas
agregación compleja
Realice varias consultas y luego agrúpelas en el sistema de inteligencia empresarial (BI).


11. Cómo solicitar planes de medios

Para consultar planes de medios a través de la API de informes de Eulerian, se recomienda dividir la consulta en varias partes para que siga siendo viable y utilizable.
La mejor práctica consiste en realizar una consulta para cada canal de adquisición.
Cada solicitud sigue la misma estructura, pero con una path diferente dependiendo de la palanca deseada.
Levier d’acquisition
Path à utiliser
Mostrar
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[3].mcPUBLISHER
Envío
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[2].mcPUBLISHER
Social
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[17].mcPUBLISHER
MAR
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[5].mcPUBLISHER
Afiliación
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[4].mcPUBLISHER
En estos ejemplos:
  • mcWEBSITE[1] corresponde al sitio en cuestión;
  • mcMEDIAPLAN[1] corresponde al plan de medios objetivo;
  • mcMEDIA[x] corresponde a la palanca de adquisición;
  • mcPUBLISHER te permite acceder al nivel de soporte/editor.
Los identificadores deben adaptarse al contexto del cliente y al nivel de información deseado.

Ejemplo de consulta para la palanca de visualización

Ejemplo para la palanca Display , con vistas de atribución 3 , 8 y 6 , durante el período del 01/04/2026 al 31/05/2026 .
{
"async": false,
"reports": [
{
"kind": "rt#mediaplan",
"path": "mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[3].mcPUBLISHER",
"segments": [
{
"name": "Attribution rule",
"operator": "IN",
"type": "attributionrule",
"value": [
3,
8,
6
]
}
],
"dimensions": [
{
"field": "publisheralias_alias",
"name": "Support"
}
],
"metrics": [
{
"name": "Ventes réelles",
"field": "realscartvalid"
}
],
"dateRanges": [
{
"dateFrom": "2026-04-01",
"dateTo": "2026-05-31",
"dateFormat": "YYYY-MM-DD"
}
]
}
]
Para consultar otra palanca, simplemente utilice la misma estructura y reemplace el valor de la
}

path por la de la palanca deseada.
Por ejemplo, para el sudeste asiático, la path quedaría así:
Este enfoque ayuda a garantizar tiempos de respuesta óptimos, controlar mejor los volúmenes devueltos y facilitar la agregación de resultados en el lado de la inteligencia empresarial o del almacén de datos.
"path": "mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[5].mcPUBLISHER"



12. Recomendación: elija entre publisheralias_alias y publisher_name

Durante una consulta, puede ocurrir que la dimensión publisheralias_alias devuelva un valor vacío aunque haya métricas presentes.
Este comportamiento es normal y depende de cómo se haya implementado el seguimiento euleriano en las plataformas asociadas.

Diferencia entre publisheralias_alias y publisher_name

Cuando el seguimiento euleriano se implementa dentro de una plataforma de terceros, como un DSP, un servidor de anuncios o una plataforma de medios, los parámetros de seguimiento de la campaña no recopilan directamente el nombre del editor o de la campaña a través de una macro legible, por ejemplo:
En este caso, el seguimiento puede basarse en identificadores técnicos, por ejemplo:
ead-publisher={{publisher_name}}, qui deviendrait "lequipe.fr"

A continuación, Eulerian utiliza conectores EPC para asignar el ID recopilado en la configuración de seguimiento al editor o la etiqueta de campaña real tal como aparece en la plataforma de terceros.
ead-publisher={{publisher_id}}, qui deviendrait "1234"

Estas etiquetas revisadas se denominan alias en el lado euleriano. Se puede acceder a ellas a través de la dimensión:
{
"field": "publisheralias_alias",
"name": "Support"
Por el contrario, cuando el nombre del editor se envía directamente al seguimiento, sin necesidad de mapeo de conectores, se debe utilizar la siguiente dimensión:
}

{
"field": "publisher_name",
"name": "Support"
13. Uso
}


overwriteNameByAlias ​​para gestionar automáticamente los alias.

Para evitar tener que cambiar manualmente entre publisher_name y publisheralias_alias , puede utilizar la siguiente opción de API:
Esta opción le permite solicitar a la API que priorice el alias cuando exista, manteniendo el nombre original cuando el alias no esté disponible.
"overwriteNameByAlias": true

Aborda específicamente el siguiente caso:
  • Si el editor tiene un alias, la API devuelve el alias;
  • Si el editor no tiene un alias, la API devuelve el publisher_name .
Esto ayuda a limitar las líneas vacías en las exportaciones y a obtener una dimensión de "Soporte" que se puede utilizar de forma más directa en el lado de la inteligencia empresarial o del almacén de datos.

¿Dónde colocar la opción en la consulta?

La opción overwriteNameByAlias ​​debe agregarse a nivel de bloque de informe, al mismo nivel que kind , path , segments , dimensions , metrics y dateRanges .
Ejemplo sobre el factor social:
{
"async": false,
"reports": [
{
"kind": "rt#mediaplan",
"path": "mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[17].mcPUBLISHER",
"overwriteNameByAlias": true,
"segments": [
{
"name": "Attribution rule",
"operator": "IN",
"type": "attributionrule",
"value": [
3,
8,
6
]
}
],
"dimensions": [
{
"field": "publisher_name",
"name": "Support"
}
],
"metrics": [
{
"name": "Ventes réelles",
"field": "realscartvalid"
}
],
"dateRanges": [
{
"dateFrom": "2026-04-01",
"dateTo": "2026-05-31",
"dateFormat": "YYYY-MM-DD"
}
]
}
]
Dimensión a utilizar con esta opción
}




Cuando se activa overwriteNameByAlias , se recomienda utilizar la dimensión estándar publisher_name :
"dimensions": [
{
"field": "publisher_name",
"name": "Support"
}
La API se carga al aplicar el alias cuando el teléfono está disponible.
]

Este enfoque es más simple que el de solicitar por separado publisher_name y publisheralias_alias , para poder reconciliar los dos campeones entre BI.

Portée de l'option

La opción overwriteNameByAlias ​​no se aplica únicamente a los editores.
También puede aplicar otras dimensiones disponibles con un mecanismo de alias, por ejemplo:
Dimension brute
Alias potentiellement appliqué
publisher_name
alias del editor
ope_name
alias de campaña
creative_name
alias para la creación
Por lo tanto, esta opción permite obtener etiquetas más limpias y consistentes en las exportaciones de API cuando los conectores eulerianos utilizan alias.

Recomendación operativa

Para consultas por parte del soporte/editor:
    Utilice publisher_name como dimensión principal.
    Agregue "overwriteNameByAlias": true en el bloque de informe.
    Pruebe el resultado en las palancas donde coexisten las dos lógicas, en particular la Social.
    Mantenga esta opción si los soportes se recuperan correctamente con los alias esperados y sin líneas vacías injustificadas.
Esta opción resulta especialmente útil para la función social, donde algunas campañas pueden rastrearse mediante identificadores de socios y luego reprocesarse por alias, mientras que otras campañas pueden rastrearse manualmente con un nombre de editor ya disponible.