API de migración de la toma de decisiones decisioning-migration-api

En esta página: Utilice la API del servicio de migración de decisiones para mover objetos de administración de decisiones entre zonas protegidas con análisis de dependencia automatizado y compatibilidad con reversiones, de modo que pueda realizar la transición del contenido de las decisiones entre entornos preservando al mismo tiempo la integridad de los datos.

La API del servicio de migración de decisiones permite migrar objetos de administración de decisiones de una zona protegida a otra. El proceso de migración se ejecuta como flujos de trabajo asincrónicos que incluyen análisis de dependencia, ejecución y funciones de reversión opcionales.

Esta API le permite realizar una transición sin problemas del contenido de toma de decisiones entre entornos , manteniendo la integridad de los datos y las relaciones.

Para obtener más información sobre las ventajas y capacidades de la toma de decisiones en comparación con la administración de decisiones, consulte esta página.

Competencias capabilities

La API del servicio de migración de Decisioning proporciona las siguientes funcionalidades:

Requisitos previos prerequisites

Permisos necesarios permissions

Para utilizar la API de migración, necesita los permisos adecuados en los entornos limitados de origen y destino:

Entorno aislado de Source: acceso de lectura a los objetos de administración de decisiones

Entorno aislado de Target: cree y edite el acceso a los objetos de Decisioning

Los permisos habituales incluyen:

Preparación de la zona protegida de Target target-sandbox-preparation

Antes de ejecutar una migración, asegúrese de que la zona protegida de Target esté configurada correctamente:

Para obtener más información sobre la administración de zonas protegidas, consulte Usar y asignar zonas protegidas.

Requisitos previos de migración entre zonas protegidas cross-sandbox-prerequisites

Cuando la zona protegida de origen ≠ la de destino, se requieren los siguientes elementos:

Conceptos básicos de la API api-basics

URL base base-url

Utilice la siguiente URL base:

Autenticación authentication

Todas las solicitudes de API requieren los siguientes encabezados:

Para obtener instrucciones detalladas sobre cómo configurar la autenticación, consulte la guía de autenticación de Journey Optimizer.

Flujo de trabajo migración migration-workflow

El proceso de migración consta de dos pasos principales: analizar las dependencias y ejecutar la migración. Siga estos pasos para garantizar una migración correcta.

Paso 1: Análisis de dependencias analyze-dependencies

Antes de migrar, utilice el flujo de trabajo de dependencias para identificar qué debe asignarse desde Gestión de decisiones a Decisiones en la zona protegida de destino. Este análisis le ayuda a comprender las relaciones entre los objetos y a preparar las asignaciones necesarias.

Creación de un flujo de trabajo de dependencias create-dependency-workflow

Utilice la siguiente llamada de API para crear un flujo de trabajo de análisis de dependencias.

Formato de API

POST /workflows/generate-dependencies

Dependencia a nivel de espacio aislado (recomendada primero)

Comience con un análisis a nivel de zona protegida para obtener una vista completa de todas las dependencias:

curl --request POST \
  --url "https://decisioning-migration.adobe.io/workflows/generate-dependencies?request-level=sandbox" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "Content-Type: application/json" \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" }
  }'

Dependencia de nivel de oferta

Para analizar dependencias solo para ofertas específicas, llame al mismo extremo con request-level=offer en la cadena de consulta y proporcione una matriz offersList en el cuerpo con los ID de oferta que desee analizar.

Dependencia de nivel de decisión

Para analizar dependencias únicamente para decisiones específicas, use request-level=decision en la cadena de consulta y proporcione una matriz decisionsList en el cuerpo con los identificadores de decisión que desee analizar.

Comprobar estado de flujo de trabajo de dependencia poll-dependency-status

Encueste el flujo de trabajo de dependencias para comprobar cuándo se ha completado el análisis.

Formato de API

GET /workflows/generate-dependencies/{id}

Solicitud

