Medir o desempenho conjunto em aplicativos e web: o resultado do rastreamento entre dispositivos

Se há anos que o cachorro é o melhor amigo do homem, questionámos desde há alguns anos (sem muitos) poderíamos dizer que, em certa medida, o smartphone está começando a ocupar cada vez mais o lugar do pelo de quatro patas. E não os decimos nosotros desde Singular, mas qualquer pessoa com cara e olhos para ele no seu dia a dia.

E então comprove os dados:

​​

No entanto, se é certo que o celular cada vez é mais do que o Rey, há muito conteúdo que hoje será visto em outras plataformas . Você já é tradicional (como desktop ou tablet) ou via outros novos como smartwatches / videoconsolas, etc.

Além disso, aqui não acaba a coisa, mas dentro de cada plataforma própria, podemos ter grandes diferenças. No entanto, quando falamos sobre o consumo de internet em dispositivos móveis, incluímos os grandes mundos:

• Consumo via navegadores no celular 
• Consumo via aplicativos mobile  

E, de novo, embora os aplicativos sejam as rainhas da festa “móvel”, é claro que também há pessoas consumindo Internet por meio de navegadores em seus smartphones. Menos, mas o feno. 

Por isso, nos encontramos com três realidades:

• Os usuários podem interagir com marcas através de diferentes plataformas, como 
• Os usuários, dentro de uma plataforma como o celular, podem nos conhecer ou nos levar pela web ou por um aplicativo

Então, como sabemos a verdade, como conhecemos um usuário?

Este é um dos grandes retos da atribuição moderna. Sim, é isso que se conhece como medição entre dispositivos , sendo a forma na qual medimos (ou pelo menos o que tentamos) os usuários que nos levaram através de diferentes locais.

Para simplificar, diremos que esta atribuição se divide em dois grandes mundos:

• Medição na web : mede tudo o que ocorre em uma web, onde não teremos grandes diferenças (para não complicar mais) entre a web no desktop e a web no celular. Porque se miden de uma maneira “bastante similar”
• Medição do aplicativo : onde medimos o que ocorre nos aplicativos móveis. E é aqui que precisaremos da ajuda de um MMP ( Mobile Measurement Partner) para entender melhor como é original, não apenas as descargas, mas tudo o que ocorre depois. Incluindo a receita, porque queremos que nossa empresa tenha dinheiro, ¿verdad?

Por que precisamos medir o que ocorre entre dispositivos (cross-device)?

Piensa en ti mismo planejando umas férias de duas semanas na cidade de Nova York. 

• Pesquisa no Google “o que fazer em Nova York em 14 dias” enquanto você está esperando um ônibus / trem 
• Leia alguns artigos interessantes e comece a entender que há mais Nova York além de Manhattan, que o Central Park é mais grande do que você pensa, que o Empire State precisa de um ingresso especial e que você ou você tem um Madison Square Garden para ver uma festa dos Knicks. Mesmo que você tenha um olho na cara. 
• Uns dias mais tarde empiezas a mirar voos na web do Skyscanner como seu descanso para começar o trabalho. Deixe alguns favoritos e empiezas a dar-te conta de que a viagem para Nova York barato não vai ser. Mas, como dirían los americanos “ YOLO ” (You Only Live Once ou “que la vida se vive uma vez”).
• De volta ao trabalho, no aplicativo do TikTok, há um anúncio do aplicativo do Airbnb, com um anúncio focado em ir para Nova York. Piensas que “te escuchan” mas você se esquece rapidamente e instala o aplicativo. Procurei ver o que há em Nova York durante um rato, mas já o deixei.   
• Dos dias depois, enquanto espera na sala de espera do dentista, você entra em uma onda de adrenalina e reserva os bilhetes de avião por meio do aplicativo Skyscanner. 
• E a cada dois dias, encontrei uma “ganga” de piso no Airbnb porque você recebeu um e-mail que abriu no seu computador e decidiu reservar. Era agora ou nunca.   

Você está suena? Você pode extrapolar isso para qualquer circunstância de sua vida onde você pode interagir com marcas através de diferentes plataformas. Sim, a jornada do cliente de um usuário não é “monoplataforma”. Vamos saltar de um em outro em função de nosso momento vital e isso obriga as marcas a medir (ou perseguirmos) lá por onde vamos. 

Porque se um usuário ou um anúncio focado em baixar o aplicativo, mas depois de gerar a compra / reserva na web, precisamos ter alguma forma de cruzar esses dois pontos. Também ocorreu em plataformas diferentes. Porque Juan / Lucía / María / Fran / Lucas u Olinda siguen siguen ellos mismos allá onde usen internet. A pesar da plataforma que você está usando.

