Skip to content

Fusionner les utilisateurs

post

/users/merge

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 limite de 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 requête

1
2
Content-Type: application/json
Authorization: Bearer YOUR_REST_API_KEY
1
2
3
{
  "merge_updates" : (required, array of objects)
}

Paramètres de requête

Comportement de fusion

Le comportement documenté ci-dessous s’applique à toutes les fonctionnalités de Braze qui ne sont pas alimenté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 Currents.

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

  • Prénom
  • Nom
  • Adresses e-mail (à moins qu’elles ne soient chiffrées
  • Genre
  • Date de naissance
  • Numéro de téléphone
  • Fuseau horaire
  • Ville d’origine
  • Pays
  • Langue
  • Informations sur l’appareil
  • Nombre de sessions (la somme des sessions des deux profils)
  • Date de la première session (Braze sélectionne la date la plus ancienne des deux)
  • Date de la dernière session (Braze sélectionne la date la plus récente des deux)
  • Attributs personnalisés (Braze conserve les attributs personnalisés existants sur le profil cible et inclut 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 d’événements personnalisés et d’événements d’achat pour la segmentation « X fois en Y jours » (où X<=50 et Y<=30)
  • Résumé des événements personnalisés segmentables
    • Nombre d’événements (la somme des deux profils)
    • Date de première occurrence de l’événement (Braze sélectionne la date la plus ancienne des deux)
    • Date de dernière occurrence de l’événement (Braze sélectionne la date la plus récente des deux)
  • Total des achats in-app 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 des deux)
  • Date du dernier achat (Braze sélectionne la date la plus récente des deux)
  • Résumés des applications
  • Champs Last_X_at (Braze met à jour les champs si ceux du profil orphelin sont plus récents)
  • Données d’interaction de Campaign (Braze sélectionne les champs de date les plus récents)
  • Résumés de flux de travail (Braze sélectionne les champs de date les plus récents)
  • Historique des messages et de l’engagement des messages
  • Braze fusionne les données de session uniquement si l’application est présente sur les deux profils utilisateurs.

Comportement des dates d’événements personnalisés et d’événements 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 un email ou un phone est spécifié comme identifiant, vous devez inclure une valeur prioritization supplémentaire dans l’identifiant. La prioritization doit être un tableau ordonné indiquant quel utilisateur fusionner si plusieurs utilisateurs sont trouvés. Cela signifie que si plusieurs utilisateurs correspondent à partir d’une priorisation, la fusion n’aura pas lieu.

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

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

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

  • identified donne la priorité à un utilisateur ayant un external_id
  • unidentified donne la priorité à un utilisateur n’ayant pas d’external_id

Exemples de requêtes

Requête de base

Voici un corps de requête basique pour illustrer 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 un utilisateur non identifié

La requête 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 externe john. Dans cet exemple, l’utilisation de most_recently_updated filtre la requête à un seul 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 de l’ID externe 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": "[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] avec l’utilisateur identifié le plus récemment mis à jour avec l’adresse e-mail [email protected].

L’utilisation de most_recently_updated filtre les requêtes à 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": "[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 la priorisation most_recently_updated

S’il existe deux utilisateurs non identifiés avec l’adresse e-mail [email protected], cette requête 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 codes de statut de réponse 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 en erreur

Le code de statut 400 pourrait renvoyer le corps de réponse suivant. Consultez la section 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.

New Stuff!