datavaviz 02.03

Como criar dashboards eficientes – DataViz Intermediate: 2 de 4

By | Dashboard, Dashboards, Digital Analytics, Google Analytics, Marketing Digital | No Comments

“Os dashboards tornam as decisões de negócio mais eficientes, na medida em que suportam o monitoramento do desempenho da marca e dos produtos no digital e de como estamos em relação aos objetivos. Isso nos permite obter uma visão a médio prazo se a estratégia está seguindo o rumo desejado e desenhar ações táticas para melhorar os resultados ainda em curso.”

Barbara Pamplona, Coordenadora de Operação da Sala de Performance da Fiat Chrysler Automobiles, cliente DP6

O que faz um dashboard ser eficiente?

Um dashboard pode ser considerado eficiente se ajuda a tomar melhores decisões estratégicas.

Para isso, é necessário entender a diferença entre medir e agir. É comum os relatórios recorrentes apenas informarem qual é a situação de determinado ativo ou unidade do negócio. Ou seja, apenas fazem a atividade de medir os dados. Mudar esse paradigma, para agir com base nos dados, demanda esforço analítico. E nem sempre há tempo para análises profundas antes de tomar as decisões!

Um dashboard comum apenas exibe o estado dos principais indicadores do negócio.

Contudo, o papel do dashboard deve ser facilitar a interpretação desses dados, e expor as principais ações para melhorar os resultados, da forma mais direta possível.

O dashboard pode ser considerado eficiente se exibe as principais necessidades e possibilidades de ação para melhorar os indicadores do negócio, de forma fácil de entender.

Como planejar um dashboard?

Para todas as fases do planejamento de um dashboard eficiente é necessário ter conhecimento sobre os objetivos e estratégias do negócio.

Um projeto de dashboard deve cuidar essencialmente de três camadas:

  1. Fontes de dados: é a coleta dos dados brutos. Na prática, envolve as ferramentas de coleta dos dados, que podem ser da própria empresa, de fornecedores parceiros ou de terceiros (1st, 2nd e 3rd party data). Para essa camada, é recomendável ter um conhecimento básico sobre as ferramentas, entender quais dados estão disponíveis e como podem ser extraídos – por exemplo, via API.
  2. Base de dados: é onde os dados estão organizados para alimentar os gráficos. Na prática, envolve as ferramentas de armazenamento de dados (data warehouse), o planejamento de métricas e dimensões e a configuração dos cruzamentos de dados. Para essa camada, recomenda-se ter conhecimento sobre estruturação de base de dados e linguagens de programação voltadas para a pesquisa de bancos de dados, como SQL.
  3. Interface do usuário: é onde os usuários visualizam e interagem com os dados através de gráficos. Na prática, envolve as ferramentas de visualização de dados (data visualization), com a criação dos gráficos e configurações visuais. Para essa camada, é recomendável ter no mínimo um conhecimento básico sobre visualização de dados e princípios de design. 

A interface do usuário pode ser dividida em dois aspectos:

Desenvolvimento: Consiste na identificação dos gráficos mais eficientes para acompanhar cada indicador de performance do negócio. As ferramentas comuns de visualização de dados oferecem um conjunto padrão de gráficos, mas gráficos mais avançados podem ser configurados usando linguagens de programação como JavaScript. Para esse aspecto, recomendamos também consultar nosso “Guia de gráficos básicos” e o artigo “Como escolher o melhor gráfico para meus dados”.

Visual: O planejamento visual não tem apenas o intuito de deixar os gráficos bonitos, pois sem uma boa configuração visual simplesmente corremos o risco de ninguém entender os dados que estão no dashboard! Por isso, para que um dashboard seja eficiente, é indispensável pensar em aspectos visuais. Para esse aspecto, recomendamos o artigo “5 dicas para facilitar a leitura e entendimento de gráficos”.

Como colocar em prática um dashboard eficiente?

Para criar um bom dashboard, é preciso passar por algumas etapas essenciais. Reduzimos o processo a alguns passos básicos:

Passo 1 – Levantamento de requisitos: é entender o que o negócio precisa e que pode ser resolvido ou ajudado com o dashboard. Significa compreender os objetivos e estratégias do negócio, e identificar os principais indicadores de performance (KPIs – Key Performance Indicators). Para essa etapa, recomendamos seguir a metodologia do Modelo de Mensuração de Marketing Digital (DM3 – Digital Marketing and Measurement Model).