curl --request GET \
  --url "https://decisioning-migration.adobe.io/workflows/generate-dependencies/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>"

Cuando el campo status muestra Completed, el análisis de dependencias está listo. Utilice la salida del flujo de trabajo para crear las asignaciones de dependencias de migración:

Proporcione estas asignaciones en el objeto dependency de la solicitud de migración en el paso 2.

Paso 2: Ejecución de la migración execute-migration

Una vez que haya analizado las dependencias y preparado las asignaciones, puede ejecutar la migración.

Creación de un flujo de trabajo de migración create-migration-workflow

Utilice las asignaciones de dependencias del paso 1 para configurar y ejecutar la migración.

Formato de API

POST /workflows/migration

Migración a nivel de espacio aislado

Para migrar todos los objetos de toma de decisiones de una zona protegida a otra:

curl --request POST \
  --url 'https://decisioning-migration.adobe.io/workflows/migration?request-level=sandbox' \
  --header 'Authorization: Bearer <IMS_ACCESS_TOKEN>' \
  --header 'Content-Type: application/json' \
  --header 'x-gw-ims-org-id: <IMS_ORG_ID>' \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" },
    "createDataStream": true,
    "dependency": {
      "profileAttributes": {
        "sourceAttr1": "targetAttr1"
      },
      "segments": {
        "sourceSegmentKey1": {
          "namespace": "<TARGET_SEGMENT_NAMESPACE>",
          "id": "<TARGET_SEGMENT_ID>"
        }
      },
      "contextAttributes": {
        "sourceCtx1": "targetCtx1"
      },
      "datasetName": "<TARGET_DATASET_NAME>"
    }
  }'

Migración de nivel de oferta

Para migrar solamente ofertas específicas, use request-level=offer en la cadena de consulta y agregue una matriz offersList al cuerpo:

"offersList": ["offer-id-1", "offer-id-2"]

Migración de nivel de decisión

Para migrar únicamente decisiones específicas, use request-level=decision en la cadena de consulta y agregue una matriz decisionsList al cuerpo:

"decisionsList": ["decision-id-1", "decision-id-2"]

Campos de solicitud

Monitorización del estado de migración poll-migration-status

Encueste el flujo de trabajo de migración para rastrear su progreso.

Formato de API

GET /workflows/migration/{id}

Solicitud

curl --request GET \
  --url "https://decisioning-migration.adobe.io/workflows/migration/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>"

Resultados de la migración

Cuando el campo status muestra Completed, la migración se realizó correctamente. El flujo de trabajo result incluye:

Cuando el campo status muestre Failed, revise la matriz errors[] y el campo result.error para obtener detalles sobre qué ha fallado.

Cada flujo de trabajo (dependencia, migración y reversión) devuelve los mismos campos de recurso:

Validación de la migración validate-migration

Una vez completada la migración correctamente, compruebe que todos los objetos se hayan migrado correctamente.

Lista de comprobación de validación validation-checklist

Ejemplo test-runtime-delivery

Si la migración ha creado un conjunto de datos, se puede probar la entrega de ofertas con el siguiente ejemplo:

curl --request POST \
  --url "https://edge.adobedc.net/ee/or2/v1/interact?configId=<DATASTREAM_ID>" \
  --header "Content-Type: application/json" \
  --header "x-request-id: <uuid>" \
  --data '{ "events": [ ... ] }'

Reversión de una migración rollback

Si detecta problemas durante la validación, puede revertir una migración completada para restaurar la zona protegida de destino a su estado anterior.

Creación de un flujo de trabajo de reversión create-rollback-workflow

Inicie una reversión creando un flujo de trabajo de reversión que haga referencia a la migración que desea revertir.

Formato de API

POST /workflows/rollback

Solicitud

curl --request POST \
  --url "https://decisioning-migration.adobe.io/workflows/rollback" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "Content-Type: application/json" \
  --data '{ "rollbackWorkflowId": "<MIGRATION_WORKFLOW_ID>" }'

