API della migrazione a Decisioning decisioning-migration-api

In questa pagina: utilizza l’API del servizio di migrazione Decisioning per spostare gli oggetti di gestione delle decisioni tra sandbox con l’analisi automatizzata delle dipendenze e il supporto del rollback, in modo da poter trasferire il contenuto decisionale tra gli ambienti mantenendo l’integrità dei dati.

L’API del servizio di migrazione di Decisioning consente di migrare gli oggetti di gestione delle decisioni da una sandbox all’altra. Il processo di migrazione viene eseguito come flussi di lavoro asincroni che includono l’analisi delle dipendenze, l’esecuzione e le funzionalità di rollback facoltative.

Questa API consente di passare facilmente al contenuto decisionale tra gli ambienti , mantenendo al contempo l’integrità dei dati e le relazioni.

Per informazioni sui vantaggi e le funzionalità di Decisioning rispetto alla gestione delle decisioni, consulta questa pagina.

Funzionalità capabilities

L’API del servizio di migrazione Decisioning fornisce le seguenti funzionalità:

Prerequisiti prerequisites

Autorizzazioni richieste permissions

Per utilizzare l’API di migrazione, è necessario disporre delle autorizzazioni appropriate sia nella sandbox di origine che in quella di destinazione:

Sandbox Source - Accesso in lettura agli oggetti di gestione delle decisioni

Sandbox di destinazione - Crea e modifica l’accesso agli oggetti Decisioning

Le autorizzazioni tipiche includono:

Preparare la sandbox di destinazione target-sandbox-preparation

Prima di eseguire una migrazione, assicurati che la sandbox di destinazione sia configurata correttamente:

Per ulteriori informazioni sulla gestione delle sandbox, consulta Utilizzare e assegnare le sandbox.

Prerequisiti per la migrazione tra sandbox cross-sandbox-prerequisites

Quando la sandbox di origine ≠ la sandbox di destinazione, sono necessari i seguenti elementi:

Nozioni di base sulle API api-basics

URL di base base-url

Utilizza il seguente URL di base:

Autenticazione authentication

Tutte le richieste API richiedono le seguenti intestazioni:

Per istruzioni dettagliate sulla configurazione dell’autenticazione, fare riferimento alla guida all’autenticazione di Journey Optimizer.

Flusso di lavoro di migrazione migration-workflow

Il processo di migrazione consiste in due passaggi principali: analisi delle dipendenze ed esecuzione della migrazione. Per eseguire correttamente la migrazione, segui la procedura riportata di seguito.

Passaggio 1: Analizzare le dipendenze analyze-dependencies

Prima di eseguire la migrazione, utilizza il flusso di lavoro delle dipendenze per identificare gli elementi da mappare da Gestione decisioni a Decisioning nella sandbox di destinazione. Questa analisi consente di comprendere le relazioni tra gli oggetti e di preparare le mappature necessarie.

Creare un flusso di lavoro di dipendenza create-dependency-workflow

Utilizza la seguente chiamata API per creare un flusso di lavoro di analisi delle dipendenze.

Formato API

POST /workflows/generate-dependencies

Dipendenza a livello di sandbox (prima consigliata)

Inizia con un’analisi a livello di sandbox per ottenere una visualizzazione completa di tutte le dipendenze:

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>" }
  }'

Dipendenza a livello di offerta

Per analizzare le dipendenze solo per offerte specifiche, chiama lo stesso endpoint con request-level=offer nella stringa di query e fornisci un array offersList nel corpo con gli ID offerta da analizzare.

Dipendenza a livello di decisione

Per analizzare le dipendenze solo per decisioni specifiche, utilizzare request-level=decision nella stringa di query e fornire un array decisionsList nel corpo con gli ID di decisione che si desidera analizzare.

Verifica stato del flusso di lavoro delle dipendenze poll-dependency-status

Esegue il polling del flusso di lavoro delle dipendenze per verificare il completamento dell’analisi.

Formato API

GET /workflows/generate-dependencies/{id}

Richiesta

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>"

Quando il campo status mostra Completed, l’analisi della dipendenza è pronta. Utilizza l’output del flusso di lavoro per creare i mapping delle dipendenze di migrazione:

Fornisci queste mappature nell’oggetto dependency della richiesta di migrazione nel passaggio 2.

Passaggio 2: eseguire la migrazione execute-migration

