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

Aplicamos um limite de taxa compartilhado de 20.000 solicitações por minuto para este endpoint. Esse limite de frequência é compartilhado com os endpoints /users/delete, /users/alias/new, /users/identify e /users/alias/update, conforme documentado em Limites de frequência da API.

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 ponto de extremidade mescla os seguintes campos se eles não forem encontrados no usuário de direcionamento.

• Nome
• Sobrenome
• Endereços de e-mail (a menos que sejam criptografados)
• 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 escolhe a data mais cedo entre as duas datas)
• Data da última sessão (o Braze escolhe a última data entre as duas datas)
• Atributos personalizados (o Braze retém os atributos personalizados existentes no perfil de destino e inclui 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 escolhe a data mais antiga entre as duas datas)
  • Evento ocorrido pela última vez (o Braze escolhe 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 escolhe a data mais antiga entre as duas datas)
• Data da última compra (o Braze escolhe a data mais recente das duas datas)
• Resumos do app
• Last_X_at campos (o Braze atualiza os campos se os campos do perfil órfão forem mais recentes)
• Dados de interação da campanha (o Braze seleciona os campos de data mais recentes)
• Resumos do fluxo de trabalho (o Braze seleciona os campos de data mais recentes)
• Histórico de mensagens e de engajamento com mensagens
• O Braze mescla os dados da sessão somente 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 atualizam 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, você deverá incluir um valor prioritization adicional no identificador. O prioritization deve ser uma matriz ordenada que especifica qual usuário deve ser mesclado se forem encontrados vários usuários. Isso significa que, se mais de um usuário corresponder a uma priorização, a mesclagem não ocorrerá.

Os valores permitidos para a matriz são:

• identified
• unidentified
• most_recently_updated (refere-se à priorização do usuário atualizado mais recentemente)
• least_recently_updated (refere-se à priorização do usuário atualizado menos 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": "[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"
        }
      }
    }
  ]
}'

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 [email protected] no usuário com um ID externo john. Neste exemplo, o uso de most_recently_updated filtra a consulta para 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 com o usuário que tem um ID externo 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"
      }
    }
  ]
}'

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 [email protected] com o usuário identificado atualizado mais recentemente com o endereço de e-mail [email protected].

Usar most_recently_updated filtra as consultas para 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": "[email protected]",
        "prioritization": ["unidentified", "most_recently_updated"]
      },
      "identifier_to_keep": {
        "email": "[email protected]",
        "prioritization": ["identified", "most_recently_updated"]
      }
    }
  ]
}'

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

Se houver dois usuários não identificados com o endereço de e-mail [email protected], essa solicitação de exemplo não mesclará nenhum usuário porque há dois usuários não identificados com esse endereço de e-mail. Essa solicitação só funciona se houver apenas um usuário não identificado com o endereço de 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"
      }
    }
  ]
}'

Resposta

Existem dois códigos de status para este 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.