Reemplace <MIGRATION_WORKFLOW_ID> por el ID del flujo de trabajo de migración que desea revertir.

Monitorizar estado de reversión poll-rollback-status

Encuesta el flujo de trabajo de reversión para rastrear su progreso.

Formato de API

GET /workflows/rollback/{rollbackWorkflowId}

Solicitud

curl --request GET \
  --url "https://decisioning-migration.adobe.io/workflows/rollback/<ROLLBACK_WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>"

Gestión de flujos de trabajo simultáneos handle-concurrency

La API de migración solo permite ejecutar un flujo de trabajo a la vez por organización. Si intenta crear un nuevo flujo de trabajo mientras otro está en curso, recibirá una respuesta de error 409 Conflict (“Ya hay un flujo de trabajo en curso…”).

En este caso, espere a que se complete el flujo de trabajo en curso o recupere el ID de flujo de trabajo y sondee su estado. Una vez finalizado el flujo de trabajo actual, puede crear uno nuevo.

Alcance y cobertura de la migración migration-scope

Comprender el ámbito de la migración le ayuda a planificar y validar la transición de la gestión de decisiones a la toma de decisiones. En esta sección se describe qué cubre el proceso de migración y qué requiere una acción manual.

En el ámbito: Aspectos cubiertos in-scope

La API de migración gestiona los siguientes elementos y funcionalidades:

Fuera del ámbito: elementos que no están cubiertos o que requieren una acción manual out-of-scope

Los siguientes elementos requieren una acción manual o no son compatibles con las herramientas de migración:

Referencia de asignación de entidad entity-mapping

Al migrar de Administración de decisiones a Toma de decisiones, las entidades se asignan según la siguiente tabla. Las asignaciones incluyen las entidades Decisioning principales y las entidades asociadas adicionales creadas o utilizadas durante la migración.

Administración de decisiones para la asignación de entidades de decisiones

Convenciones de nomenclatura

El proceso de migración aplica convenciones de nomenclatura utilizando el prefijo ExD_ para garantizar la coherencia y evitar conflictos de nomenclatura.

Atributos adicionales

Modelo de solicitud y respuesta request-response-model

Al migrar de Administración de decisiones a Toma de decisiones, el código de la aplicación debe actualizarse para utilizar los nuevos formatos de solicitud y respuesta. Ambos sistemas utilizan el extremo de Edge Network, pero con diferentes estructuras de carga útil y nombres de campo.

Solicitud Edge de gestión de decisiones (actual) dm-request

La solicitud de Edge actual de Administración de decisiones sigue esta estructura:

Punto final:

POST https://edge.adobedc.net/ee/v2/interact

Encabezados:
​- Authorization: Bearer <IMS_ACCESS_TOKEN>
​- x-api-key: <API_KEY> (de Developer Console)
​- x-gw-ims-org-id: <IMS_ORG_ID> (formato: {ORG_ID}@AdobeOrg)
​- x-request-id: <UNIQUE_REQUEST_ID> (para seguimiento y deduplicación)
​- Content-Type: application/vnd.adobe.xdm+json; schema="…/decision-request;version=1.0"
​- Accept: application/vnd.adobe.xdm+json; schema="…/decision-response;version=1.0"
​- x-sandbox-name: <SANDBOX_NAME> (por ejemplo, prod, dev)

Parámetros de cuerpo de solicitud:
​- xdm:dryRun (true/false): solicitudes de prueba sin informes contaminantes
​- xdm:propositionRequests[] - Matriz de solicitudes de decisión:
​- activityId - Identificador de actividad de decisión
​- placementId - Identificador de ubicación
​- itemCount: número máximo de ofertas que se devolverán
​- xdm:profiles[].xdm:identityMap: asignación de identidad (correo electrónico, ECID, etc.)
​- xdm:validateContextData - Indicador de validación de datos de contexto estricto
​- xdm:responseFormat.xdm:includeContent: incluir contenido real frente a solo ID

