Entscheidungsfindungsmigrations-API decisioning-migration-api

Auf dieser Seite: Verwenden Sie die Entscheidungsfindungsmigrations-API, um Entscheidungs-Management-Objekte mit automatisierter Abhängigkeitsanalyse und Rollback-Unterstützung zwischen Sandboxes zu verschieben, damit Sie Entscheidungsinhalte zwischen Umgebungen übertragen können, während die Datenintegrität erhalten bleibt.

Mit der Entscheidungsfindungsmigrations-API können Sie Entscheidungs-Management-Objekte von einer Sandbox in eine andere migrieren. Der Migrationsprozess wird in Form asynchroner Workflows ausgeführt, die Funktionen für Abhängigkeitsanalysen, Ausführung und optionales Rollback enthalten.

Mit dieser API können Sie Ihre Entscheidungs-Inhalte nahtlos zwischen Umgebungen übertragen und dabei Datenintegrität und -beziehungen beibehalten.

Weitere Informationen zu den Vorteilen und Funktionen von Entscheidungsfindung im Vergleich zum Entscheidungs-Management finden Sie auf dieser Seite.

Funktionen capabilities

Die Entscheidungsfindungsmigrations-API bietet die folgenden Funktionen:

Voraussetzungen prerequisites

Erforderliche Berechtigungen permissions

Um die Migrations-API verwenden zu können, benötigen Sie entsprechende Berechtigungen in der Quell- und Ziel-Sandbox:

Quell-Sandbox – Lesezugriff auf Entscheidungs-Management-Objekte

Ziel-Sandbox – Erstellungs- und Bearbeitungszugriff auf Entscheidungsfindungs-Objekte

Zu den typischen Berechtigungen gehören:

Vorbereiten der Ziel-Sandbox target-sandbox-preparation

Bevor Sie eine Migration ausführen, stellen Sie sicher, dass Ihre Ziel-Sandbox ordnungsgemäß konfiguriert ist:

Weitere Informationen zur Sandbox-Verwaltung finden Sie unter Verwenden und Zuweisen von Sandboxes.

Voraussetzungen für die Migration zwischen Sandboxes cross-sandbox-prerequisites

Wenn die Quell-Sandbox nicht mit der Ziel-Sandbox übereinstimmt, sind die folgenden Elemente erforderlich:

API-Grundlagen api-basics

Basis-URL base-url

Verwenden Sie die folgende Basis-URL:

Authentifizierung authentication

Alle API-Anfragen erfordern die folgenden Header:

Detaillierte Anweisungen zum Einrichten der Authentifizierung finden Sie im Authentifizierungshandbuch für Journey Optimizer.

Migrations-Workflow migration-workflow

Der Migrationsprozess besteht aus zwei Hauptschritten: Analysieren von Abhängigkeiten und Ausführen der Migration. Führen Sie die folgenden Schritte aus, um eine erfolgreiche Migration sicherzustellen.

Schritt 1: Analysieren von Abhängigkeiten analyze-dependencies

Verwenden Sie vor der Migration den Abhängigkeits-Workflow, um zu ermitteln, was in Ihrer Ziel-Sandbox vom Entscheidungs-Management zur Entscheidungsfindung zugeordnet werden muss. Diese Analyse hilft Ihnen, die Beziehungen zwischen Objekten zu verstehen und die erforderlichen Zuordnungen vorzubereiten.

Erstellen eines Abhängigkeits-Workflows create-dependency-workflow

Verwenden Sie den folgenden API-Aufruf, um einen Workflow zur Abhängigkeitsanalyse zu erstellen.

API-Format

POST /workflows/generate-dependencies

Abhängigkeit auf Sandbox-Ebene (als erste Analyse empfohlen)

Beginnen Sie mit einer Analyse auf Sandbox-Ebene, um einen vollständigen Überblick über alle Abhängigkeiten zu erhalten:

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

Abhängigkeit auf Angebotsebene

Um die Abhängigkeiten nur für bestimmte Angebote zu analysieren, rufen Sie denselben Endpunkt mit request-level=offer in der Abfragezeichenfolge auf und geben Sie im Hauptteil ein offersList-Array mit den Angebots-IDs an, die Sie analysieren möchten.

Abhängigkeit auf Entscheidungsebene

