Collecter des analyses et appliquer une personnalisation dans les applications ChatGPT (collecte de données MCP)

Ce cas pratique montre comment connecter une application ChatGPT (Model Context Protocol + composants facultatifs de l’interface utilisateur) à Adobe Experience Platform Edge Network. Ce type de collecte de données vous permet d’enregistrer des analyses pour les interactions conversationnelles qui appellent vos outils et de fournir des décisions de personnalisation à partir d’Edge Network dans un widget rendu par ChatGPT.

Ce cas d’utilisation privilégie une approche hybride, utilisant à la fois une implémentation côté serveur pour la collecte de données et une implémentation côté client pour le rendu du contenu personnalisé. Cette approche est idéale, car l’appel de l’outil MCP est le moment le plus fiable pour collecter des analyses. Le widget s’exécute dans un contexte de navigateur et est l’endroit approprié pour stocker l’identité (dans un cookie) et appliquer les décisions de personnalisation.

Ce cas d’utilisation est accompagné d’un exemple de code entièrement opérationnel. Voir Application ChatGPT + Adobe Experience Platform Edge dans le référentiel alloy-samples sur GitHub pour obtenir un exemple de code et des instructions d’implémentation.

Architecture

À un niveau élevé, il existe cinq parties mobiles :

Flux de données

Les sections suivantes décrivent en détail chaque étape.

Étape 1 : l'utilisateur invite ChatGPT en utilisant votre serveur MCP

Cette étape est le point d’entrée du workflow. L’utilisateur indique l’intention du langage naturel :

"Use the Adobe Office Information Tool to show me details about which office that is the most pet-friendly."

Voir Créer votre serveur MCP dans la documentation OpenAI Developers pour plus d’informations.

Étape 2 : ChatGPT interprète l'intention et appelle un outil MCP

En fonction des métadonnées de votre serveur MCP, ChatGPT interprète l’intention et appelle le gestionnaire d’outils approprié sur votre serveur MCP. Cet appel d’outil crée un point de vérité côté serveur pour l’interaction, qui est indépendant de la réussite du rendu de l’interface utilisateur. L’un de vos outils peut avoir les métadonnées suivantes :

{
  "name": "office_details",
  "description": "Fetch details for a single office by ID and return personalization handles for the UI.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sessionId": { "type": "string", "description": "Server-issued session identifier." },
      "officeId": { "type": "string", "description": "Office identifier." }
    },
    "required": ["sessionId", "officeId"],
    "additionalProperties": false
  },
  "_meta": {
    "ui": {
      "visibility": ["model", "app"]
    }
  }
}

Consultez Définir des outils dans la documentation OpenAI destinée aux développeurs pour plus d’informations sur la manière d’indiquer à ChatGPT ce que fait chaque outil MCP.

Étape 3 : votre serveur MCP envoie un événement d’expérience à Edge Network

Lorsque votre serveur MCP reçoit une demande, il déclenche un appel à l’Edge Network Adobe Experience Platform pour enregistrer les données d’analyse et éventuellement demander la prise de décision/personnalisation. Comme cette requête est serveur à serveur, utilisez le point d’entrée de interact authentifié dans le cadre des API de collecte de données. Adobe recommande d’utiliser un espace de noms personnalisé pour transmettre l’identifiant unique OpenAI. Assurez-vous que l’espace de noms que vous créez dans l’interface utilisateur Identités et l’espace de noms d’identité que vous définissez dans votre appel correspondent (sensible à la casse).

curl -X POST "https://server.adobedc.net/ee/v2/interact?datastreamId={DATASTREAM_ID}"
  -H "Authorization: Bearer {TOKEN}"
  -H "x-gw-ims-org-id: {ORG_ID}"
  -H "x-api-key: {API_KEY}"
  -H "Content-Type: application/json"
  -d '{
    "event": {
      "xdm": {
        "eventType": "office.details.view",
        "identityMap": {
          "{IDENTITY_NAMESPACE}": [
            { "id": "{PSEUDONYMOUS_SUBJECT_ID}", "primary": true }
          ]
        },
        "timestamp": "YYYY-02-20T19:00:00.000Z"
      }
    },
    "query": {
      "personalization": {
        "decisionScopes": ["__view__"]
      }
    },
    "meta": {
      "state": {
        "entries": [
          { "key": "kndctr_orgid_cluster", "value": "{CLUSTER_HINT_IF_KNOWN}" },
          { "key": "kndctr_orgid_identity", "value": "{ECID_BLOB_IF_KNOWN}" }
        ]
      }
    }
  }'