Cuerpo de solicitud de ejemplo:

{
  "xdm": {
    "dryRun": false,
    "propositionRequests": [
      { "activityId": "<ACTIVITY_ID>", "placementId": "<PLACEMENT_ID>", "itemCount": 3 }
    ],
    "profiles": [
      { "identityMap": { "ECID": [ { "id": "<ECID>", "primary": true } ] } }
    ],
    "validateContextData": true,
    "responseFormat": { "includeContent": true }
  }
}

Decisión de una solicitud de Edge (después de la migración) decisioning-request

Después de la migración, utilice el formato de solicitud de Decisioning a través del mismo punto de conexión de Edge Network.

Punto final:

POST https://edge.adobedc.net/ee/v2/interact

Campos de solicitud de clave:
​- query.identity.fetch: matriz de tipos de identidad para resolver (por ejemplo, ["ECID"])
​- event.xdm.environment.type - Tipo de entorno: "browser", "app" o "server"
​- event.xdm.environment.browserDetails - Metadatos del explorador (viewportWidth, viewportHeight, userAgent)
​- event.xdm.identityMap - Misma asignación de identidad que Administración de decisiones
​- event.xdm.timestamp - Marca de tiempo ISO 8601
​- query.personalization.surfaces - Matriz de superficies de destino (por ejemplo, ["web://site.com/homepage"]) — reemplaza a decisionScope
​- query.personalization.schemas - Esquemas de contenido para devolver (por ejemplo, ["json-content-item", "html-content-item"])
​- data.__adobe.ajo.allowDuplicateDecisionItems - Control de deduplicación (el valor predeterminado es true; establezca false de modo que un elemento que cumpla los requisitos para varias superficies se devuelva solo una vez, y las demás superficies recibirán un elemento de reserva o vacío). Reemplaza la Administración de decisiones allowDuplicatePropositions.
​- data.__adobe.ajo.dryRun - Indicador de prueba; suprime los eventos de comentarios tanto para los contadores de informes como de límite. Reemplaza la Administración de decisiones xdm:dryRun. Eliminar antes de producción.

Cuerpo de solicitud de ejemplo (lado del servidor):

{
  "events": [
    {
      "query": {
        "identity": { "fetch": ["ECID"] },
        "personalization": {
          "surfaces": ["web://my-web/IP_NLI_HP_GET_LOAN_WIDGET"],
          "schemas": [
            "https://ns.adobe.com/personalization/json-content-item",
            "https://ns.adobe.com/personalization/html-content-item"
          ]
        }
      },
      "xdm": {
        "eventType": "decisioning.propositionFetch",
        "environment": {
          "type": "browser",
          "browserDetails": { "viewportWidth": 1280, "viewportHeight": 900, "userAgent": "<USER_AGENT>" }
        },
        "identityMap": {
          "ECID": [ { "id": "<ECID>", "authenticatedState": "ambiguous", "primary": true } ]
        },
        "timestamp": "2025-09-08T12:00:00.000Z"
      },
      "data": {
        "__adobe": { "ajo": { "allowDuplicateDecisionItems": false } }
      }
    }
  ],
  "meta": {
    "state": {
      "domain": "my-web",
      "cookiesEnabled": true,
      "entries": [
        { "key": "kndctr_<ORG>_AdobeOrg_identity", "value": "<identity-cookie>" },
        { "key": "kndctr_<ORG>_AdobeOrg_cluster", "value": "<cluster-cookie>" }
      ]
    }
  }
}

Decidir la respuesta de Edge decisioning-response

La respuesta de Decisioning contiene varios identificadores organizados por tipo de problema: personalization:decisions (las ofertas), locationHint:result y state:store (las cookies que se van a mantener).

Estructura de respuesta:

