Mesclar usuários

Use esse ponto de extremidade para mesclar um usuário em outro usuário.

Até 50 mesclagens podem ser especificadas por solicitação. Esse ponto de extremidade é assíncrono.

Pré-requisitos

Para usar esse endpoint, você precisará de uma chave de API com a permissão users.merge.

Limite de taxa

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.

Corpo da solicitação

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

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

Parâmetros de solicitação

Comportamento de mesclagem

O comportamento documentado abaixo é verdadeiro para todos os recursos da Braze que não são alimentados pelo Snowflake. As fusões de usuários não serão refletidas na guia Histórico de mensagens, Extensões de segmento, Criador de consultas e Currents.

Esse endpoint mesclará qualquer um dos seguintes campos se eles não forem encontrados no usuário segmentado:

• Nome
• Sobrenome
• E-mail
• Gênero
• Data de nascimento
• Número de telefone
• Fuso horário
• Cidade natal
• País
• Idioma
• Informações sobre o dispositivo
• Contagem de sessões (a soma das sessões de ambos os perfis)
• Data da primeira sessão (o Braze escolherá a data mais cedo entre as duas datas)
• Data da última sessão (o Braze escolherá a data mais recente entre as duas datas)
• Atributos personalizados (os atributos personalizados existentes no perfil de destino são mantidos e incluirão atributos personalizados que não existiam no perfil de destino)
• Dados de eventos personalizados e de eventos de compra
• Propriedades de eventos personalizados e de eventos de compra para a segmentação “X vezes em Y dias” (onde X<=50 e Y<=30)
• Resumo dos eventos personalizados segmentáveis
  • Contagem de eventos (a soma de ambos os perfis)
  • O evento ocorreu pela primeira vez (o Braze escolherá a data mais antiga entre as duas datas)
  • Evento ocorrido pela última vez (o Braze escolherá a data mais recente entre as duas datas)
• Total de compras no app em centavos (a soma de ambos os perfis)
• Número total de compras (a soma de ambos os perfis)
• Data da primeira compra (o Braze escolherá a data mais antiga entre as duas datas)
• Data da última compra (o Braze escolherá a data mais recente entre as duas datas)
• Resumos do app
• Campos Last_X_at (o Braze atualizará os campos se os campos do perfil órfão forem mais recentes)
• Dados de interação da campanha (o Braze escolherá os campos de data mais recentes)
• Resumos do fluxo de trabalho (o Braze escolherá os campos de data mais recentes)
• Histórico de mensagens e de engajamento com mensagens

Os dados de sessão só serão mesclados se o app existir em ambos os perfis de usuário.

Comportamento da data do evento personalizado e da data do evento de compra

Esses campos mesclados atualizarão os filtros “para X eventos em Y dias”. Para eventos de compra, esses filtros incluem “número de compras em Y dias” e “dinheiro gasto nos últimos Y dias”.

Envio de usuários por e-mail ou número de telefone

Se um email ou phone for especificado como um identificador, um valor adicional prioritization será necessário no identificador. O prioritization deve ser uma matriz que especifica qual usuário deve ser mesclado se houver vários usuários encontrados. prioritization é uma matriz ordenada, ou seja, se mais de um usuário corresponder a uma priorização, a mesclagem não ocorrerá.

Os valores permitidos para o vetor são: identified, unidentified, most_recently_updated. most_recently_updated refere-se à priorização do usuário atualizado mais recentemente.

Somente uma das opções a seguir pode existir na matriz de priorização por vez:

• identified refere-se à priorização de um usuário com uma external_id
• unidentified refere-se à priorização de um usuário sem um external_id

Exemplos de solicitações

Solicitação básica

Esse é um corpo de solicitação básico para mostrar o padrão da solicitação.

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"
        }
      }
    }
  ]
}'

Mesclando usuário não identificado

A solicitação a seguir mesclaria o usuário não identificado atualizado mais recentemente com o endereço de e-mail “john.smith@braze.com” no usuário com external_id “john”. Usar most_recently_updated filtra a consulta para apenas um usuário não identificado. Portanto, se houvesse dois usuários não identificados com esse endereço de e-mail, apenas um seria mesclado no usuário com 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"
      }
    }
  ]
}'

Mesclando usuário não identificado com usuário identificado

O próximo exemplo mescla o usuário não identificado atualizado mais recentemente com o endereço de e-mail “john.smith@braze.com” com o usuário identificado atualizado mais recentemente com o endereço de e-mail “john.smith@braze.com”. Usar most_recently_updated filtra as consultas para apenas um usuário (um usuário não identificado para identifier_to_merge e um usuário identificado para 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"]
      }
    }
  ]
}'

Mesclar um usuário não identificado sem incluir a priorização mais_recentemente_atualizada

Se houver dois usuários não identificados com o endereço de e-mail “john.smith@braze.com”, esse exemplo de solicitação não mescla nenhum usuário, pois há dois usuários não identificados com esse endereço de e-mail. Essa solicitação só funcionará se houver apenas um usuário não identificado com o endereço de e-mail “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"
      }
    }
  ]
}'

Resposta

Há duas respostas de código de status para esse endpoint: 202 e 400.

Exemplo de resposta bem-sucedida

O código de status 202 poderia retornar o seguinte corpo de resposta.

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

Exemplo de resposta de erro

O código de status 400 poderia retornar o seguinte corpo de resposta. Consulte Solução de problemas para obter mais informações sobre os erros que você pode encontrar.

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

Solução de problemas

A tabela a seguir lista as possíveis mensagens de erro que podem ocorrer.