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).

This let’s you know your TikTok campaign is more effective than your Applovin campaign for that unique user.

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).
  • For TikTok discrepancies, please refer to isto guide

“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.

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