Dopo aver analizzato le dipendenze e preparato le mappature, puoi eseguire la migrazione.

Creare un flusso di lavoro di migrazione create-migration-workflow

Utilizza i mapping delle dipendenze dal passaggio 1 per configurare ed eseguire la migrazione.

Formato API

POST /workflows/migration

Migrazione a livello di sandbox

Per migrare tutti gli oggetti decisioning da una sandbox all’altra:

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>"
    }
  }'

Migrazione a livello di offerta

Per migrare solo offerte specifiche, utilizza request-level=offer nella stringa di query e aggiungi un array offersList al corpo:

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

Migrazione a livello di decisione

Per migrare solo decisioni specifiche, utilizza request-level=decision nella stringa di query e aggiungi un array decisionsList al corpo:

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

Campi richiesta

Monitorare lo stato della migrazione poll-migration-status

Esegui il polling del flusso di lavoro di migrazione per tracciarne l’avanzamento.

Formato API

GET /workflows/migration/{id}

Richiesta

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>"

Risultati migrazione

Quando il campo status mostra Completed, la migrazione è riuscita. Il flusso di lavoro result include:

Quando il campo status mostra Failed, controlla l’array errors[] e il campo result.error per i dettagli sul problema.

Ogni flusso di lavoro (dipendenza, migrazione e rollback) restituisce gli stessi campi di risorse:

Convalidare la migrazione validate-migration

Al termine della migrazione, verificare che tutti gli oggetti siano stati migrati correttamente.

Elenco di controllo per la convalida validation-checklist

Esempio test-runtime-delivery

Se la migrazione ha creato un flusso di dati, puoi testare la consegna delle offerte utilizzando il seguente esempio:

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": [ ... ] }'

Ripristino dello stato precedente di una migrazione rollback

Se riscontri dei problemi durante la convalida, puoi eseguire il rollback di una migrazione completata per ripristinare lo stato precedente della sandbox di destinazione.

Creare un flusso di lavoro di rollback create-rollback-workflow

Avvia un rollback creando un flusso di lavoro di rollback che faccia riferimento alla migrazione da ripristinare.

Formato API

POST /workflows/rollback

Richiesta

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>" }'

Sostituire <MIGRATION_WORKFLOW_ID> con l’ID del flusso di lavoro di migrazione di cui si desidera eseguire il rollback.

Monitora stato rollback poll-rollback-status

Esamina il flusso di lavoro di rollback per tenerne traccia dell’avanzamento.

Formato API

GET /workflows/rollback/{rollbackWorkflowId}

Richiesta

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>"

Gestire flussi di lavoro simultanei handle-concurrency

L’API di migrazione consente di eseguire un solo flusso di lavoro alla volta per organizzazione. Se tenti di creare un nuovo flusso di lavoro mentre ne è in corso un altro, riceverai una risposta di errore 409 (“Un flusso di lavoro è già in corso…”).

In questo caso, attendi il completamento del flusso di lavoro in corso oppure recupera l’ID del flusso di lavoro ed esegui il polling del relativo stato. Al termine del flusso di lavoro corrente, puoi crearne uno nuovo.

Ambito e copertura della migrazione migration-scope

Comprendere l’ambito della migrazione consente di pianificare e convalidare la transizione da Gestione delle decisioni a Decisioning. Questa sezione descrive cosa è coperto dal processo di migrazione e cosa richiede un’azione manuale.

In-Scope: cosa è coperto in-scope

L’API di migrazione gestisce i seguenti elementi e funzionalità:

Fuori ambito: cosa non è coperto o richiede un’azione manuale out-of-scope

Gli elementi seguenti richiedono un’azione manuale o non sono supportati dagli strumenti di migrazione:

Riferimento mapping entità entity-mapping

Durante la migrazione da Gestione decisioni a Decisioning, le entità vengono mappate in base alla tabella seguente. I mapping includono le entità decisioning primarie e altre entità associate create o utilizzate durante la migrazione.

Mappatura entità da gestione delle decisioni a decisioning

Convenzioni di denominazione

Il processo di migrazione applica le convenzioni di denominazione utilizzando il prefisso ExD_ per garantire la coerenza ed evitare conflitti di denominazione.

Attributi aggiuntivi

Modello di richiesta e risposta request-response-model

Durante la migrazione da Gestione decisioni a Decisioning, il codice dell’applicazione deve essere aggiornato per utilizzare i nuovi formati di richiesta e risposta. Entrambi i sistemi utilizzano l’endpoint Edge Network, ma con strutture di payload e nomi di campo diversi.

