Fusionner les utilisateurs

Utilisez cet endpoint pour fusionner un utilisateur avec un autre utilisateur.

Vous pouvez spécifier jusqu’à 50 fusions par requête. Cet endpoint est asynchrone.

Conditions préalables

Pour utiliser cet endpoint, vous aurez besoin d’une clé API avec l’autorisation users.merge.

Limite de débit

Nous appliquons une limite de débit partagée de 20 000 requêtes par minute à cet endpoint. Cette limitation du débit est partagée avec les endpoints /users/delete, /users/alias/new, /users/identify et /users/alias/update, comme documenté dans Limites de débit de l’API.

Corps de la demande

1
2
Content-Type: application/json
Authorization: Bearer YOUR_REST_API_KEY

1
2
3
{
  "merge_updates" : (required, array of objects)
}

Paramètres de demande

Comportement de fusion

Le comportement documenté ci-dessous est vrai pour toutes les fonctionnalités de Braze qui ne sont pas optimisées par Snowflake. Les fusions d’utilisateurs ne seront pas prises en compte pour l’onglet Historique des messages, les extensions de segments, le générateur de requêtes et les actualités.

Ce endpoint fusionne les champs suivants s’ils ne sont pas trouvés chez l’utilisateur cible.

• Prénom
• Nom
• Adresses de e-mail (à moins qu’elles ne soient cryptées)
• Genre
• Date de naissance
• Numéro de téléphone
• Fuseau horaire
• Ville d’origine
• Pays
• Langue
• Informations sur l’appareil
• Décompte des sessions (la somme des sessions des deux profils)
• Date de la première session (Braze sélectionne la date la plus proche des deux dates)
• Date de la dernière session (Braze sélectionne la date la plus récente parmi les deux dates)
• Attributs personnalisés (Braze conserve les attributs personnalisés existants dans le profil cible et inclut les attributs personnalisés qui n’existaient pas dans le profil cible)
• Données d’événements personnalisés et d’événements d’achat
• Propriétés d’événement personnalisé et d’événement d’achat pour la segmentation « X fois en Y jours » (oùX<=50et Y<=30)
• Résumé des événements personnalisés pouvant être segmentés
  • Nombre d’événements (la somme des deux profils)
  • Date à laquelle l’événement s’est produit pour la première fois (Braze sélectionne la date la plus ancienne parmi les deux dates)
  • Dernière occurrence de l’événement (Braze sélectionne la date la plus récente parmi les deux dates)
• Total des achats intégrés à l’application en centimes (la somme des deux profils)
• Nombre total d’achats (la somme des deux profils)
• Date du premier achat (Braze sélectionne la date la plus ancienne parmi les deux dates)
• Date du dernier achat (Braze sélectionne la date la plus récente parmi les deux dates)
• Résumés des applications
• Last_X_at champs (Braze met à jour les champs si les champs du profil orphelin sont plus récents)
• Données d’interaction de la campagne (Braze sélectionne les champs de date les plus récents)
• Résumés du flux de travail (Braze sélectionne les champs de date les plus récents)
• Message et historique d’engagement du message
• Braze fusionne les données de session uniquement si l’application est présente sur les deux profils utilisateurs.

Comportement personnalisé de la date de l’événement et de la date de l’événement d’achat

Ces champs fusionnés mettent à jour les filtres « pour X événements en Y jours ». Pour les événements d’achat, ces filtres incluent « nombre d’achats en Y jours » et « argent dépensé au cours des Y derniers jours ».

Fusionner les utilisateurs par e-mail ou par numéro de téléphone

Si unemail ouphone est spécifié comme identifiant, il est nécessaire d’inclure une valeur prioritizationsupplémentaire dans l’identifiant. Ilprioritizationest nécessaire de fournir un tableau ordonné indiquant quel utilisateur fusionner si plusieurs utilisateurs sont détectés. Cela signifie que si plusieurs utilisateurs correspondent à une priorité, la fusion n’aura pas lieu.

Les valeurs autorisées pour le tableau sont les suivantes :

• identified
• unidentified
• most_recently_updated (Priorité à l’utilisateur le plus récemment mis à jour)
• least_recently_updated (Priorité à l’utilisateur le moins récemment mis à jour)

Une seule des options suivantes peut exister à la fois dans le tableau de priorisation :