E assim como um profissional de marketing, se você está gastando dinheiro em campanhas focadas no download do aplicativo, você quer saber o desempenho que ele teve (ou seja, o ROAS) independentemente de onde a transação ocorreu. Se ocorrer no próprio aplicativo, é mais fácil de medir. Mas se isso acontecer na web, você não decidiu medi-lo e olhar para o outro lado, o que é verdade?

Identificando os usuários entre os diferentes dispositivos/plataformas 

Se sabemos que Juan / Lucía / María / Fran / Lucas e Olinda usam aplicativos e sites indiferentemente, como podemos identificá-los a cada um deles? Da mesma maneira que as Administrações utilizam o NIF (Número de Identificação Fiscal), um identificador único de cada cidadão, também temos que poder ter algum tipo de indicador que nos permite reconhecer sempre nossos usuários. Algo assim como ponerles uma prenda que nos permita, onde quer que esteja, reconheça que eles são.  

Se você já trabalhou algumas vezes com equipamentos técnicos ou de dados, saiba da existência (quase sempre) de um conceito chamado User ID. Trata-se de um identificador que os usuários suelen tener quando se registram em um produto. É independente da plataforma / dispositivo onde ele é registrado e, quando isso acontece, ele gera um identificador exclusivo para cada usuário na base de dados da empresa. 

Bem, esse ID de usuário (que também pode ser visto como u_id, user_id, UID, etc) provavelmente será o identificador mais robusto que podemos ter para identificar o usuário onde quer que esteja (web desktop, web móvel, aplicativo, etc). 

ID do usuário em cada “ação” (evento) do usuário 

É por isso que, se queremos identificar o usuário graças ao seu identificador, um dos parâmetros que temos que sempre “medir” das ações do usuário é este ID de usuário. Assim que…

• Se o usuário entrar no aplicativo… rastrearemos um evento de app_open e adicionaremos seu ID de usuário como um dos parâmetros deste evento
• Se o usuário deixar o checkout do nosso ecommerce na web, rastrearemos um evento de checkout_viewed e adicionaremos o User ID como um dos parâmetros deste evento
• Se o usuário fizer uma correspondência no aplicativo de citações que temos, enviaremos um evento de match_occured e mediremos o ID do usuário. E neste caso concreto, muito provavelmente o mediremos para os usuários, com seu respectivo ID de usuário. Porque não há amor (ni match) sem duas pessoas involucradas, ¿verdad?

E assim por diante com todas as ações do usuário. Se algo tivermos que tratar de medir com cada ação que o usuário faz é o ID do usuário. Porque como dizemos, é o identificador mais robusto que podemos tentar tentar “encontrar” o usuário onde você está e fazer o que fez. E não nos decimos, mas o todo poderoso Google também recomenda enviar um ID de usuário para poder fazer o rastreamento entre dispositivos (no caso, entre plataformas). Porque o Google pode fazer o rastreamento entre dispositivos sem ter identificadores exclusivos para o usuário

O que nos ajuda no dia a dia ter este ID de usuário?

Como este ID é identificado de forma clara e compatível com o usuário, nos permitirá medir tudo o que você tem. Dessa forma, todos os usuários mais têm claramente identificado o ID do usuário, por exemplo, podemos ler:

• Medindo a Receita Média por Usuário (ARPU), o que me ajudará a entender quanto dinheiro de mídia gerou para meus usuários. E com ele, saiba quais segmentos são mais interessantes para:
  • Entender que tipo de usuário nos vale mais valor. Com base no gênero, país de origem, tipologia de produto que consome, tempo no produto, etc. 
  • Faça campanhas Lookalike com esses usuários e obtenha usuários “semelhantes” no produto
  • Poderíamos saber o que esses usuários (patronos) fizeram para tentar fomentar que o resto o fizesse. Aqui é onde entramos no reino da Analítica de Produto ou Análise de Produto. 
• Entendemos melhor a retenção no produto, pois podemos medir o volume de usuários que retornam todos os dias (Usuários ativos diários ou DAU), todas as semanas (Usuários ativos semanais ou WAU) ou meses (Usuários ativos mensais ou MAU). 
• Podemos añadir esses usuários a herramientas de terceros. Por exemplo, há muitas ferramentas (como alguns CRMs) que só permitem que usuários se identifiquem com um ID de usuário. Pelo contrário, não podemos usar certas capacidades para enviar e-mails ou notificações push a esses usuários (embora tenhamos outras formas de fazer algo mais “artesanal”).