Capturar

fonte: https://www.kaushik.net/avinash/digital-marketing-and-measurement-model/

Passo 2 – Planejamento de Dashboard: no planejamento é imprescindível reunir todos os envolvidos na construção do dashboard, juntamente com quem irá receber os dados, para definir métricas, dimensões e entender as particularidades e necessidades da equipe que vai consumir os dados. Além disso, nesta fase  é importante encontrar a melhor ferramenta para a criação do painel com base nos dados que serão extraídos.  

É possível dividir o planejamento em três áreas:

Usabilidade: Quais áreas da empresa vão acessar esses dados e de quais funcionalidades precisam? Quais são as ferramentas ou plataformas mais adequadas para as necessidades desse projeto?

Estrutura de dados: Quais são as métricas e dimensões que é preciso incluir no dashboard? Como esses dados se cruzam? De quais fontes vêm? Como devem ser estruturadas as bases de dados?

Visual: Quais são os gráficos mais adequados para cada conjunto de dados? Quais são os principais indicadores que devem ser mostrados como “big numbers” logo no início do dashboard? Qual é o padrão visual que o dashboard deve seguir? Como os aspectos visuais podem facilitar a interpretação dos dados?

Passo 3 – Configuração técnica: nesta etapa é necessário entender a viabilidade técnica  para construir o painel, sendo importante a participação de alguém com conhecimento sobre a ferramenta que vai ser utilizada e também sobre onde os dados serão  extraídos.

É necessário dividir a configuração técnica em duas frentes:

Configuração da base – é a integração dos dados em uma única base de dados ou armazém de dados (data warehouse). É configurar o nível intermediário entre as fontes de dados e a interface que será acessada pelos usuários finais.

Configuração da interface – é a criação visual dos gráficos na ferramenta, com alertas e esquema de cores, além do desenvolvimento avançado de gráficos com fórmulas ou linguagens como JavaScript.

Passo 4 – Refinamento: é acompanhar as ações tomadas a partir da interpretação do dashboard, e trabalhar em melhorias constantes. Esse passo é importante para que o dashboard permaneça útil para as estratégias da empresa, que podem mudar ao longo do tempo.

Quais medidas você tomou para tornar seus dashboards mais eficientes? Compartilhe aqui nos comentários!

Não deixe de ler os outros artigos sobre visualização de dados.

Série básica:

  1. Desafios e tendências da visualização de dados
  2. Como escolher o melhor gráfico para meus dados?
  3. Guia de gráficos básicos
  4. 5 dicas para facilitar a leitura e entendimento de gráficos

Série intermediária:

  1. Por que DataViz é essencial e como provar pro seu chefe – DataViz Intermediate: 1 de 4

Coautoria de:

20160601_110209-Copia-96x96Ingrid Pino: Participa de projetos de Data Science e Data Visualization em cinco países e atua há quatro anos com Inteligência de Negócios na área de Marketing, com foco em Digital Analytics e Análises de Mercado.

renata-galindo-96x96

Renata Galindo: Atua há 5 anos no mercado de Marketing Digital, tendo passado pela área de Performance Media e atualmente trabalha em Digital Analytics, com foco em análise, criação de dash’s e DataViz.

blacklistwhitelist

Whitelists vs. Blacklists na Mídia Programática

By | News | No Comments

Com a proliferação de sites de notícia falsa e com má reputação, é necessário que anunciantes que fazem uso de mídia programática deem atenção às estratégias de Whitelist e Blacklist a fim de evitar que seus anúncios apareçam em sites com conteúdo de indesejável associação.

No contexto de mídia programática, whitelist e blacklist consistem, respectivamente, na permissão e proibição da exibição de anúncios dado um endereço, isto é, uma estratégia de whitelisting restringe as impressões a determinados sites enquanto a de blacklisting permite impressões em qualquer endereço, exceto nos bloqueados.

Ainda que o whitelisting seja um caminho mais certeiro na solução do problema, uma vez que há uma boa diversidade de opções de mídia programática em domínios maiores e mais confiáveis como Yahoo, Buzzfeed e outros, há ainda uma parcela significativa de impressões potenciais em sites de pequeno e médio porte a um CPM menor.

