Perguntas frequentes sobre atribuição

Ao utilizar o Tenjin, irá verificar que existem dois tipos de instalações: «Instalações comunicadas» e «Instalações monitorizadas».

Instalações declaradas são as instalações que a rede publicitária afirma ter gerado para cada uma das suas campanhas. Instalações monitorizadas são as instalações que uma entidade terceira imparcial atribui à campanha de uma rede publicitária, tendo em conta as outras campanhas que está a realizar noutras redes publicitárias. Ao analisar as «Instalações monitorizadas», está a analisar uma métrica de instalações holística – baseada em todas as campanhas, mesmo aquelas que está a realizar noutras redes de publicidade. As «Instalações Relatadas», por outro lado, são calculadas isoladamente pela rede de publicidade em que está a anunciar – baseiam-se apenas no que essa rede de publicidade regista.

Então, as «Instalações Reportadas» devem ser iguais às «Instalações Rastreadas»? Nem sempre. O objetivo da Atribuição NÃO é fazer com que as «Instalações Rastreadas» sejam iguais às «Instalações Reportadas». Na verdade, por vezes, a Atribuição deve fazer exatamente o oposto. O objetivo da atribuição é ter uma visão holística de TODA a atividade da campanha nas várias redes publicitárias que está a utilizar em simultâneo e atribuir os utilizadores à campanha mais adequada. Apenas uma entidade terceira imparcial pode fazer isto.

Por exemplo: Está a realizar campanhas em duas redes publicitárias ao mesmo tempo: a Applovin e o TikTok. Definiste os CPIs para $1,00 para cada campanha em cada rede publicitária. Um utilizador único clica na tua campanha da Applovin; mais tarde, esse mesmo utilizador clica na tua campanha da Tiktok e, em seguida, instala a aplicação. O que acontece? Como é que tudo é monitorizado para esse utilizador?

Uma vez que a Applovin e o TikTok não comunicam entre si, não há forma de conciliar o utilizador único que interage com ambas as campanhas publicitárias em redes distintas ao mesmo tempo. Consequentemente, o número de instalações reportadas pela Applovin seria “1” e o número de instalações reportadas pela Tiktok seria também “1”. Eis o que temos até agora:

Mas isto não faz sentido! Só conseguimos um único utilizador único! Um utilizador único só deve estar associado a uma das campanhas!

É isso que a Atribuição resolve. Ao utilizar um fornecedor de Atribuição de terceiros como a Tenjin, esta irá associar o utilizador à campanha do TikTok como uma “Instalação Rastreada” (com base no último clique, neste caso). Desta forma, o utilizador único que clicou no Applovin e, em seguida, no TikTok será associado à campanha do TikTok e NÃO à do Applovin. Neste exemplo, a contagem de «Instalações Rastreadas» e «Instalações Reportadas» ficaria assim:

Agora, o utilizador único encontra-se na campanha adequada da rede de publicidade, o que permite uma análise posterior das suas campanhas. Se o utilizador começar a gerar LTV, saberá qual é a eficácia do seu investimento. Esta é a única forma de medir o seu ROI numa comparação equitativa.

Suponhamos, então, que o utilizador adquirido gere um LTV de 90 dias de $2.5. A sua análise revelaria o seguinte:

Neste caso, o ROI = (LTV/Despesa - 1).

Isto permite-lhe saber que a sua campanha no Google é mais eficaz do que a sua campanha no Facebook para esse utilizador específico.

Normalmente, é de esperar uma discrepância de até 30% para as SANs e de 10% para as não-SANs, pelas razões abaixo indicadas:

• As redes de publicidade ignoram a tecnologia de atribuição de terceiros – a Meta, o Twitter, o Google e algumas outras empresas recorrem à sua própria tecnologia interna para informar os parceiros de atribuição quando uma instalação deve ser atribuída às suas redes. Quando os utilizadores destas redes se sobrepõem, a tecnologia de terceiros não consegue controlar se a rede publicitária reivindica uma instalação reportada, mesmo quando a tecnologia de atribuição seleciona apenas uma rede publicitária para associar o download.
• Os callbacks de instalação e os URLs de clique não estão configurados corretamente – O problema mais fácil de resolver é aquele em que os URLs de clique e os callbacks de instalação são configurados incorretamente pelo anunciante. Normalmente, isto pode ser resolvido imediatamente, verificando se estão a ser utilizados os URLs de clique corretos e se o callback de instalação na tecnologia de atribuição está a funcionar corretamente.
• São utilizados métodos imprecisos para monitorizar cliques e instalações com os SDKs das redes de publicidade – Quando uma rede de publicidade não suporta a recolha de um identificador de publicidade (IDFA ou GAID), a tecnologia de atribuição de terceiros recorre geralmente à atribuição probabilística.
• Duplicação de SDKs de redes de publicidade e de atribuição – Os sistemas de atribuição enviam callbacks de instalação às redes de publicidade para notificá-las de uma instalação. Se a aplicação tiver um SDK duplicado que envie callbacks de instalação à rede de publicidade, poderá ocorrer uma contagem dupla das instalações reportadas.
• As redes de publicidade utilizam uma janela de atribuição diferente da nossa (normalmente para SANs).