{
  "requestId": "<REQUEST_ID>",
  "handle": [
    {
      "type": "personalization:decisions",
      "eventIndex": 0,
      "payload": [
        {
          "id": "103ae599-e6d8-4631-baf3-51dd8c6ed4c1",
          "scope": "web://my-web/IP_NLI_HP_GET_LOAN_WIDGET",
          "scopeDetails": {
            "decisionProvider": "AJO",
            "correlationID": "<CORRELATION_ID>",
            "characteristics": {
              "eventToken": "<base64 message-level event token>",
              "subPropositions": "<base64-encoded array of decision items>"
            },
            "rank": 1,
            "activity": {
              "id": "<campaignId>#<actionId>",
              "priority": 0,
              "matchedSurfaces": ["web://my-web/IP_NLI_HP_GET_LOAN_WIDGET"]
            }
          },
          "items": [
            {
              "id": "36646bab-af1b-44c6-b632-bbfb9c357919",
              "schema": "https://ns.adobe.com/personalization/json-content-item",
              "data": { "content": "{ ...offer JSON... }" }
            }
          ]
        }
      ]
    },
    {
      "type": "locationHint:result",
      "payload": [
        { "scope": "EdgeNetwork", "hint": "ind1", "ttlSeconds": 1800 }
      ]
    },
    {
      "type": "state:store",
      "payload": [
        { "key": "kndctr_<ORG>_AdobeOrg_cluster", "value": "<cluster-cookie>", "maxAge": 1800 },
        { "key": "kndctr_<ORG>_AdobeOrg_identity", "value": "<identity-cookie>", "maxAge": 34128000 }
      ]
    }
  ]
}

Campos de respuesta clave:
​- handle[].type - Tipo de identificador (personalization:decisions, locationHint:result, state:store)
​- payload[].id - ID de instancia de propuesta única — Eco de nuevo en los eventos de visualización/interacción
​- payload[].scope: URI de superficie para el que se resolvió la propuesta
​- payload[].scopeDetails.decisionProvider - Confirma que el motor es AJO
​- payload[].scopeDetails.correlationID: vincula la instancia de decisión con el evento de servicio
​- payload[].scopeDetails.rank / payload[].scopeDetails.activity - Metadatos de clasificación, campaña y acción de la propuesta
​- payload[].scopeDetails.characteristics.eventToken - Token de seguimiento de nivel de mensaje
​- payload[].scopeDetails.characteristics.subPropositions - matriz de elementos de decisión codificada en Base64; cada elemento lleva su propio elemento por elemento token. Estos tokens por elemento son lo que se pasa en propositionAction.tokens en eventos de visualización/interacción
​- payload[].items[].schema / payload[].items[].data.content: esquema de contenido y contenido de oferta real (JSON/HTML) que se procesarán
​- state:store carga: las cookies de identidad y de clúster que se mantendrán y reenviarán en solicitudes posteriores (del lado del servidor)

La cadena characteristics.subPropositions base64-descodifica la matriz de elementos servidos, cada uno con su valor por elemento token:

[
  {
    "id": "1ae75277-8832-4c23-bbbc-09f01cfe6c8b",
    "scope": "web://my-web/IP_NLI_HP_GET_LOAN_WIDGET",
    "scopeDetails": { "decisionProvider": "EXD", "correlationID": "<CORRELATION_ID>-0", "rank": 1 },
    "items": [
      { "id": "dps:<schema>:1be64ff83a612488", "name": "ExD_Personal Loan Offer", "score": 997.0, "token": "CLaefQnVLcLbCtzEXV3Jeg" },
      { "id": "dps:<schema>:1be6516838e1248c", "name": "ExD_Home Loan Offer",     "score": 995.0, "token": "ALlB5KV1B0e+CpHoahi7Ew" },
      { "id": "dps:<schema>:1be650da3cd06e98", "name": "ExD_Auto Loan Offer",     "score": 994.0, "token": "koJTRQcwFkR92AqbZ88ytQ" },
      { "id": "dps:<schema>:1be65612d5a1248d", "name": "ExD_Fallback Offer",      "itemSelection": { "selectionDetail": { "selectionType": "fallback" } }, "token": "GHo4ow7h6iCzBOhYR1+6jg" }
    ]
  }
]