• identified Il s’agit de donner la priorité à un utilisateur ayant une external_id
• unidentified Il s’agit de donner la priorité à un utilisateur qui n’a pas de external_id

Exemple de requêtes

Demande de base

Il s’agit d’un corps de requête basique pour montrer le modèle de la requête.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
curl --location --request POST 'https://rest.iad-01.braze.com/users/merge' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
{
  "merge_updates": [
    {
      "identifier_to_merge": {
        "external_id": "old-user1"
      },
      "identifier_to_keep": {
        "external_id": "current-user1"
      }
    },
    {
      "identifier_to_merge": {
        "email": "[email protected]",
        "prioritization": ["unidentified", "most_recently_updated"]
      },
      "identifier_to_keep":  {
        "email": "[email protected]",
        "prioritization": ["identified", "most_recently_updated"]
      }
    },
    {
      "identifier_to_merge": {
        "user_alias": {
          "alias_name": "[email protected]",
          "alias_label": "email"
        }
      },
      "identifier_to_keep": {
        "user_alias": {
          "alias_name": "[email protected]",
          "alias_label": "email"
        }
      }
    }
  ]
}'

Fusionner des utilisateurs non identifiés

La demande suivante fusionnerait l’utilisateur non identifié le plus récemment mis à jour avec l’adresse e-mail[email protected] avec l’utilisateur ayant l’ID externejohn . Dans cet exemple, l’utilisationmost_recently_updatedde filtre la requête à un utilisateur non identifié. Ainsi, s’il y avait deux utilisateurs non identifiés avec cette adresse e-mail, un seul serait fusionné avec l’utilisateur disposant d’un ID externejohn.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
curl --location --request POST 'https://rest.iad-01.braze.com/users/merge' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
{
  "merge_updates": [
    {
      "identifier_to_merge": {
        "email": "[email protected]",
        "prioritization": ["unidentified", "most_recently_updated"]
      },
      "identifier_to_keep": {
        "external_id": "john"
      }
    }
  ]
}'

Fusionner un utilisateur non identifié avec un utilisateur identifié

L’exemple suivant fusionne l’utilisateur non identifié le plus récemment mis à jour avec l’adresse e-mail[email protected] et l’utilisateur identifié le plus récemment mis à jour avec l’adresse e-mail[email protected] .

Utilisationmost_recently_updatedde filtres pour limiter les requêtes à un utilisateur (un utilisateur non identifié pour identifier_to_mergeet un utilisateur identifié pour le identifier_to_keep).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
curl --location --request POST 'https://rest.iad-01.braze.com/users/merge' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
{
  "merge_updates": [
    {
      "identifier_to_merge": {
        "email": "[email protected]",
        "prioritization": ["unidentified", "most_recently_updated"]
      },
      "identifier_to_keep": {
        "email": "[email protected]",
        "prioritization": ["identified", "most_recently_updated"]
      }
    }
  ]
}'

Fusionner un utilisateur non identifié sans inclure lamost_recently_updatedpriorisation

S’il existe deux utilisateurs non identifiés avec l’adresse e-mail[email protected] , cette requête exemple ne fusionne aucun utilisateur, car il y a deux utilisateurs non identifiés avec cette adresse e-mail. Cette requête ne fonctionne que s’il n’y a qu’un seul utilisateur non identifié avec l’adresse e-mail[email protected].

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
curl --location --request POST 'https://rest.iad-01.braze.com/users/merge' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
{
  "merge_updates": [
    {
      "identifier_to_merge": {
        "email": "[email protected]",
        "prioritization": ["unidentified"]
      },
      "identifier_to_keep": {
        "external_id": "john"
      }
    }
  ]
}'

Réponse

Deux réponses de code de statut existent pour cet endpoint : 202 et 400.

Exemple de réponse réussie

Le code de statut 202 pourrait renvoyer le corps de réponse suivant.

1
2
3
{
  "message": "success"
}

Exemple de réponse échouée

Le code de statut 400 pourrait renvoyer le corps de réponse suivant. Consultez la résolution des problèmes pour plus d’informations concernant les erreurs que vous pourriez rencontrer.

1
2
3
{
  "message": "'merge_updates' must be an array of objects"
}

Résolution des problèmes

Le tableau suivant répertorie les messages d’erreur possibles.