Por outro lado, sites menores enfrentam desafios fora da realidade dos maiores, como um menor orçamento para a implementação de uma tecnologia de filtro, menos conhecimento sobre boas práticas de redução de tráfego de bot e nenhuma exigência de autenticação ou login, o que prejudica a relevância do anúncio impresso.

 

Entenda melhor sobre o assunto no artigo original da Marketing Land

clouds

CloudBleed – Vulnerabilidade de dados e informações secretas por bug no CloudFlare

By | News | No Comments

Foi descoberto um severo problema de segurança no CloudFlare, uma rede de fornecimento de conteúdo (CDN, Content Delivery Network em inglês) que ajuda na otimização da segurança e performance de mais de 5,5 milhões de sites na internet, que resultou no vazamento de chaves de sessão particulares e outras informações.

A falha, descoberta por Travis Ormandy, pesquisador de segurança no Google Project Zero, consiste em um erro na identificação do final de um buffer de informações, o que acarreta no retorno de dados além da requisição, similar ao HeartBleed que ocorreu em 2014.

As recomendações são de alteração de senhas pessoais nos mais diversos sites, principalmente se for habitual a reutilização da mesma senha em diferentes plataformas. As informações vazadas podem ser acessadas através de requisições maliciosas, além de os dados terem ficado acessíveis por buscadores como Google, Bing e Yahoo. Informações presentes em aplicativos mobile também ficaram vulneráveis.

Notícia completa na The Hacker News

firebase_logo_shot

Captação de informações sobre uso, frequência e aquisição de usuários do seu App – Firebase: 2 de 4

By | Mobile, Tech | No Comments

Este é o segundo post da série “Firebase” da DP6, focada nas funcionalidades que o Firebase traz para o cenário de desenvolvimento, análise e cativação de usuários de aplicativos móveis. Se quiser uma visão geral do que a ferramenta é capaz, vale dar uma olhada no nosso primeiro post sobre o assunto.

Nesta segunda entrada da série vamos focar no aspecto analítico da ferramenta, mais precisamente como se faz para capturar informações sobre o uso, frequência e aquisição de usuários do seu App, via o flexível SDK do Firebase, unido ao já robusto Tag Manager do Google (GTM).

Este é um post com viés técnico e é recomendado o conhecimento de tecnologias e linguagens focadas no desenvolvimento de aplicativos para iOS (Swift) e Android (Java), além de seus ambientes de desenvolvimento (XCode e Android Studio, respectivamente). Infelizmente não temos bits suficientes para cobrir todo o processo de desenvolvimento de apps, então vamos focar nos detalhes do SDK.

Introdução

Cobrimos no primeiro post os relatórios que o Firebase traz para que seja possível ter uma visão focada no sucesso do seu App.

A coleta de dados é atividade crucial para que se tenha uma noção clara do que está dando certo e o que possui oportunidade de melhoria em seu App. Não deixe para o “achismo”, tenha sempre dados para apoiar suas teorias e suas apostas serão muito mais acuradas!

Como introdução, gostaria usar a oportunidade do post para recomendar que a coleta de dados de todas as funcionalidades do App façam parte não apenas de um processo posterior ao desenvolvimento, mas que esteja intrinsecamente ligado à construção da visão do seu negócio.

Inclua a coleta como parte do desenvolvimento e limitante para o lançamento; é importante defender esta atividade como algo essencial para o funcionamento do App, já que não saber o que e como cada função está sendo utilizada cria discussões vazias e noções muito limitadas às prioridades de desenvolvimento para próximas versões.

Sendo assim, antes de tudo, é vital que seja feito um levantamento cuidadoso do que o seu App traz para o cenário da empresa e seus objetivos de negócio. Quais são os indicadores de sucesso para o App? Quais interações você diria que indicam que seus usuários estão usando o App da forma correta? Com tudo isso anotado, é hora de implementar o SDK do Firebase.

Estrutura geral

O SDK do Firebase habilita que muitas informações sejam coletadas sobre a navegação e interação dos usuários. Algumas informações são coletadas automaticamente apenas à partir da inicialização do SDK, enquanto outras precisam ser coletadas manualmente.