E outro longo etc. de coisas que não poderíamos fazer, mas que deixamos para outros artigos.  

Se você não tem ID de usuário… não pode fazer rastreamento entre dispositivos?

Resposta curta: sim, sim, você pode fazer isso. Há empresas que não trabalham com o User ID quando um usuário se registra (isso daria para uma longa conversa), mas guardariam o e-mail de registro do usuário. Muito bem, podemos usar esse e-mail como identificador do usuário. 

Mas ele sabe que um mesmo usuário pode registrar um produto com vários e-mails. Porque a solidez do e-mail como identificador único é menor que a de um ID de usuário gerado de maneira automática em sua base de dados. É dito: 

• Um usuário com ID de usuário pode ter dois (ou três ou quatro) e-mails associados
• Um e-mail de um usuário nunca deveria ter mais de um ID de usuário 

Sim, por isso você tem e-mails com mais de um ID de usuário, aqui está outro tipo de problema um pouco mais sério. Recomendamos conversar com seus desenvolvedores e encontrar uma solução com antecedência.  

Além disso, há outras circunstâncias onde não podemos ter User ID como identificador do usuário:

• O usuário atual não foi registrado em um dispositivo 
• O usuário não exige “registro” para usar o produto 

Vejamos ambos os casos um pouco mais detalhados

Usuário não registrado em uma plataforma

Seguindo o exemplo do Skyscanner de antes, você poderia dar o exemplo de que você já foi registrado no Skyscanner por meio do aplicativo, usa a web sem logar. É dito, sem dizer, entrar com seu usuário e contrasenha e que o Skyscanner “ sepa que você é você ”.

Aqui o rastreamento entre dispositivos é algo mais complexo, já que o Skyscanner não tem ideia de que esses voos estão olhando para você no aplicativo. Sabe que alguém está olhando para Nova York, mas como ele viu a roupa que você identificou, não sabe que você é você.

Se bem, esta visita que você está fazendo é que gera um identificador (ID) da visita / sessão. Nomeamos um exemplo: 

• Seu ID de usuário no Skyscanner é: ABC123
• O ID da sessão no aplicativo é: S19101199

O ideal é, de alguma forma, associar que S19101199 pertence ao ID do usuário ABC123. Porque uma vez o hagamos, saberemos que esse usuário fez ações X, Y ou Z. É o que na indústria de dados se conhece como fazer “cosido” ou, em inglês, costura .

O usuário não requer registro para usar o produto 

Outras situações possíveis em que um usuário não possui ID de usuário parte do número de marcas que, para usá-las, não são obrigados a registrar ou logar. Piensa em sites de jornais, onde você não precisa de um medidor de credenciais de nenhum tipo. Ou algum aplicativo que você pode usar para remover arquivos duplicados do seu celular. Em geral, estes produtos:

• Bem, não é necessário que o usuário se registre para gerar valor no negócio. Por exemplo, os jornais vivem:
  • Ao aprender anúncios, quais são segmentados usando outras fontes de dados, como as informações que podem ser acessadas do navegador ou do próprio dispositivo (localização, idioma, etc.) 
  • Os modelos de assinatura onde você deseja ler uma notícia Premium em um meio estão “detrás” de um acesso pago e precisam acessar credenciais próprias. Um correio e uma senha que você adivinha que o identificador estará associado apenas com total segurança? Na verdade, com um ID de usuário

• Gerar ingressos com modelos que não exigem informações de algum usuário. Por exemplo, um aplicativo que oferece serviços de VPN, onde os registradores ao mesmo tempo são levemente desalineados com o que procuram alguns (que não todos) os usuários que usam VPN. 

Então, como vamos fazer essa identificação para o usuário? 

Se você foi informado até aqui, você sabe que ter informações do usuário é mais valioso do que ter um dispositivo ou sessão, verdade? Porque, repetimos:

• Cada usuário deveria ter um identificador único robusto, idealmente um ID de usuário que não fosse o e-mail. 
• Um dispositivo pode ter vários IDs de sessão
• Um ID de usuário pode ter vários IDs de dispositivo 

Para chegar à conclusão de quais IDs “suaves” (sessão, dispositivo, etc.) correspondem a cada ID “forte·(User ID), temos que levar a cabo um processo de coleta de dados e consolidação dos mesmos. Tudo isso para gerar algo assim como uma espécie de histórico de tudo o que faz um usuário.

Este histórico é denominado Gráfico de Identidade ou Gráfico de Identidade . Este “histórico” gera uma visão unificada de nossos usuários / clientes com base nas diferentes interações. E isso é feito, em parte, através de um processo de Resolução de Identidade ou Resolução de Identidade, o que nos permite “reconciliar e unificar” todo o caminho do usuário através de sessões, plataformas / dispositivos, etc.