Um die Abhängigkeiten nur für bestimmte Entscheidungen zu analysieren, verwenden Sie request-level=decision in der Abfragezeichenfolge und stellen Sie im Hauptteil ein decisionsList-Array mit den Entscheidungs-IDs bereit, die Sie analysieren möchten.

Prüfen des Status des Abhängigkeits-Workflows poll-dependency-status

Fragen Sie den Abhängigkeits-Workflow ab, um zu prüfen, wann die Analyse abgeschlossen ist.

API-Format

GET /workflows/generate-dependencies/{id}

Anfrage

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

Wenn das Feld status den Wert Completed anzeigt, ist die Abhängigkeitsanalyse bereit. Verwenden Sie die Workflow-Ausgabe, um Ihre Zuordnungen von Migrationsabhängigkeiten zu erstellen:

Sie stellen diese Zuordnungen im Objekt dependency der Migrationsanfrage in Schritt 2 bereit.

Schritt 2: Ausführen der Migration execute-migration

Nachdem Sie die Abhängigkeiten analysiert und die Zuordnungen vorbereitet haben, können Sie die Migration ausführen.

Erstellen eines Migrations-Workflows create-migration-workflow

Verwenden Sie die Abhängigkeitszuordnungen aus Schritt 1, um Ihre Migration zu konfigurieren und auszuführen.

API-Format

POST /workflows/migration

Migration auf Sandbox-Ebene

So migrieren Sie alle Entscheidungsfindungs-Objekte von einer Sandbox in eine andere:

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

Migration auf Angebotsebene

Um nur bestimmte Angebote zu migrieren, verwenden Sie request-level=offer in der Abfragezeichenfolge und fügen Sie dem Hauptteil ein offersList-Array hinzu:

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

Migration auf Entscheidungsfindungs-Ebene

Um nur bestimmte Entscheidungen zu migrieren, verwenden Sie request-level=decision in der Abfragezeichenfolge und fügen Sie dem Hauptteil ein decisionsList-Array hinzu:

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

Anfragefelder

Überwachen des Migrationsstatus poll-migration-status

Fragen Sie den Status des Migrations-Workflows ab, um seinen Fortschritt nachzuverfolgen.

API-Format

GET /workflows/migration/{id}

Anfrage

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

Migrationsergebnisse

Wenn das Feld status den Wert Completed anzeigt, war die Migration erfolgreich. Der Workflow result umfasst die folgenden Elemente:

Wenn das Feld status den Wert Failed anzeigt, prüfen Sie das errors[]-Array und das Feld result.error auf Details zu den Problemen.

Jeder Workflow (Abhängigkeit, Migration und Rollback) gibt dieselben Ressourcenfelder zurück:

Validieren der Migration validate-migration

Prüfen Sie nach erfolgreichem Abschluss der Migration, ob alle Objekte korrekt migriert wurden.

Validierungs-Checkliste validation-checklist

Beispiel test-runtime-delivery

Wenn bei der Migration ein Datenstrom erstellt wurde, können Sie die Angebotsbereitstellung anhand des folgenden Beispiels testen:

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

Rollback einer Migration rollback

Wenn Sie während der Validierung Probleme feststellen, können Sie eine abgeschlossene Migration zurücksetzen, um den vorherigen Status der Ziel-Sandbox wiederherzustellen.

Erstellen eines Rollback-Workflows create-rollback-workflow

Starten Sie ein Rollback, indem Sie einen Rollback-Workflow erstellen, der auf die Migration verweist, die Sie zurücksetzen möchten.

API-Format

POST /workflows/rollback

Anfrage

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

Ersetzen Sie <MIGRATION_WORKFLOW_ID> durch die ID des Migrations-Workflows, den Sie zurücksetzen möchten.

Überwachen des Rollback-Status poll-rollback-status

Fragen Sie den Rollback-Workflow ab, um seinen Fortschritt nachzuverfolgen.

API-Format

GET /workflows/rollback/{rollbackWorkflowId}

Anfrage

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

Bearbeitung gleichzeitiger Workflows handle-concurrency

