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 Sandbox-übergreifende Migration cross-sandbox-prerequisites

Wenn die Quell-Sandbox die Ziel-Sandbox ≠, 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 geben diese Zuordnungen im dependency Objekt der Migrationsanfrage in Schritt 2 an.

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.

Umfang und Abdeckung der Migration migration-scope

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

Im Umfang: Was wird abgedeckt? in-scope

Die Migrations-API verarbeitet die folgenden Elemente und Funktionen:

Außerhalb des Geltungsbereichs: Was nicht abgedeckt ist oder manuelle Maßnahmen erfordert 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 zum Entscheidungs-Management werden Entitäten gemäß 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.

Entscheidungs-Management für die Zuordnung von Entscheidungsentitäten

Namenskonventionen

Der Migrationsprozess wendet Benennungskonventionen mit dem 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 zu Decisioning muss Ihr Anwendungs-Code aktualisiert werden, um die neuen Anfrage- und Antwortformate zu verwenden. Beide Systeme verwenden den Edge Network-Endpunkt, jedoch mit unterschiedlichen Payload-Strukturen und Feldnamen.

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

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

Endpunkt:

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

Kopfzeilen:
​- Authorization: Bearer <IMS_ACCESS_TOKEN>
​- x-api-key: <API_KEY> (aus Developer Console)
​- x-gw-ims-org-id: <IMS_ORG_ID> (Format: {ORG_ID}@AdobeOrg)
​- x-request-id: <UNIQUE_REQUEST_ID> (für Tracking und Deduplizierung)
​- 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> (z. B. prod, dev)

Parameter des Anfragetexts:
​- xdm:dryRun (true/false) - Testanfragen ohne schädliche Berichte
​- xdm:propositionRequests[] - Array von Entscheidungsanfragen:
​- activityId - Kennung der Entscheidungsaktivität
​- placementId - Platzierungs-ID
​- itemCount - Maximale Anzahl an zurückzugebenden Angeboten
​- xdm:profiles[].xdm:identityMap - Identitätszuordnung (E-Mail, ECID usw.)
​- xdm:validateContextData - Markierung für die strikte Kontextdatenvalidierung
​- xdm:responseFormat.xdm:includeContent - Nur tatsächliche Inhalte vs. IDs werden einbezogen

Beispiel-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 }
  }
}

Decisioning - Edge-Anfrage (nach der Migration) decisioning-request

Verwenden Sie nach der Migration das Decisioning-Anfrageformat über denselben Edge Network-Endpunkt.

Endpunkt:

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

Felder für Schlüsselanfragen:
​- query.identity.fetch - Array von aufzulösenden Identitätstypen (z. B. ["ECID"])
​- event.xdm.environment.type - Umgebungstyp: "browser", "app" oder "server"
​- event.xdm.environment.browserDetails - Browser-Metadaten (viewportWidth, viewportHeight, userAgent)
​- event.xdm.identityMap - Identitätszuordnung wie Entscheidungs-Management
​- event.xdm.timestamp - ISO 8601-Zeitstempel
​- query.personalization.surfaces - Array von Zieloberflächen (z. B. ["web://site.com/homepage"]) - ersetzt decisionScope
​- query.personalization.schemas - Zurückzugebende Inhaltsschemata (z. B. ["json-content-item", "html-content-item"])
​- data.__adobe.ajo.allowDuplicateDecisionItems - Deduplizierungssteuerung (standardmäßig true; false festlegen, dass ein Element, das für mehrere Oberflächen geeignet ist, nur einmal zurückgegeben wird, wobei die anderen Oberflächen ein Fallback-/Leer-Element erhalten). Ersetzt die Entscheidungs-Management-allowDuplicatePropositions.
​- data.__adobe.ajo.dryRun - Test-Flag; unterdrückt Feedback-Ereignisse für Reporting- und Begrenzungszähler. Ersetzt die Entscheidungs-Management-xdm:dryRun. Vor der Produktion entfernen.

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

Decisioning - Edge-Antwort decisioning-response

Die Decisioning-Antwort enthält mehrere Handles, die nach Concern-Typ organisiert sind: personalization:decisions (die Angebote), locationHint:result und state:store (die Cookies, die beibehalten werden sollen).

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