E para ele, siga três passos:

1. identificar as ações do usuário 

2. Consolidar os dados identificados uma vez 

3. Cruzar esta entre plataformas 

1. identificar as ações do usuário

Já o explicamos anteriormente. É possível associar tanto quanto podemos cada ação a um ID de usuário. E aí: 

• Se usar Singular como MMP para seus aplicativos, você deve associar cada evento que deseja medir o ID do usuário. E isso tende a fazer tanto para seus aplicativos Android quanto para seus aplicativos iOS
• Se seu produto também estiver conectado à web, você também terá que usar o WebSDK e enviar o ID do usuário dos eventos que ocorreram

Se chegarmos até aqui, por agora teremos plataformas separadas, midiendo (com suerte) as ações dos usuários que usam algumas ou todas elas. Se for honesto, o normal será usar, como muitos deles (Android + Web ou iOS + Web), já que é raro o caso de um usuário que possui um dispositivo iOS e Android simultaneamente. Mas vale mais prevenir do que curar. 

2. Consolidar os dados identificados uma vez 

Uma vez que Singular fez seu trabalho (identificação e atribuição por dispositivo), ele enviará esses dados usando um processo de ETL. Desde Singular, você pode mandar toda esta informação para:

• Bases de dados e data warehouses como Google BiQuery, Snowflake, Redshift ou MySQL 
• Fontes de dados baseadas em filas como Google Sheets, Amazon S3 ou Google Cloud Storage

Entre os tipos que você pode exportar de Singular para esses destinos você tem:

• Dados de campanhas agregados : informações de gastos com publicidade, criatividade, instalações, etc. Isso é interessante, sobre tudo, para os equipamentos de aquisição de usuários.
• Dados de monetização por meio de anúncios agregados : mais focado em modelos de negócios que ganham dinheiro ensinando anúncios para seus usuários. Se você quiser saber mais sobre isso, você pode ler sobre monetização de anúncios em aplicativos
• Dados de nível de usuário : estes serão os mais relevantes para o rastreamento entre dispositivos que buscamos
• Dados de monetização por meio de anúncios no nível de usuário: semelhantes aos recomendados antes, mas com maior granularidade no nível de cada usuário. Você também pode ser interessante para rastreamento entre dispositivos se uma de suas formas de gerar ingressos no aplicativo for por meio de anúncios

3. Cruzar os dados para tomar decisões acertadas

Aqui é onde tendemos a envolver nossos equipamentos de dados. Dependendo do tipo de dados que temos, precisamos ou bem envolver Engenheiros de Dados (processamento, normalização e limpeza de dados) ou Analistas de Dados (representação de dados e extração de insights). 

Mas, como profissionais de marketing, como somos vistos por agora, fazemos grande parte do trabalho solo:

• Leyendo este artigo para entender sobre IDs suaves e fortes, Gráfico de Identidade, Resolução de Identidade, etc. 
• Escolha uma ferramenta que nos permita rastrear eventos do usuário com o User ID incorporado, como é o caso do Singular 
• Mandando os dados e rastreando qualquer destino que nos permita fazer uma análise mais detalhada 

Outras plataformas fazem o processo completo de rastreamento entre dispositivos. Está correto?

Resposta curta: não. Nenhuma ferramenta pode ser inventada por você um ID de usuário para poder “cruzar” os usuários que navegam em diferentes plataformas. Se você quiser o Google Analytics 4, embora ele diga alguns gurus da Analítica Web.

 No caso de plataformas como GA4, o que ocorre é que vários IDs são gerados:

• Pseudo ID do usuário : é um identificador associado a cada dispositivo. É dito que se seu usuário tiver capacidade de uso em Android, iOS e web, provavelmente terá três pseudo_user_id para cada usuário.

​​

• User ID: ID do usuário que é enviado do lado da marca. Repetimos, você tem que mandar você como marca. GA4 não foi criado nem pode ser criado. Se isso acontecesse, seria mais digno de um mago da Grifinória do que de uma plataforma de meditação.

Claro, além dos limites do GA4 como ferramenta de atribuição, esse “cosido” de IDs não é algo que pode ser visto de maneira semelhante no GA4. Você também exporta os dados do GA4 para o Data Warehouse do Google, BigQuery e trabalha com ele. E para isso, seu conhecimento e habilidades em dados têm sido bastante elevados.

Ou conte com um engenheiro de dados próximo.

Exemplo de uma tabela do BigQuery onde há o pseudo_user_id