Mit der Migrations-API kann jeweils nur ein Workflow pro Organisation ausgeführt werden. Wenn Sie versuchen, einen neuen Workflow zu erstellen, während ein anderer ausgeführt wird, erhalten Sie eine Fehlerantwort 409 Conflict („Ein Workflow ist bereits in Bearbeitung …“).

Warten Sie in diesem Fall, bis der laufende Workflow abgeschlossen ist, oder rufen Sie die Workflow-ID ab und fragen Sie den Status ab. Sobald der aktuelle Workflow abgeschlossen ist, können Sie einen neuen erstellen.

Migrationsumfang und -abdeckung migration-scope

Wenn Sie den Umfang der Migration verstehen, können Sie den Übergang vom Entscheidungs-Management zur Entscheidungsfindung planen und validieren. In diesem Abschnitt wird beschrieben, was vom Migrationsprozess abgedeckt wird und was ein manuelles Eingreifen erfordert.

Im Umfang: Das wird abgedeckt in-scope

Die Migrations-API verarbeitet die folgenden Elemente und Funktionen:

Außerhalb des Geltungsbereichs: Das wird nicht abgedeckt oder erfordert manuelle Maßnahmen out-of-scope

Die folgenden Elemente erfordern manuelle Aktionen oder werden vom Migrations-Tool nicht unterstützt:

Entitätszuordnungsreferenz entity-mapping

Bei der Migration vom Entscheidungs-Management zur Entscheidungsfindung werden Entitäten entsprechend der folgenden Tabelle zugeordnet. Die Zuordnungen umfassen die primären Entscheidungsentitäten und zusätzliche verknüpfte Entitäten, die während der Migration erstellt oder verwendet wurden.

Zuordnung von Entscheidungsentitäten zwischen Entscheidungs-Management und Entscheidungsfindung

Namenskonventionen

Der Migrationsprozess wendet Benennungskonventionen mit dem Präfix ExD_ an, um Konsistenz zu gewährleisten und Benennungskonflikte zu vermeiden.

Zusätzliche Attribute

Anfrage- und Antwortmodell request-response-model

Bei der Migration vom Entscheidungs-Management zur Entscheidungsfindung muss Ihr Anwendungs-Code aktualisiert werden, damit die neuen Anfrage- und Antwortformate verwendet werden. Beide Systeme verwenden den Edge Network-Endpunkt, jedoch mit unterschiedlichen Payload-Strukturen und Feldnamen.

Entscheidungs-Management – Edge-Anfrage (aktuell) dm-request

Die aktuelle Edge-Anfrage beim Entscheidungs-Management folgt dieser Struktur:

Endpunkt:

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

Kopfzeilen:

Parameter des Anfragetexts:

Beispiel für einen Anfragetext:

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

Entscheidungsfindung – Edge-Anfrage (nach der Migration) decisioning-request

Verwenden Sie nach der Migration das Format für Entscheidungsanfragen über denselben Edge Network-Endpunkt.

Endpunkt:

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

Wichtigste Anfragefelder:

Beispiel für einen Anfragetext (Server-seitig):

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

Entscheidungsfindung – Edge-Antwort decisioning-response

Die Antwort der Entscheidungsfindung enthält mehrere Handles, die nach Zuständigkeitsbereich gegliedert sind: personalization:decisions (die Angebote), locationHint:result und state:store (die beizubehaltenden Cookies).

Antwortstruktur:

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

Wichtigste Anfragefelder:

Die Base64-Decodierung der Zeichenfolge characteristics.subPropositions ergibt das Array der bereitgestellten Elemente, jeweils mit dem zugehörigen elementspezifischen 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" }
    ]
  }
]

Implementierungsmuster implementation-patterns

Die Entscheidungsfindung unterstützt drei Implementierungsansätze:

Client-seitige Implementierung (Web SDK/Mobile SDK) client-side

Das Web SDK oder Mobile SDK wickelt alle Anfragen und das Cookie-Management automatisch ab. Das SDK speichert und übermittelt sowohl Identitäts- als auch Cluster-Cookies bei jeder Anfrage.

Cookie-Verwaltung: Automatisch – Das Web SDK verwaltet die Cookies kndctr_<OrgId>_identity und kndctr_<OrgId>_cluster.

Server-seitige Implementierung (Edge Network-API) server-side