Wichtige Antwortfelder:
​- handle[].type - Grifftyp (personalization:decisions, locationHint:result, state:store)
​- payload[].id - Eindeutige ID der Vorschlagsinstanz — Echoback bei Anzeige-/Interaktionsereignissen
​- payload[].scope - Oberflächen-URI, für den der Vorschlag aufgelöst wurde
​- payload[].scopeDetails.decisionProvider - Bestätigt, dass die Engine AJO ist
​- payload[].scopeDetails.correlationID - verknüpft die Entscheidungsinstanz mit dem bereitstellenden Ereignis
​- payload[].scopeDetails.rank/payload[].scopeDetails.activity - Rang- und Kampagnen-/Aktionsmetadaten für den Vorschlag
​- payload[].scopeDetails.characteristics.eventToken - Tracking-Token auf Nachrichtenebene
​- payload[].scopeDetails.characteristics.subPropositions - Base64-kodiertes Array der Entscheidungselemente Jedes Element verfügt über eine eigene token pro Element. Diese Token pro Element werden propositionAction.tokens bei Anzeige-/Interaktionsereignissen übergeben
​- payload[].items[].schema/payload[].items[].data.content - Inhaltsschema und tatsächlicher Angebotsinhalt (JSON/HTML) zum Rendern
​- state:store Payload : Die Identitäts- und Cluster-Cookies, die bei nachfolgenden Anfragen beibehalten und weitergeleitet werden sollen (Server-seitig)

Die characteristics.subPropositions-Zeichenfolge base64-decodiert für das Array von bereitgestellten Elementen, jedes mit seiner token pro Element:

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

Decisioning unterstützt drei Implementierungsansätze:

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

Web SDK oder Mobile SDK verarbeitet alle Anfragen und Cookie-Verwaltung automatisch. SDK speichert und leitet bei jeder Anfrage Identitäts- und Cluster-Cookies weiter.

Cookie-Handhabung: Automatisch - Web SDK verwaltet kndctr_<OrgId>_identity und kndctr_<OrgId>_cluster Cookies.

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

Der Anwendungs-Server sendet POST-Anfragen direkt an Edge Network und muss die Cookie-Weiterleitung 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 als Antwort festlegen. Cookies müssen in meta.state.entries explizit weitergeleitet werden, um eine konsistente Identität zu gewährleisten.

Hybridimplementierung hybrid

Kombiniert Server-seitiges Rendering (anfängliches 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 - Serverseitig ist eine manuelle Weiterleitung von Cookies an Edge Network erforderlich; Client-seitig automatisch von Web SDK verarbeitet. Stellen Sie sicher, dass Identitäts-Token vom Server-seitigen Rendering für Client-seitige SDK verfügbar sind, um eine konsistente Identitätsauflösung zu gewährleisten.

Ereignisverfolgung und Datenerfassung event-tracking

Um Entscheidungsergebnisse ordnungsgemäß zuzuordnen, Frequenzlimitierung zu aktivieren und die KI-basierte Rangfolgenoptimierung zu ermöglichen, müssen Sie die Ereignisverfolgung mit dem Decisioning-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 inkrementiert.

Schemaanforderungen schema-requirements

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

Verarbeitung von Tracking-Token tracking-token

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

Beispiele für Decisioning-Ereignisse event-examples

Jedes Beispiel spiegelt den servierten Vorschlag wider (einschließlich seines scopeDetails, der characteristics.subPropositions trägt) 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.

Ereignisse anzeigen

Anzeigen von Ereignissen benachrichtigt Sie von Decisioning, wenn einem Benutzer 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>"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Interagieren (Klicken) von Ereignissen

Interaktionsereignisse verfolgen, wann ein Benutzer auf ein angezeigtes Angebot klickt oder mit ihm interagiert. Sie müssen genau ein Token angeben, 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 eine kundendefinierte eventType (einen beliebigen Wert außer decisioning.proposition<Display|Interact|Dismiss>) und setzt alle display/interact/dismiss auf 0 in propositionEventType (als OTHER klassifiziert). Benutzerdefinierte 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 Frequenzlimitierung, vorkonfiguriertes Reporting und eine KI-gesteuerte Ranking-Optimierung in Decisioning. Informationen zum Senden von Vorschlagsereignissen mit Web SDK finden Sie Code-basiertes Erlebnis: Entscheidungsimplementierungen.

End-to-End-Migrationsprozess migration-process

Verwandte Themen related-topics