O SDK é capaz de coletar as seguintes informações automaticamente:

Age: Faixa etária do usuário (18-24, 25-34, 35-44, 45-54, 55-64, e 65+)

App Store: Em qual loja de aplicativos foi feito o download (útil para aplicativos Android)

App Version: Versão do aplicativo

Country: País de onde o aplicativo está sendo utilizado

Device Brand: Marca do aparelho

Device Category: Categoria do aparelho (ex: mobile (smartphones) e tablet)

Device Model: Modelo do aparelho (ex: iPhone 5s ou SM-J500M)

First Open Time: O momento (em microsegundos, UTC) em que o usuário abriu o app pela primeira vez, arredondado para a próxima hora fechada.

Gender: Gênero do usuário

Interests: Lista de interesses do usuário

Language: Língua configurada para o sistema operacional

New: Abriu o app pela primeira vez nos últimos 7 dias

Established: Abriu o app pela primeira vez há mais de 7 dias

OS Version: Versão do sistema operacional do aparelho (ex: 9.3.2 ou 5.1.1)

Todas as outras informações que forem necessárias precisam ser coletadas de forma personalizada, pelo uso de funções específicas para cada plataforma.

Os dados personalizados coletados no Firebase são separados em duas categorias:

Eventos: Todas as interações com o seu app, como ações do usuário, eventos de sistema, erros e visualizações de telas. Podem ser coletados até 500 eventos distintos e o Firebase não possui amostragem de dados.

Propriedades: Atributos personalizados de seus usuários para que sua audiência possa ser categorizada em segmentos específicos, como a preferência de língua utilizada ou a localização geográfica.

Firebase + GTM

Para uma implementação flexível, é possível que o Firebase seja implementado junto ao Google Tag Manager. Seguindo este caminho, o GTM é capaz de interceptar, redirecionar e bloquear eventos enviados ao Firebase para que os dados coletados possam ser reutilizados por outras ferramentas, como o Google Analytics, por exemplo.

Aqui vamos focar na implementação pura do Firebase, mas vale revisar as documentações oficiais para entender os benefícios desta outra camada de desenvolvimento.

Preparativos

Antes de tudo, certifique-se que você já possui um projeto Firebase criado. Se não tiver, lembre-se de criar um no Console do Firebase.

iOS

A implementação para iOS em Swift se apoia no uso do CocoaPods, se você ainda não utiliza, é extremamente recomendado fazer a instalação da funcionalidade. O CocoaPods ajuda na instalação de SDKs e bibliotecas com extrema facilidade em seus projetos XCode.

Pré-requisitos

Para a instalação do Firebase, esteja atento ao seguintes requisitos:

  • XCode 7.0 ou superior
  • Um projeto XCode direcionado ao iOS 7.0 ou superior
  • O Identificador da “Bundle” do seu app (ex: com.meuapp.com)
  • Cocoa Pods 1.0.0 ou posterior
  • Para usar o sistema de mensagens:
    • Um aparelho iOS
    • Certificado APN com “Push Notifications” habilitado
    • No XCode, habilitar os “Push Notifications” em App > Capabilities
  • Um computador que rode MacOS (Apenas o MacOS suporta a instalação do XCode)

Instalando o SDK

Para instalar o Firebase, abra o terminal, vá até a pasta inicial de seu projeto. Se não tiver um projeto, crie um novo projeto no XCode. Escolha a opção para abrir um Workspace.

$ cd seu-projeto
$ pod init

*Substitua “seu-projeto” pela pasta que representa seu projeto. O comando “cd” é utilizado para entrar em pastas do diretório selecionado.

Este comando irá criar um arquivo Podfile na pasta. Abra este arquivo e inclua o pod do Firebase e rode o comando de instalação do pod.

No arquivo:

Pod ‘Fireabse/Core’

No Terminal:

$ pod install

Entre em seu Console do Firebase e faça o download do arquivo GoogleService-Info.plist e inclua ele na pasta inicial de seu projeto.

Isto irá adicionar todas as bibliotecas e arquivos necessários para rodar o Firebase em seu projeto. Após este processo, abra o arquivo .xcworkspace de seu projeto para abrir o XCode.

No XCode inclua a seguinte linha de código em sua subclasse UIApplicationDelegate:

import Firebase

Após a importação, inicialize uma instância compartilhada, tipicamente em cada arquivo .swift das telas do seu App, no método application:didFinishiLauchingWithOptions:

FIRApp.configure();

Estamos focados no módulo de Analytics do Firebase, porém, do mesmo modo que instalamos o Firebase/Core no PodFile, outros módulos são instalados da mesma forma. Segue a lista de todos os módulos que podem ser instalados:

post-raj_02

Analytics – Enviando eventos

Com a instância do objeto FIRApp inicializado, é possível capturar eventos utilizando o método logEventWithName(), que segue a seguinte estrutura:

class func logEvent(withName name:String, parameters: [String : NSObject]?)

name: Nome do evento. Deve conter até 40 caracteres alfanuméricos ou “_”. O prefixo “firebase_” não pode ser utilizado no envio de nome de eventos. Cuidado: os nomes dos eventos são sensíveis e eventos com nomes similares, mas com letras individuais maiúsculas trocadas serão contabilizados como eventos distintos.

Parameters: um dicionário de parâmetros. É possível passar nil  como valor para indicar que o evento não possui parâmetros. Nomes de parâmetros podem conter até 40 caracteres alfanuméricos e precisam começar com um caractere alfanumérico. Apenas valores NSString e NSNumber (64-bit integers e floats) são aceitos. Os valores NSString podem conter até 100 caracteres. O prefixo “firebase_” é reservado e não pode ser utilizado para nomes de valores.

Cuidado, os seguintes nomes são reservados e não podem ser utilizados, pois são automaticamente coletados pelo SDK:

  • O prefixo firebase_
  • app_clear_data
  • app_remove
  • app_update
  • error
  • first_open
  • in_app_purchase
  • notification_dismiss
  • notification_foreground
  • notification_open
  • notification_receive
  • os_update
  • session_start
  • User_engagement

Eventos e Parâmetros Pré-Configurados

Para adicionar parâmetros, é recomendado utilizar os parâmetros pré-configurados do Firebase, estes são adicionados aos relatórios específicos de eventos e podem também ser utilizados para marcar valores importantes, como compras feitas em Apps de Ecommerce.

Os parâmetros pré-configurados podem ser encontrados na documentação oficial ou no arquivo FIRParameterNames.h adicionado ao seu projeto.

O mesmo pode ser aplicado aos eventos. Eventos pré-configurados geram relatórios especializados no Firebase Analytics. Por exemplo, o uso do evento kFIREventEcommercePurchase para marcar compras em seu App cria um relatório especializado para mostrar a compra de produtos, com resumo dos produtos, valores e outros parâmetros relevantes diretamente no acompanhamento de compras.

O exemplo abaixo envia um evento para marcar a interação do usuário com um elemento selecionado, marcando o seu ID, nome e tipo de conteúdo; ótimo para marcar o tap em botões:

FIRAnalytics.logEvent(withName: kFIREventSelectContent, parameters:[
kFIRParameterItemID: “id-\(title!)” as NSObject,
kFIRParameterItemName: title! as NSObject,
kFIRParameterContentType: “cont” as NSObject,
])

Eventos e Parâmetros Personalizados

Se os eventos pré-configurados ainda não atenderem às suas necessidades de coleta, é possível coletar eventos totalmente personalizados. Estes eventos são aqueles que utilizam nomes e parâmetros fora do padrão.

Atenção: Os parâmetros de eventos personalizados não aparecem nos relatórios dos eventos, porém, podem ser utilizados para criar segmentos e para criar audiências. Além disso, se integrado ao Google BigQuery, o Firebase também faz a exportação destes parâmetros juntos aos eventos.

O exemplo abaixo envia um evento com nome “share_image”, incluindo os parâmetros “name” e “full_text”.

FIRAnalytics.logEvent(withName:“share_image”, parameters: [
“name”: name as NSObject
“Full_text”: text as NSObject
])

Validando o envio de eventos

Os relatórios do Firebase não são populados em real-time. Sendo assim, para validar se os eventos configurados estão sendo enviados corretamente, é recomendado que o modo “debug” do Firebase Analytics seja habilitado em seu projeto. Para fazer a configuração, siga os passos:

  • No XCode, vá em Product > Scheme > Edit Scheme …
  • Selecione Run no menu
  • Selecione a aba Arguments
  • Na sessão Arguments passed on launch, adicione -FIRAnalyticsDebugEnabled