Patrones de implementación implementation-patterns

Decisioning admite tres enfoques de implementación:

Implementación del lado del cliente (SDK web/SDK móvil) client-side

Web SDK o Mobile SDK gestiona automáticamente todas las solicitudes y la administración de cookies. SDK almacena y reenvía las cookies de identidad y de clúster con cada solicitud.

Administración de cookies: Automática: Web SDK administra las cookies kndctr_<OrgId>_identity y kndctr_<OrgId>_cluster.

Implementación del lado del servidor (API de Edge Network) server-side

El servidor de aplicaciones realiza POST directamente en Edge Network y debe administrar manualmente el reenvío de cookies. El servidor extrae las cookies del explorador de las solicitudes entrantes, las reenvía a Edge Network a través de meta.state.entries[] y, a continuación, devuelve las cookies en la respuesta.

Administración de cookies: Manual: el servidor de aplicaciones debe extraer las cookies de la solicitud del explorador, reenviarlas a Edge Network en el cuerpo de la solicitud y configurarlas como respuesta. Las cookies deben reenviarse explícitamente en meta.state.entries para mantener la coherencia de la identidad.

Implementación híbrida hybrid

Combina el procesamiento del lado del servidor (carga inicial de página) con SDK del lado del cliente (interacciones subsiguientes). El servidor procesa el contenido inicial mediante Edge Network y, a continuación, Web SDK asume el control para las solicitudes de personalización posteriores.

Administración de cookies: mixta: el lado del servidor requiere el reenvío manual de cookies a Edge Network; el lado del cliente se administra automáticamente mediante Web SDK. Asegúrese de que los tokens de identidad del procesamiento del lado del servidor estén disponibles para SDK del lado del cliente para una resolución de identidad coherente.

Seguimiento de eventos y recopilación de datos event-tracking

Para atribuir correctamente los resultados de las decisiones, habilitar la restricción de frecuencia y activar la optimización de clasificación basada en IA, debe implementar el seguimiento de eventos mediante el esquema de eventos Decisioning.

Campos de evento obligatorios event-fields

Se requieren eventType y _experience.decisioning.propositionEventType. Si falta alguna de las dos, el contador de visualización/interacción correspondiente no se incrementa.

Requisitos de esquema schema-requirements

Asocie el grupo de campos Decisioning al esquema del conjunto de datos de evento antes de la migración:

Administración de tokens de seguimiento tracking-token

El token de seguimiento debe gestionarse de acuerdo con estos requisitos:

Ejemplos de eventos de decisiones event-examples

Cada ejemplo hace eco de la propuesta servida (incluido su scopeDetails, que lleva characteristics.subPropositions) y establece eventType y propositionEventType. Los contadores se incrementan en los elementos de subPropositions; propositionAction.tokens selecciona qué elementos.

Mostrar eventos

Mostrar eventos notificar a Decisioning cuando se muestra una oferta a un usuario. Proporcione los token de los elementos mostrados u omita tokens para aumentar el contador de visualización de todos los elementos en subPropositions:

{
  "header": {
    "imsOrgId": "YOUR_ORG_ID",
    "sandboxId": "sandbox-id",
    "sandboxName": "sandbox-name",
    "source": { "name": "ajo-inbound" }
  },
  "body": {
    "xdmEntity": {
      "identityMap": {
        "ECID": [ { "id": "ecid-123", "primary": true } ]
      },
      "eventType": "decisioning.propositionDisplay",
      "_experience": {
        "decisioning": {
          "propositionEventType": { "display": 1 },
          "propositionAction": {
            "id": "b96f842b-5dd9-4c55-9dae-647d96250028",
            "tokens": ["CLaefQnVLcLbCtzEXV3Jeg", "ALlB5KV1B0e+CpHoahi7Ew"]
          },
          "propositions": [
            {
              "id": "103ae599-e6d8-4631-baf3-51dd8c6ed4c1",
              "scope": "web://my-web/IP_NLI_HP_GET_LOAN_WIDGET",
              "scopeDetails": {
                "decisionProvider": "AJO",
                "characteristics": {
                  "eventToken": "<base64 eventToken from response>",
                  "subPropositions": "<base64 subPropositions from response>"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Eventos de interacción (clic)

Los eventos de interacción rastrean cuándo un usuario hace clic o interactúa con una oferta mostrada. Usted debe proporcionar exactamente un token que identifique el elemento en el que se hizo clic:

{
  "header": {
    "imsOrgId": "YOUR_ORG_ID",
    "sandboxId": "sandbox-id",
    "sandboxName": "sandbox-name",
    "source": { "name": "ajo-inbound" }
  },
  "body": {
    "xdmEntity": {
      "identityMap": {
        "ECID": [ { "id": "ecid-123", "primary": true } ]
      },
      "eventType": "decisioning.propositionInteract",
      "_experience": {
        "decisioning": {
          "propositionEventType": { "interact": 1 },
          "propositionAction": {
            "id": "b96f842b-5dd9-4c55-9dae-647d96250028",
            "tokens": ["CLaefQnVLcLbCtzEXV3Jeg"]
          },
          "propositions": [
            {
              "id": "103ae599-e6d8-4631-baf3-51dd8c6ed4c1",
              "scope": "web://my-web/IP_NLI_HP_GET_LOAN_WIDGET",
              "scopeDetails": {
                "decisionProvider": "AJO",
                "characteristics": {
                  "eventToken": "<base64 eventToken from response>",
                  "subPropositions": "<base64 subPropositions from response>"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Eventos personalizados

Un evento personalizado usa un eventType definido por el cliente (cualquier valor que no sea decisioning.proposition<Display|Interact|Dismiss>) y establece todo display/interact/dismiss en 0 en propositionEventType (clasificado como OTHER). Los eventos personalizados se descodifican como eventos de visualización (filtrado de múltiples tokens) con subPropositions y se evalúan mediante el PQL configurado:

{
  "header": {
    "imsOrgId": "YOUR_ORG_ID",
    "sandboxId": "sandbox-id",
    "sandboxName": "sandbox-name",
    "originalTimestamp": 1700000
  },
  "body": {
    "xdmEntity": {
      "identityMap": {
        "ECID": [ { "id": "ecid-123", "primary": true } ]
      },
      "eventType": "add-to-cart",
      "_experience": {
        "decisioning": {
          "propositionEventType": { "display": 0, "interact": 0, "dismiss": 0 },
          "propositionAction": {
            "id": "b96f842b-5dd9-4c55-9dae-647d96250028",
            "tokens": ["CLaefQnVLcLbCtzEXV3Jeg"]
          },
          "propositions": [
            {
              "id": "103ae599-e6d8-4631-baf3-51dd8c6ed4c1",
              "scope": "web://my-web/IP_NLI_HP_GET_LOAN_WIDGET",
              "scopeDetails": {
                "decisionProvider": "AJO",
                "characteristics": {
                  "eventToken": "<base64 eventToken from response>",
                  "subPropositions": "<base64 subPropositions from response>"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Estos eventos permiten la restricción de frecuencia, la creación de informes predeterminados y la optimización de clasificación impulsada por IA en Decisioning. Para enviar eventos de propuesta con Web SDK, consulte Experiencia basada en código: Implementaciones de decisiones.

Proceso de migración de extremo a extremo migration-process

Temas relacionados related-topics