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

For customers who onboarded with Braze on or after September 16, 2021, we apply a shared rate limit of 20,000 requests per minute to this endpoint. This rate limit is shared with the /users/delete, /users/alias/new, /users/identify, and /users/alias/update endpoints, as documented in API rate limits.

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.

Cet endpoint fusionnera n’importe lequel des champs suivants s’ils ne sont pas trouvés dans l’utilisateur cible :

• Prénom
• Nom
• E-mail
• 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 choisira la date la plus ancienne parmi les deux)
• Date de la dernière session (Braze choisira la date la plus récente parmi les deux)
• Attributs personnalisés (les attributs personnalisés existants sur le profil cible sont conservés et incluront les attributs personnalisés qui n’existaient pas sur le profil cible).
• Données d’événements personnalisés et d’événements d’achat
• Propriétés de l’événement d’achat et personnalisées pour la segmentation « X fois en Y jours » (où X <= 50 et Y <= 30)
• Résumé des événements personnalisés pouvant être segmentés
  • Nombre d’événements (la somme des deux profils)
  • Événement survenu pour la première fois (Braze choisira la date la plus ancienne parmi les deux)
  • Événement survenu pour la dernière fois (Braze choisira la date la plus récente parmi les deux)
• 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 choisira la date la plus ancienne parmi les deux)
• Date du dernier achat (Braze choisira la date la plus récente parmi les deux)
• Résumés des applications
• Champs Last_X_at (Braze mettra à jour les champs si les champs du profil orphelins sont plus récents).
• Données d’interaction de la campagne (Braze choisira les champs de date les plus récents)
• Résumés du flux de travail (Braze choisira les champs de date les plus récents)
• Message et historique d’engagement du message

Les données de session ne seront fusionnées que si l’application existe 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 mettront à 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 un identifiant email ou phone est spécifié, une valeur supplémentaire prioritization est requise dans l’identifiant. prioritization doit être un tableau spécifiant l’utilisateur à fusionner s’il y a plusieurs utilisateurs trouvés. prioritization est un tableau ordonné, ce qui signifie que si plus d’un utilisateur correspond à un ordre de priorité, la fusion n’aura pas lieu.

Les valeurs autorisées pour le tableau sont les suivantes : identified, unidentified, most_recently_updated. most_recently_updated signifie que la priorité est accordée à l’utilisateur ayant effectué la dernière mise à 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": "user1@braze.com",
        "prioritization": ["unidentified", "most_recently_updated"]
      },
      "identifier_to_keep":  {
        "email": "user2@braze.com",
        "prioritization": ["identified", "most_recently_updated"]
      }
    },
    {
      "identifier_to_merge": {
        "user_alias": {
          "alias_name": "old-user2@example.com",
          "alias_label": "email"
        }
      },
      "identifier_to_keep": {
        "user_alias": {
          "alias_name": "current-user2@example.com",
          "alias_label": "email"
        }
      }
    }
  ]
}'

Fusionner des utilisateurs non identifiés

external_id La demande suivante fusionnerait l’utilisateur non identifié dont l’adresse e-mail est “john.smith@braze.com” avec l’utilisateur dont l’adresse e-mail est “ john “. L’utilisation de most_recently_updated permet de filtrer la requête pour afficher un seul utilisateur non identifié. Ainsi, s’il y avait deux utilisateurs non identifiés avec cette adresse e-mail, un seul serait fusionné dans l’utilisateur avec external_id “john”.

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": "john.smith@braze.com",
        "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é dont l’adresse e-mail est “john.smith@braze.com” avec l’utilisateur identifié dont l’adresse e-mail est “john.smith@braze.com”. L’utilisation de most_recently_updated filtre les requêtes pour afficher un seul utilisateur (un utilisateur non identifié pour identifier_to_merge et un utilisateur identifié pour 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": "john.smith@braze.com",
        "prioritization": ["unidentified", "most_recently_updated"]
      },
      "identifier_to_keep": {
        "email": "john.smith@braze.com",
        "prioritization": ["identified", "most_recently_updated"]
      }
    }
  ]
}'

Fusionner un utilisateur non identifié sans inclure la priorisation most_recently_updated

S’il y a deux utilisateurs non identifiés avec l’adresse e-mail “john.smith@braze.com”, cet exemple de demande ne fusionne aucun utilisateur puisqu’il y a deux utilisateurs non identifiés avec cette adresse e-mail. Cette demande ne fonctionne que s’il n’y a qu’un seul utilisateur non identifié dont l’adresse e-mail est “john.smith@braze.com”.

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": "john.smith@braze.com",
        "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.