Os eventos coletados são apresentados na aba “Events” do relatório de Analytics, no console do Firebase.

Propriedades

Para coletar atributos importantes que o ajudaram na identificação dos usuários e sua segmentação, é possível utilizar o método setUserPropertyString(). Até 25 propriedades podem ser criadas, porém, lembre-se que o Firebase já coleta algumas propriedades por padrão, como listado anteriormente.

O exemplo abaixo marca uma comida selecionada como a preferida do usuário:

FIRAnalytics.setUserPropertyString(food, forName: “favorite_food”);

Atenção: as propriedades de idade, gênero e interesse são coletadas apenas se a coleta de publicidade for configurada (IDFA).

Campanhas e dados demográficos

Para coletar dados de campanha e informações demográficas, como idade e gênero, é necessário que o seu App esteja habilitado para coleta de informações de publicidade. Para habilitar a funcionalidade, siga os passos:

  • No XCode, selecione o Target (versão) do seu projeto
  • Vá até a aba General do Target
  • Abra a sessão Linked Framework and Libraries
  • Clique em + para adicionar uma biblioteca
  • Selecione AdSupport.framework

Android

A implementação para Android em Java se apoia no uso do Android Studio, porém, o SDK pode ser instalado em qualquer plataforma utilizada para desenvolvimento Android.

Pré-requisitos

Para a instalação do Firebase, esteja atento ao seguintes requisitos:

  • Um aparelho Android 4.0 (Ice Cream Sandwich) ou superior
  • Google Play Services 10.2.0 ou superior
  • O SDK do Google Play Services, adquirido pelo repositório do Google
  • Android Studio, versão 1.5 ou superior

Instalando o SDK

Caso esteja utilizando a versão 2.2 ou superior do Android Studio, é recomendado o uso do Firebase Assistant para fazer a instalação da ferramenta em seu projeto. Para isso, siga os passo:

  • No Android Studio, selecione Tools > Firebase
  • Selecione a opção Analytics dos módulos listados
  • Selecione Connect to Firebase e siga o tutorial para a instalação em seu App

Se não estiver usando esta versão do Android Studio (2.2+), ainda é possível adicionar o SDK manualmente ao seu projeto, seguindo as instruções oficiais do google.

Assim como no iOS, os módulos de funcionalidade do Firebase são instalados separadamente, eles são:

post-raj_03

Analytics – Enviando eventos

Atenção: Certifique que o seu App está compilando o firebase no arquivo build.grandle:

compile ‘com.google.firebase:firebase-core:10.0.1’

No topo de suas atividades, declare a biblioteca do firebase

Import com.google.fireabse.analytics.FirebaseAnalytics

Declare a classe no construtor de cada atividade…

private FirebaseAnalytics mFirebaseAnalytics;

e inicialize-a no método onCreate()

mFirebaseAnalytics = FirebaseAnalytics.getInstance(this);

Com a instância do objeto inicializado, é possível capturar eventos utilizando o método logEvent(), que segue a seguinte estrutura:

public void logEvent(String name, Bundle params)

name: Nome do evento. Deve conter até 40 caracteres alfanuméricos ou “_”. O prefixo “firebase_” não pode ser utilizado no envio de nome de eventos. Cuidado: os nomes dos eventos são sensíveis e eventos com nomes similares mas com letras individuais maiúsculas trocadas serão contabilizados como eventos distintos.

Parameters: um mapa de parâmetros. É possível passar null como valor para indicar que o evento não possui parâmetros. Nomes de parâmetros podem conter até 40 caracteres alfanuméricos, precisam começar com um caractere alfanumérico. Apenas valores NSString e NSNumber (64-bit integers e floats) são aceitos. Os valores NSString podem conter até 100 caracteres. O prefixo “firebase_” é reservado e não pode ser utilizado para nomes de valores.

Cuidado, os seguintes nomes são reservados e não podem ser utilizados, pois são automaticamente coletados pelo SDK:

  • O prefixo firebase_
  • app_clear_data
  • app_remove
  • app_update
  • error
  • first_open
  • in_app_purchase
  • notification_dismiss
  • notification_foreground
  • notification_open
  • notification_receive
  • os_update
  • session_start
  • User_engagement