Der Anwendungs-Server sendet POST-Anfragen direkt an das Edge Network und muss die Weiterleitung von Cookies manuell verwalten. Der Server extrahiert Browser-Cookies aus eingehenden Anfragen und leitet sie über meta.state.entries[] an Edge Network weiter. Anschließend gibt er Cookies in der Antwort zurück.

Handhabung von Cookies: Manuell – Der Anwendungs-Server muss Cookies aus der Browser-Anfrage extrahieren, im Anfragetext an Edge Network weiterleiten und in der Antwort festlegen. Cookies müssen explizit in meta.state.entries weitergeleitet werden, um eine konsistente Identität zu gewährleisten.

Hybridimplementierung hybrid

Kombiniert Server-seitiges Rendern (erstes Laden der Seite) mit Client-seitigem SDK (nachfolgende Interaktionen). Der Server rendert den anfänglichen Inhalt über Edge Network, dann übernimmt Web SDK für nachfolgende Personalisierungsanfragen.

Behandlung von Cookies: Gemischt – Server-seitig ist eine manuelle Weiterleitung von Cookies an Edge Network erforderlich; Client-seitig erfolgt die Verarbeitung automatisch durch Web SDK. Stellen Sie sicher, dass Identitäts-Token vom Server-seitigen Rendern für Client-seitiges SDK verfügbar sind, um eine konsistente Identitätsauflösung zu gewährleisten.

Ereignisnachverfolgung und Datenerfassung event-tracking

Um Entscheidungsergebnisse ordnungsgemäß zuzuordnen, Frequenzbegrenzung zu aktivieren und die KI-basierte Rangfolgenoptimierung zu ermöglichen, müssen Sie die Ereignisnachverfolgung mit dem Entscheidungsfindungs-Ereignisschema implementieren.

Erforderliche Ereignisfelder event-fields

Sowohl eventType als auch _experience.decisioning.propositionEventType sind erforderlich. Wenn eines von beiden fehlt, wird der entsprechende Anzeige-/Interaktionszähler nicht hochgezählt.

Schemaanforderungen schema-requirements

Verknüpfen Sie die Entscheidungsfindungs-Feldergruppe vor der Migration mit Ihrem Ereignis-Datensatzschema:

Verarbeitung von Tracking-Token tracking-token

Das Tracking-Token muss gemäß den folgenden Anforderungen verarbeitet werden:

Beispiele für Entscheidungsfindungs-Ereignisse event-examples

Jedes Beispiel spiegelt den bereitgestellten Vorschlag wider (einschließlich seiner scopeDetails, mit characteristics.subPropositions) und legt sowohl eventType als auch propositionEventType fest. Die Zähler erhöhen sich für die Elemente in subPropositions; propositionAction.tokens wählt die Elemente aus.

Anzeigeereignisse

Anzeigeereignisse benachrichtigen die Entscheidungsfindung, wenn einer Person ein Angebot angezeigt wird. Geben Sie die Token der angezeigten Elemente an oder lassen Sie die tokens aus, um den Anzeigenzähler für alle Elemente in subPropositions zu erhöhen:

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

Interaktions-(Klick-)Ereignisse

Interaktionsereignisse verfolgen nach, wann eine Person auf ein angezeigtes Angebot klickt oder damit interagiert. Sie müssen genau ein Token angeben, das das angeklickte Element identifiziert:

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

Benutzerspezifische Ereignisse

Ein benutzerspezifisches Ereignis verwendet einen kundendefinierten eventType (einen beliebigen Wert außer decisioning.proposition<Display|Interact|Dismiss>) und setzt alle Parameter display/interact/dismiss auf 0 in propositionEventType (als OTHER klassifiziert). Benutzerspezifische Ereignisse werden wie Anzeigeereignisse (Multi-Token-Filterung) für subPropositions decodiert und über die konfigurierte PQL ausgewertet:

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

Diese Ereignisse ermöglichen eine Frequenzbegrenzung, vorkonfiguriertes Reporting und eine KI-gesteuerte Ranking-Optimierung in der Entscheidungsfindung. Informationen zum Senden von Vorschlagsereignissen mit dem Web SDK finden Sie unter Code-basiertes Erlebnis: Entscheidungsimplementierungen.

End-to-End-Migrationsprozess migration-process

Verwandte Themen related-topics