Richiesta Edge di gestione delle decisioni (corrente) dm-request

L’attuale richiesta Edge di gestione delle decisioni segue questa struttura:

Endpoint:

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

Intestazioni:
​- Authorization: Bearer <IMS_ACCESS_TOKEN>
​- x-api-key: <API_KEY> (da Developer Console)
​- x-gw-ims-org-id: <IMS_ORG_ID> (formato: {ORG_ID}@AdobeOrg)
​- x-request-id: <UNIQUE_REQUEST_ID> (per traccia e deduplicazione)
​- 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> (ad esempio, prod, dev)

Parametri corpo richiesta:
​- xdm:dryRun (true/false) - Verifica le richieste senza rapporti inquinanti
​- xdm:propositionRequests[] - Array di richieste di decisione:
​- activityId - Identificatore attività decisione
​- placementId - Identificatore di posizionamento
​- itemCount - Numero massimo di offerte da restituire
​- xdm:profiles[].xdm:identityMap - Mappatura identità (e-mail, ECID, ecc.)
​- xdm:validateContextData - Flag di convalida dei dati di contesto rigoroso
​- xdm:responseFormat.xdm:includeContent - Includi solo contenuto effettivo e ID

Esempio di corpo della richiesta:

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

Decisioning della richiesta di Edge (dopo la migrazione) decisioning-request

Dopo la migrazione, utilizza il formato di richiesta Decisioning tramite lo stesso endpoint Edge Network.

Endpoint:

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

Campi richiesta chiave:
​- query.identity.fetch - Array di tipi di identità da risolvere (esempio: ["ECID"])
​- event.xdm.environment.type - Tipo di ambiente: "browser", "app" o "server"
​- event.xdm.environment.browserDetails - Metadati browser (viewportWidth, viewportHeight, userAgent)
​- event.xdm.identityMap - Stessa mappatura identità come gestione delle decisioni
​- event.xdm.timestamp - Timestamp ISO 8601
​- query.personalization.surfaces - Array di superfici di destinazione (ad esempio, ["web://site.com/homepage"]) — sostituisce decisionScope
​- query.personalization.schemas - Schemi di contenuto da restituire (esempio: ["json-content-item", "html-content-item"])
​- data.__adobe.ajo.allowDuplicateDecisionItems - Controllo di deduplicazione (impostazione predefinita: true; impostazione di false in modo che un elemento idoneo per più superfici venga restituito una sola volta, mentre le altre superfici ricevono un elemento vuoto o di fallback). Sostituisce la gestione delle decisioni allowDuplicatePropositions.
​- data.__adobe.ajo.dryRun - Flag di test; sopprime gli eventi di feedback sia per i contatori di reporting che per i contatori di limitazione. Sostituisce la gestione delle decisioni xdm:dryRun. Rimuovi prima della produzione.

Esempio di corpo della richiesta (lato server):

{
  "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>" }
      ]
    }
  }
}

Decisioning della risposta di Edge decisioning-response

La risposta di Decisioning contiene più handle organizzati per tipo di problema: personalization:decisions (le offerte), locationHint:result e state:store (i cookie da mantenere).

Struttura risposta:

{
  "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 }
      ]
    }
  ]
}

Campi risposta chiave:
​- handle[].type - Tipo di handle (personalization:decisions, locationHint:result, state:store)
​- payload[].id - ID istanza proposta univoco — esegui l’eco sugli eventi di visualizzazione/interazione
​- payload[].scope - URI di superficie per cui è stata risolta la proposta
​- payload[].scopeDetails.decisionProvider - Conferma motore: AJO
​- payload[].scopeDetails.correlationID - Collega l’istanza di decisione all’evento di servizio
​- payload[].scopeDetails.rank / payload[].scopeDetails.activity - Classificazione e metadati campagna/azione per la proposta
​- payload[].scopeDetails.characteristics.eventToken - Token di tracciamento a livello di messaggio
​- payload[].scopeDetails.characteristics.subPropositions - Array con codifica Base64 degli elementi decisionali; ogni elemento ha il proprio token per elemento. Questi token per elemento sono ciò che trasmetti in propositionAction.tokens sugli eventi di visualizzazione/interazione
​- payload[].items[].schema / payload[].items[].data.content - Schema del contenuto e contenuto dell’offerta effettiva (JSON/HTML) da riprodurre
​- Payload state:store: cookie di identità e cluster da mantenere e inoltrare nelle richieste successive (lato server)