Eventos e Parâmetros Pré-Configurados

Para adicionar parâmetros, é recomendado utilizar os parâmetros pré-configurados do Firebase, estes são adicionados aos relatórios específicos de eventos e podem também ser utilizados para marcar valores importantes, como compras feitas em Apps de Ecommerce. Os eventos pré-configurados podem ser encontrados na documentação oficial.

Os parâmetros pré-configurados podem ser encontrados na documentação oficial ou no arquivo FIRParameterNames.h adicionado ao seu projeto.

O mesmo pode ser aplicado aos eventos. Eventos pré-configurados geram relatórios especializados no Firebase Analytics. Por exemplo, o uso do evento kFIREventEcommercePurchase para marcar compras em seu App cria um relatório especializado para mostrar a compra de produtos, com resumo dos produtos, valores e outros parâmetros relevantes diretamente no acompanhamento de compras.

O exemplo abaixo envia um evento para marcar a interação do usuário com um elemento selecionado, marcando o seu ID, nome e tipo de conteúdo, ótimo para marcar o tap em botões:

Bundle bundle = new Bundle();
bundle.putString(FirebaseAnalytics.Param.ITEM_ID, id);
bundle.putString(FirebaseAnalytics.Param.ITEM_NAME, title);
bundle.putString(FirebaseAnalytics.Param.CONTENT_TYPE, “cont”);
mFirebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_CONTENT, bundle);

Eventos e Parâmetros Personalizados

Se os eventos pré-configurados ainda não atenderem às suas necessidades de coleta, é possível coletar eventos totalmente personalizados. Estes eventos são aqueles que utilizam nomes e parâmetros fora do padrão.

Atenção: Os parâmetros de eventos personalizados não aparecem nos relatórios dos eventos, porém, podem ser utilizados para criar segmentos e para criar audiências. Além disso, se integrado ao Google BigQuery, o Firebase também faz a exportação destes parâmetros juntos aos eventos.

O exemplo abaixo envia um evento com nome “share_image”, incluindo os parâmetros “name” e “full_text”.

Bundle bundle = new Bundle();
bundle.putString(“name”, name);
bundle.putString(400;">“full_text”, text);
mFirebaseAnalytics.logEvent(“share_image”, bundle);

Validando o envio de eventos

Os relatórios do Firebase não são populados em real-time. Sendo assim, para validar se os eventos configurados estão sendo enviados corretamente, é recomendado que o modo “debug” do Firebase Analytics seja habilitado em seu projeto, para que sejam mostrados no LogCat do Android Studio. Para fazer a configuração, insira os seguintes comandos adb em sua linha de comando:

  • adb shell setprop log.tag.FA VERBOSE
  • adb shell setprop log.tag.FA-SVC VERBOSE
  • adb logcat -v time -s FA FA-SVC

Os eventos coletados são apresentados na aba “Events” do relatório de Analytics, no console do Firebase.

Propriedades

Para coletar atributos importantes que o ajudaram na identificação dos usuários e sua segmentação, é possível utilizar o método setUserProperty(). Até 25 propriedades podem ser criadas, porém, lembre-se que o Firebase já coleta algumas propriedades por padrão, como listado anteriormente.

Primeiramente, configure as propriedades no console do firebase:

  • No Firebase Analytics vá até a aba User Properties
  • Clique em NEW USER PROPERTY
  • Insira um nome e descrição para a propriedade e selecione Create

O exemplo abaixo marca uma comida selecionada como a preferida do usuário. O método pode ser utilizado em qualquer atividade em que a instância do Firebase foi inicializada:

mFirebaseAnalytics.setUserProperty(“favorite_food”, mFavoriteFood);

Conclusão

Vimos neste artigo o método de implementação básica do Firebase Analytics para iOS e Android. Existem detalhes que podem ser descobertos nas documentações oficiais para as plataformas e gostaria de encorajar todos a estudar os manuais:

Na próxima edição, vamos explorar as ferramentas focadas no desenvolvimento de aplicativos que o pacote do Firebase oferece, incluindo o Firebase Auth, o Firebase DataBase, Dynamic Links, Storage e Remote Config.