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 à cet endpoint une limite de débit partagée de 20 000 requêtes par minute. 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.

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

• Prénom
• Nom
• les adresses e-mail (sauf si elles sont 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 choisit la première des deux dates)
• Date de la dernière session (Braze choisit la dernière des deux dates)
• 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énement personnalisé et d’achat pour la segmentation “X fois dans 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)
  • Date à laquelle l’événement s’est produit pour la première fois (Braze choisit la première des deux dates)
  • Dernière date à laquelle l’événement s’est produit (Braze choisit la date la plus tardive des 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 choisit la première des deux dates)
• Date du dernier achat (Braze choisit la date la plus tardive des deux dates)
• Résumés des applications
• Last_X_at champs (Braze met à jour les champs si les champs du profil orphelins 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 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 mettent à jour les filtres “pour X événements dans 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 une valeur email ou phone est spécifiée comme identifiant, vous devez inclure une valeur prioritization supplémentaire dans l’identifiant. L’adresse prioritization doit être un tableau ordonné spécifiant l’utilisateur à fusionner si plusieurs utilisateurs sont trouvés. Cela signifie que si plusieurs utilisateurs correspondent à un ordre de priorité, il n’y a pas de fusion.

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é dont l’adresse e-mail est la plus récente ( [email protected] ) avec l’utilisateur dont l’ID externe est john. Dans cet exemple, l’utilisation de most_recently_updated permet de filtrer la requête sur 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 qui a un 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é dont l’adresse e-mail est la plus récente ( [email protected] ) avec l’utilisateur identifié dont l’adresse e-mail est la plus récente ( [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 y a deux utilisateurs non identifiés avec l’adresse e-mail [email protected], cet exemple de demande ne fusionne aucun utilisateur car 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é 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.