La stringa characteristics.subPropositions base64-decodifica nell’array di elementi serviti, ciascuno con il relativo token per elemento:

[
  {
    "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" }
    ]
  }
]

Modelli di implementazione implementation-patterns

Decisioning supporta tre approcci di implementazione:

Implementazione lato client (Web SDK / Mobile SDK) client-side

Il SDK web o il SDK mobile gestisce automaticamente tutte le richieste e la gestione dei cookie. Con ogni richiesta, SDK archivia e inoltra cookie di identità e cookie cluster.

Gestione cookie: Automatica. Web SDK gestisce kndctr_<OrgId>_identity e kndctr_<OrgId>_cluster cookie.

Implementazione lato server (API Edge Network) server-side

Il server applicazioni POST viene inviato direttamente ad Edge Network e deve gestire manualmente l’inoltro dei cookie. Il server estrae i cookie del browser dalle richieste in arrivo e li inoltra ad Edge Network tramite meta.state.entries[], quindi restituisce i cookie nella risposta.

Gestione cookie: manuale. Il server app deve estrarre i cookie dalla richiesta del browser, inoltrarli ad Edge Network nel corpo della richiesta e impostarli nella risposta. I cookie devono essere inoltrati esplicitamente in meta.state.entries per coerenza identità.

Implementazione ibrida hybrid

Combina il rendering lato server (caricamento pagina iniziale) con SDK lato client (interazioni successive). Il server esegue il rendering del contenuto iniziale tramite Edge Network, quindi Web SDK subentra nelle successive richieste di personalizzazione.

Gestione cookie: misti: il lato server richiede l’inoltro manuale dei cookie ad Edge Network; il lato client viene gestito automaticamente da Web SDK. Assicurati che i token di identità dal rendering lato server siano disponibili per SDK lato client per una risoluzione coerente delle identità.

Tracciamento degli eventi e raccolta dati event-tracking

Per attribuire correttamente i risultati del decisioning, abilitare il limite di frequenza e l’ottimizzazione del ranking basato sull’intelligenza artificiale, devi implementare il tracciamento degli eventi utilizzando lo schema evento Decisioning.

Campi evento obbligatori event-fields

Sono necessari sia eventType che _experience.decisioning.propositionEventType. Se manca una delle due, il display/contatore di interazione corrispondente non incrementa.

Requisiti dello schema schema-requirements

Associa il gruppo di campi Decisioning allo schema del set di dati dell’evento prima della migrazione:

Gestione dei token di tracciamento tracking-token

Il token di tracciamento deve essere gestito in base ai seguenti requisiti:

Esempi di eventi decisionali event-examples

Ogni esempio fa eco alla proposta trasmessa (incluso scopeDetails, che contiene characteristics.subPropositions) e imposta sia eventType che propositionEventType. I contatori aumentano rispetto agli elementi in subPropositions; propositionAction.tokens seleziona gli elementi desiderati.

Visualizza eventi

Gli eventi di visualizzazione avvisano Decisioning quando un’offerta viene mostrata a un utente. Fornisci i token degli elementi visualizzati oppure ometti tokens per incrementare il contatore di visualizzazione per tutti gli elementi in 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>"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Eventi di interazione (clic)

Gli eventi di interazione tengono traccia di quando un utente fa clic su un’offerta visualizzata o la interagisce con essa. devi fornire esattamente un token che identifica l’elemento su cui è stato fatto 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>"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Eventi personalizzati

Un evento personalizzato utilizza un eventType definito dal cliente (qualsiasi valore diverso da decisioning.proposition<Display|Interact|Dismiss>) e imposta tutti i valori di display/interact/dismiss su 0 in propositionEventType (classificato come OTHER). Gli eventi personalizzati vengono decodificati come eventi di visualizzazione (filtro multi-token) rispetto a subPropositions e vengono valutati tramite il PQL configurato:

{
  "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>"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Questi eventi abilitano il limite di frequenza, il reporting preconfigurato e l’ottimizzazione del ranking basata sull’intelligenza artificiale in Decisioning. Per l’invio di eventi di proposta con Web SDK, consulta Esperienza basata su codice: implementazioni di decisioning.

Processo di migrazione completo migration-process

Argomenti correlati related-topics