“A ”retenção“ é um conceito simples, mas há vários pormenores a ter em conta na sua implementação. Por predefinição, na Tenjin, calculamos a retenção ”clássica»: um utilizador retido durante N dias é aquele que regressa no N.º dia após a aquisição. O dia em que um utilizador regressa pode parecer claro e simples, mas, na realidade, há duas formas de interpretar isto: (1) utilizando o tempo absoluto ou (2) utilizando o tempo relativo. A título de exemplo de tempo absoluto, um utilizador adquirido a 1 de maio e que regressa a 2 de maio é designado por utilizador de 1 dia. No entanto, se esse utilizador tiver sido adquirido às 23:59 de 1 de maio e tiver regressado às 00:01 de 2 de maio, na realidade esperou apenas 2 minutos para regressar.

• Na Tenjin, por predefinição, utilizamos o tempo relativo. Cada utilizador tem o seu próprio “período de vida”, contado em dias a partir do momento da aquisição. O seu “nascimento” ocorre no momento da aquisição, no dia 0, e o dia 1 começa 24 horas depois. Um utilizador retido durante N dias é aquele que regressa entre 24N horas e 24(N+1) horas após a aquisição

Taxa de retenção de N dias = utilizadores únicos retidos durante N dias / utilizadores únicos no 0.º dia

• Acreditamos que a utilização do tempo relativo coloca todos os utilizadores em pé de igualdade, independentemente do fuso horário em que se encontrem ou do seu ritmo circadiano. Permite-nos também “normalizar” as nossas outras métricas ao longo do ciclo de vida, tais como a receita acumulada, o ROI acumulado e o custo por utilizador retido. (NOTA) A Tenjin suporta agora o cálculo da Taxa de Retenção utilizando a estratégia de coorte baseada no UTC. Com esta abordagem, o Dia 1 começa à meia-noite UTC seguinte ao registo de data e hora da instalação de cada utilizador. Este método ajuda a alinhar os cálculos da Taxa de Retenção com outras plataformas que utilizam registos de data e hora baseados no UTC, reduzindo as discrepâncias nas métricas.

Para ativar esta funcionalidade na sua conta, aceda a «A minha conta» → «Gerir utilizador» → «Estratégia de coorte» e selecione a opção pretendida.

Como vimos acima, na opção de retenção relativa, um utilizador retido durante N dias é aquele que regressa entre 24N horas e 24(N+1) horas após a aquisição

Talvez a melhor forma de compreender isto seja ver um exemplo.

• Os utilizadores pertencentes à coorte “1 de setembro” foram registados entre as 00:00 de 1 de setembro de 2015 e as 23:59 de 1 de setembro de 2015.
• O utilizador mais recente de “1 de setembro” (vamos chamá-lo de Joe) pode ter sido registado às 23:59 de 1 de setembro de 2015.
• O dia 0 do Joe tem a duração de 24 horas, terminando às 23:59 de 02/09/2015.
• Se o Joe regressar em qualquer momento entre as 23:59 de 2 de setembro de 2015 e as 23:59 de 3 de setembro de 2015, será considerado um utilizador retido por 1 dia.
• Por conseguinte, a taxa de retenção de 1 dia para a coorte “1 de setembro” só fica definida a partir das 00:00 de 4 de setembro de 2015.

Em geral, a taxa de retenção no dia x para uma determinada coorte só fica definida DEPOIS de (x+2) dias COMPLETOS após a aquisição. Ou, por outras palavras, no (x+3)º dia, essa taxa permanecerá constante.