Étape 4 : L’Edge Network renvoie les poignées

Lorsque l’Edge Network reçoit votre appel interact, elle répond avec un tableau handle. Ce tableau peut inclure des décisions d’identité et de personnalisation, selon la configuration de votre flux de données. Voici un exemple de réponse :

{
  "requestId": "60a2f...2294d",
  "handle": [
    {
      "type": "locationHint:result",
      "payload": [
        { "scope": "EdgeNetwork", "hint": "or2", "ttlSeconds": 1800 }
      ]
    },
    {
      "type": "state:store",
      "payload": [
        { "key": "kndctr_..._identity", "value": "CiYzM...snTI=", "maxAge": 34128000 },
        { "key": "kndctr_..._cluster", "value": "or2", "maxAge": 1800 }
      ]
    }
  ]
}

Votre serveur MCP peut ensuite extraire des informations de la réponse Edge Network pour conserver les informations d’identité :

type EdgeHandle = { type: string; payload?: Array<{ key?: string; value?: string }> };

export function extractStateStore(handles: EdgeHandle[]) {
  const store = handles.find(h => h.type === "state:store");
  const entries = store?.payload ?? [];

  const identity = entries.find(e => e.key?.includes("_identity"))?.value;
  const cluster  = entries.find(e => e.key?.includes("_cluster"))?.value;

  return { identity, cluster };
}

Étape 5 : le serveur MCP renvoie la sortie d'outil structuré plus les métadonnées Adobe à ChatGPT

Votre réponse de l’outil MCP inclut la sortie de l’outil structuré et la personnalisation à partir d’Edge Network.

{
  "content": "Displayed details for office seattle.",
  "structuredContent": {
    "office": {
      "id": "seattle",
      "name": "Seattle",
      "amenities": ["Pet Friendly", "Cafe", "Bike Storage"]
    }
  },
  "_meta": {
    "adobe": {
      "identityMap": {
        "{IDENTITY_NAMESPACE}": [
          { "id": "{PSEUDONYMOUS_SUBJECT_ID}", "primary": true }
        ]
      },
      "handles": [
        {
          "type": "state:store",
          "payload": [
            { "key": "kndctr_..._identity", "value": "..." }
          ]
        },
        {
          "type": "personalization:decisions",
          "payload": [
            { "id": "..." }
          ]
        }
      ]
    }
  }
}

Voir Résultats de l’outil dans la référence du développeur OpenAI pour plus d’informations.

Étape 6 : le widget effectue le rendu du résultat et l’applique _adobe.handles utilisant applyResponse

Le widget effectue le rendu des données métier à partir de structuredContent, puis lit les métadonnées Adobe à partir de _meta.adobe. Dans ChatGPT, les mêmes données sont disponibles pour le widget via la couche de compatibilité :

Le widget utilise la commande applyResponse de la bibliothèque JavaScript de Web SDK pour décompresser l’état côté client et rendre les décisions de personnalisation renvoyées par l’appel de interact côté serveur. Veillez à appeler la commande configure avant de applyResponse appeler. Étant donné que votre serveur MCP a effectué un appel interact, vous n’avez pas besoin d’appeler immédiatement la commande sendEvent pour l’interaction d’appel de l’outil.

// Configure the Web SDK before any other commands.
alloy("configure", {
  datastreamId: "YOUR_DATASTREAM_ID",
  orgId: "YOUR_EXPERIENCE_CLOUD_ORG_ID"
});

// Business data exposed to ChatGPT and the widget.
const { office } = window.openai?.toolOutput ?? {};

// Adobe metadata available only to the widget.
const adobe = window.openai?.toolResponseMetadata?.adobe ?? {};
const { identityMap, handles } = adobe;

// Hydrate client-side state and render personalization decisions from the
// server-side interact response.
alloy("applyResponse", {
  renderDecisions: true,
  responseBody: { handle: handles ?? [] }
});

Si le widget envoie ultérieurement des événements supplémentaires côté interface utilisateur, vous pouvez inclure le même identityMap sur ces appels :

alloy("sendEvent", {
  xdm: {
    eventType: "office.details.widgetView",
    identityMap
  }
});

Ce modèle permet d’aligner l’utilisation des identités côté serveur et côté interface utilisateur tout en permettant à l’appel interact côté serveur de rester la source de vérité pour la collecte d’analyses et la prise de décision.

Validation

Une fois toutes les étapes ci-dessus configurées, vous pouvez valider les éléments suivants :

Considérations relatives à la sécurité et à la confidentialité