Pode parecer estranho esperar 3 dias inteiros para que esta métrica se estabilize. De onde vêm esses dias e como os explicamos? Na pior das hipóteses, um utilizador poderia ser adquirido no final do dia (“Dia #1”). O seu 0.º dia (período inicial de 24 horas) não conta para a retenção (“Dia #2”). E, na pior das hipóteses, ele poderia regressar no final do período de 24 horas do x.º dia (“Dia #3”).

• A Tenjin recolhe as receitas de compras in-app diretamente através do seu SDK, enquanto o iTunes Connect ou a Google Play Console apresentam esses valores diretamente através das compras efetuadas na loja. Com base na nossa experiência, essas receitas podem apresentar uma diferença de até 20%.
• Estas são as possibilidades caso detete uma grande discrepância.
• A receita da Tenjin é líquida (após a dedução de 30% pela Apple/Google Play Store)
• (Apenas para iOS) Se não validar os recibos, a Tenjin contabiliza todas as receitas que passam pelo nosso SDK. No entanto, algumas receitas podem ser rejeitadas pela Apple. Para evitar isso, certifique-se de que utiliza a nossa validação de recibos (SDK iOS)
• Se tiver acabado de integrar o nosso SDK e a atualização da aplicação for voluntária, alguns utilizadores ainda não terão o SDK da Tenjin instalado. Nesse caso, não verá todas as receitas na Tenjin. Esta situação deverá resolver-se com o passar do tempo.

Quando se fala em “receita” em geral, existem dois tipos de receita: de coorte e não de coorte. No Tenjin, fazemos uma distinção clara entre estas duas. A “receita” é sempre um valor não-coorte e o “LTV” é sempre um valor de coorte, por definição. Vejamos um exemplo. Suponhamos que hoje é 20/10:

Neste exemplo,

• Receita total = $94,27
• LTV total a 90 dias = $91,70

Isto significa que a aplicação gerou $94,27 a partir de todos os utilizadores (independentemente da data em que foram adquiridos) em setembro (não coorte) e que a aplicação gerou $91,70 ao longo da vida útil a partir dos utilizadores que foram adquiridos em setembro (coorte). A receita é normalmente útil na gestão do fluxo de caixa diário e o LTV serve para medir o ROI da sua campanha.

Tenha em atenção esta diferença quando comparar os números do Tenjin com os números que vê noutras ferramentas. Também separamos as receitas de compras in-app (ou LTV) das receitas publicitárias (ou LTV), para que possa ver de onde provêm as suas receitas.

A receita corresponde ao fluxo de caixa diário durante o intervalo de datas selecionado.

• No intervalo de datas entre 1 e 30 de setembro, todos os utilizadores geraram $94,27 em receitas decorrentes da atividade da aplicação (compras dentro da aplicação ou receitas publicitárias) que ocorreu nesse intervalo de datas

O LTV de x dias corresponde à receita gerada pelos utilizadores adquiridos (que instalaram a aplicação) durante o intervalo de datas selecionado, calculada como o total acumulado ao longo de X dias após a instalação da aplicação.

• É importante saber o que se entende por “hoje”, em relação ao intervalo de datas selecionado, porque é necessário saber há quanto tempo os utilizadores incluídos estão registados. Se hoje for 20 de outubro e o intervalo de datas indicado for de 1 a 30 de setembro, os seus utilizadores “mais antigos” têm 50 dias (20 de outubro menos 1 de setembro) e os seus utilizadores “mais recentes” têm 20 dias. O LTV total de 90 dias, $91,70, corresponde à receita total gerada pelos utilizadores em 30 coortes (cada dia de setembro). Consequentemente, dado este intervalo de datas no exemplo, o LTV de 50 dias, o LTV de 51 dias…, o LTV de 89 dias e o LTV de 90 dias teriam todos o mesmo valor, uma vez que os seus utilizadores mais antigos só conseguem gerar 50 dias de receita após a instalação.

Será que a receita chegará alguma vez a igualar o LTV de x dias?

Provavelmente não. Seria necessário que TODOS os utilizadores, num único dia UTC (das 00:00 às 23:59), tivessem EXATAMENTE a mesma data de instalação. Isso é extremamente improvável.

É de esperar que haja discrepâncias entre os números de DAU do Tenjin e do Firebase, uma vez que a lógica utilizada para contar e acompanhar as instalações e o DAU é diferente em ambas as plataformas. No Tenjin, utilizamos o primeiro evento «app_open» como evento de instalação e todos os eventos «app_open» subsequentes são registados como sessões. Recomenda-se também utilizar sempre o SDK mais recente do Tenjin e inicializá-lo em cada «OnResume». Se continuar a observar grandes discrepâncias nos dados, envie-nos um e-mail para support@tenjin.com com os detalhes para que possamos investigar mais a fundo.

O UUID (ID de instalação do Analytics) gerado pelo Tenjin no momento da instalação não é persistente ao nível do dispositivo. Consequentemente, quando um utilizador reinstala a aplicação, o ID de instalação do Analytics é reiniciado, o que resulta na contagem de novas instalações. Isto pode causar um ligeiro aumento no número de instalações registadas, dependendo da frequência das reinstalações.

Se pretender dispor da métrica ‘Reinstalações monitorizadas’ para a sua aplicação, envie um e-mail para support@tenjin.com. Atualmente, essas reinstalações serão atribuídas apenas ao tráfego orgânico.

No que diz respeito aos eventos de instalação: a Meta costuma tratar automaticamente a deduplicação das instalações. Assim, se tanto o Meta SDK como o Tenjin reportarem uma instalação, esta normalmente conta apenas uma vez.

No caso de eventos no aplicativo (tais como compras, receitas ou impressões de anúncios): estes não são automaticamente deduplicados. Envie eventos a partir de apenas uma fonte: escolha entre o Tenjin ou o Meta SDK para enviar os seus eventos no aplicativo; não selecione ambos.

Desativar o registo automático de eventos no SDK da Meta: Se estiver a utilizar o SDK da Meta, desative a opção «autoLogAppEventsEnabled» para impedir que este envie eventos relacionados com receitas/compras por predefinição.

Sim! A Tenjin suporta a atribuição de crédito para os Meta Instant Games. Para obter instruções detalhadas sobre como configurar esta funcionalidade, contacte a equipa de apoio da Tenjin através de support@tenjin.com