porLuis Augusto Moretto

3 passos para melhorar a conversão de clientes em seu site!

 Seu SITE está atrasando seu NEGÓCIO? Veja como corrigir isso.

Está precisando de mais leads? Planeja expandir sua visibilidade, desenvolver um novo website ou implantar uma estratégia de marketing digital? Seu site está parado e você deseja turbinar os acessos orgânicos sem propagandas?

conversion-psychology

  • Passo 1: Informe seus dados no formulário desta página para fazer a bola rolar. Nós entraremos em contato o mais rápido possível para agendar um tempo para falar com um dos nossos parceiros (provavelmente esta semana ou no próximo).
  • Passo 2: Magicamente minúsculos duendes (* não realmente) vão cavar a fundo em seu site para ver o que está funcionando, o que não, e quais as estratégias para aumentar seu valor percebido pelo cliente.
  • Passo 3: Durante a videoconferência, vamos compartilhar nosso desktop e apresentar critérios de (1) design, (2) pesquisas e (3) recomendações de conversão que têm o poder de alavancar o desempenho do seu site imediatamente.

 

Suas informações

Informe-nos seus dados e datas e horários nos proximos 10 dias para agendarmos uma videconferência GRATUITAMENTE, para lhe dar um feedback de seu site. Iremos lhe apresentar como aumentar o valor percebido pelo seu nicho de negócios!





Exemplo de recomendação com o conceito de “Design de Conversão”

  • #1: Chamada de ação: É recomendável usar várias chamadas à ação em todas as páginas da web para completar seu objetivo (neste caso, uma reserva). Por exemplo, você também pode chamadas royal_cliff_new_homepagena barra lateral e no corpo do texto na página inicial.
  • #2: Posição do campo Linguagem:  Utilizar dupla navegação está ok. Mas deve-se evitar redundâncias para não ter densidade informacional. A sugestão seria posicionar o menu de linguagens na barra superior (agrupamento por formato); Além disso aumentar a altura do botão de reservas para ficar destacado;
  • #3: Mudança de cor e destaque no Slider:  Você pode facilmente aumentar o tamanho ou a cor do botão “Fazer uma reserva” no controle deslizante principal para torná-lo mais fácil de ver (atualmente combina com algumas das imagens de fundo). Você também pode usar cores diferentes no menu de navegação superior para “Reservas” para chamar mais atenção a ele.
  • #4: Aprimorar descrição das chamadas: O site poderia usar chamada original e proporcionar uma motivação mais forte para fazer uma reserva. Aqui, o texto usado no controle deslizante de imagem na página inicial diz o que é :”vista de 180 graus”. Uma chamada como “Luxuoso Hotel a Beira do Paraíso”, instiga os sentidos.

 

porLuis Augusto Moretto

O que é Time-Box?

Introdução

SCrum time boxVocê já deve ter ouvido sobre. Mas o que é Time-box na metodologia de gerenciamento ágil de projetos Scrum?

A técnica de Timebox no Scrum, consiste em definir o tempo máximo para atingir as metas, tomar uma decisão ou executar um conjunto de tarefas. A ideia é maximizar o tempo fazendo o melhor que a equipe pode neste intervalo. Assim, em vez de começar a trabalhar em algo até sua finalização de forma indefinida, é acordado de antemão o tempo limite para cada tarefa de projeto.

O Time-boxe é usado para criar regularidade.  Na prática consiste em uma quantidade de tempo, ou seja uma duração fixa que não poderá aumentar. Como exemplo de um time-box, o Sprints de um projeto deverá ter duração fixa com no mínimo 2 semanas e no máximo 4 semanas. O tempo das Sprints de um projeto são fixas e não devem variar ao longo do projeto.

“Se vc escolheu usar o time-box de 3 semanas para os seus Sprints, use sempre 3 semanas!”

Os Sprints são iniciados imediatamente após o outro, sem intervalos ou gaps entre eles. Durante o Sprint o Scrum Master deve evitar mudanças que possam afetar o objetivo traçado para aquele Sprint . Além disso o Scrum master deve proteger o time de desenvolvimento resolvendo todos e qualquer impedimento de projeto.

Exemplos de Time Box

  • Daily meeting: reunião diária deve durar exatamente 15 minutos;
  • Sprint: duração mínima de 2 semanas máximo de 4 semanas;
  • Planning poker: Atividade de planejamento do Sprint. Deve durar entre 6 e 12 horas de forma a ser realizada em no máximo 2 dias;
  • Sprint Review: reunião para apresentar o produto do Sprint. Duração: 4 horas;
  • Retrospectiva: reunião de lições aprendidas pelo time. Duração: 4 horas;

Vantagens

  1. Reuniões mais focadas e objetivas, conforme tema planejado.
  2. A prática do conceito de  Timebox ajuda os gestores e a equipe a saber quanto tempo é necessário para realizar uma tarefa.
  3. Eliminação do desperdício de tempo
  4. Evita-se procrastinar as tarefas mais difíceis de serem feitas, pois estão na lista do backlog a devem ser cumpridas dentro da Sprint;
  5. Dedicação exclusiva para a tarefas dentro do time-box
  6. Ajuda a compreender a complexidade e o tempo para realização das tarefas

 

porLuis Augusto Moretto

5 dicas para implementar o Scrum no seu time!

untitled-1

Muitas organizações estão se conscientizando dos inúmeros benefícios de Metodologias Ágeis. Se você chegou até aqui é porque deve estar se perguntando eu quero implementar o Scrum e quero ser ágil em meus projetos. Mas, por onde começar?

Quais são os passo que você precisa tomar, a fim de seguir o caminho Agile?

Neste artigo vou te apresentar 5 dicas de valor na hora de implementar o Scrum como método ágil para o gerenciamento de projetos. Estas dicas se mostraram de extremo valor em diversos projetos sempre com o foco na geração de valor para o cliente.

1) Crie um Ambiente de Trabalho Colaborativo

Crie um ambiente de trabalho colaborativo! Para isso o ambiente deve propiciar a comunicação, a colaboração e a transparência.  Assim devem ter quadros nas paredes, canetas, e postit para anotar e comunicar as tarefas do Sprint de forma transparente. A essência do Agile é ter um modelo de comunicação e colaboração com o time e com os stakeholders do projeto;

2) Organize e Priorize o Backlog do Projeto

O Product Owner precisa saber o o valor gerado ao cliente de cada requisito ou User Story que está na lista de backlog e ele não está preocupado com o que será necessário para o desenvolvimento. Os prazos são uma tarefa exclusiva da equipe e só ela pode definir; É aconselhável utilizar o resultado da última Sprint como parâmetro para o planejamento da próxima.

3)Utilize o refinamento para entendimento das histórias

Refinamento das User Stories reduz as dúvidas técnicas e dúvidas de negócio. Essa atividade favorece ao Time de Desenvolvimento planejar a próxima Sprint de forma produtiva. Recomenda-se mapear possíveis impedimentos e trabalhar para evitar que eles ocorram.

4) Trabalhe Sempre com o Conceito de Timebox

No Scrum cada evento tem um tempo máximo pré-determinado para sua realização. Este conceito é chamado de Timebox. Isto assegura que o tempo do projeto seja maximizado. Ou seja :Reuniões focadas e objetivas; Equipe focada nos artefatos a serem entregues; Evita-se procrastinar as tarefas de serem feitas, pois além há um tempo limite para sua realização; Valorização do tempo de trabalho da equipe; e Dedicação exclusiva para a atividade dentro do time-box.

5) Monitore o Progresso com o Burndown chart

O progresso realizado pela equipe de desenvolvimento deverá sempre ser atualizado e monitorado através do burndow chart. Com isso é possível avaliar diariamente no daily meeting atualizando o gráfico e monitorando o progresso.

Conclusão

Além disso tenha claro que o conceito Ágil promove a inovação dentro da equipe. Assim o time é auto-organizado o que significa alto grau de engajamento e  busca continua de métodos, técnicas e ferramentas para promover a produtividade, a qualidade, maximizar os resultados, o valor e a geração de ROI.

Concluindo, o Scrum é um método de gerenciamento ágil que deve ser implementado em conjunto com o XP – Extreme Programming. Diria analogamente, que os dois em conjunto seriam como um tratamento médico onde são ministrados dois medicamentos para uma cura. O primeiro trata da agilidade na gestão e o segundo da agilidade no desenvolvimento!

porLuis Augusto Moretto

Medindo o progresso de projetos Scrum com Burndown chart

monitoriacontroleOs métodos e as práticas ágeis são extremamente efetivos e eficazes. Produzem resultados de qualidade em curto espaço de tempo comparado ao modelo em cascata e outras abordagens tradicionais de desenvolvimento de software.

Estes resultados são sempre orientados a geração de valor para o cliente ao final de cada Sprint do projeto. Ou seja a expectativa é software funcionando e agregando valor na organização cliente.

Para alcançar estes resultados, é primordial medir e controlar o progresso do Sprint. Alem da questão do gerenciamento, existe uma complexidade inerente que é a introdução de novos requisitos frequentemente a cada Sprint (na engenharia civil ninguém pede para mover o prédio 1cm para o lado após a construção da fundação…Entretanto falando de software a evolução é contínua).

Sendo assim surge um problema para atender ao custo prazo e qualidade associados ao Sprint:

 

“Como monitorar  e controlar o progresso dos Sprints de projetos ágeis com a metodologia Scrum de forma transparente?”




Na engenharia de software clássica, cada projeto é composto de milestones ou marcos. Estes marcos servem para mensurar o progresso do projeto, fazendo um comparativo do que foi planejado x o realizado em termos de desenvolvimento.

Uma métrica para estimar o esforço são os Use case points.  Lembrando que o esforço é uma métrica dada pela capacidade homem/hora (um pouco Taylorista….) O problema é que para usar está métrica, é necessário ter todos os casos de uso do sistema documentados e detalhados para se analisar a complexidade!

No Scrum, todas as user stories são descritas em uma única sentença simples. Neste contexto como monitorar e controlar os Sprints?

Bom aqui vamos reforçar a importância dos Daily meetings para que você entenda a dinâmica.

É no encontro diário onde a equipe aponta as tarefas que foram realizadas no dia anterior. Sendo assim cada membro da equipe da seu depoimento compartilhando com o time seu progresso. Neste mesmo momento é que o membro seleciona a tarefa em que tem maior aptidão para realizar durante o dia. Com estas informações o Scrum Master atualiza o Burndown chart diariamente.

Abrindo um paralelo, nenhum projeto atrasa 1 mes de uma vez. O atraso é decorrente da somatória de vários dias de atraso. No Scrum se durante a reunião diária for apontado algum impedimento isto será avaliado, assim como o seu risco, de forma que o Sprint seja realizado dentro do prazo. Se for um problema impactante a equipe se reúne e discute as medidas a serem tomadas em conjuntos para dirimir o problema.

Como criar um Burndown Chart

scrum_burndown_ideal

Sprint planejado com 420 horas no burndownchart

O primeiro passo é fazer o planejamento e divisão das tarefas do Sprint. Isso é realizado na reunião de planejamento do Sprint e utiliza uma técnica chamada de planning poker. Cada tarefa deve ter horas associadas.

O tempo de uma tarefa é sempre analisado usando uma sequência Fibonnaci (0,1, 1, 2, 3, 5, 8, 13, 21, 34….). Ou seja uma tarefa deve ter no mínimo 3 horas e no máximo 6, de forma que possa ser realizada em um dia.

Se a tarefa tem mais de 6 horas deve ser analisada e sub-dividida. Caso a tarefa tenha menos de 2 horas esta deve ser vinculada a outra tarefa associada. Este processo é realizado pelo time junto com o Scrum master de forma a compartilhar e gerar colaboração em torno do Sprint.

Uma vez que a divisão de tarefas foi realizada, o gráfico burn-down ideal é traçado. O ideal reflete o progresso assumindo que todas as tarefas serão concluídas dentro o sprint a uma taxa uniforme.

Para saber quantos pontos e a capacidade produtiva de um time para um determinado Sprint, leva-se em consideração as seguintes variáreis:

  • Sprint Duração – 2 semanas (10 dias úteis)
  • Equipe – 7 membros
  • Horas / dia – 6
  • Capacidade Total – 420 horas

Ou seja para um equipe de 7 membros, trabalhando 6 horas por dia no projeto cada, durante 10 dias podemos executar um total de 420 horas de desenvolvimento. Portanto na reunião de planejamento do Sprint esse parâmetro deve ser levado em consideração.

Atualizando o Burndownchart no Daily Meeting

O progresso realizado pela equipe de desenvolvimento deverá sempre estar próximo do progresso planejado. Esta linha se inicia no mesmo ponto de origem do progresso ideal, mas o seu progresso é dado a partir da queima dos story points. A reta será traçada a partir do produto do esforço realizado x tempo gasto. Assim diariamente após a equipe mover as tarefas da coluna de “doing” para “done”, o Scrum Master calcula o total de pontos realizados e atualiza o Burndown chart conforme abaixo.

image

Burndown chart: Realizado x Planejado

Faça o download da planilha no Google Drive

Gostou? curta nossa página e cadastre seu email para receber novidades!

porLuis Augusto Moretto

Insights e controle de erros com o Firebase Crash Reporting

bugs firebase crash

Uma das grandes problemáticas no desenvolvimento de aplicativos Android é a gama de fornecedores e versões disponíveis no mercado. Esse cenário faz com que um APP que foi testado e desenvolvido em um MotoG Xt-1078 por exemplo, apresente problemas em um outro dispositivo como Sansumg, Nexxus, Asus….. Um pesadelo para o processo de desenvolvimento!

Ou seja é necessário testar o APP no maior número possível de dispositivos e versões do Android. Como coletar os dados dos incidentes de erros em dispositivos não testados?

Para tratar essa questão, foi implementado no Citywatch.com.br o Firebase Crash Reporting. Com a ferramenta é fácil ter insights sempre que seu aplicativo apresentar uma falha.

O Crash Reporting cria relatórios de bugs detalhados no aplicativo. 

Os bugs são agrupados em conjuntos similares . São organizados de acordo com a gravidade (fatal ou não fatal).

Além dos relatórios automáticos, você pode registrar eventos personalizados. Isso ajuda a capturar os defeitos.

Insights no Citywatch

dashboard Firebase Crash ReportNa imagem do Crash Report do Citywatch.com.br, é possível visualizar que ocorreram 507 erros e 45 usuários afetados.

Os erros são agrupados em 74 tipos diferentes. Pode-se filtrar ainda quais os erros são fatais, ou seja fazem o APP no Android parar de rodar.

Além disso o dashboard fornece métricas para priorizar de forma ágil a correção dos erros. Basta analisar qual o erro fatal impactou mais usuários e em que parte da navegação e das funcionalidades do app ocorreu o incidente.

Sem o Firebase Crash Analytics, o desenvolvedor Android depende do usuário relatar o erro para saber do incidente. Assim os bugs são coletados automaticamente a cada incidente.

Com isso a equipe de desenvolvimento pode analisar o erro, reproduzir e corrigir. Fica muito mais ágil e da uma maior confiabilidade, reproduzir o erro em um emulador com a mesma característica registrada no incidente.

Implementação no Android Studio

Para capturar os erros dentro do APP é necessário adicionar as dependências da API do Firebase.

Na figura abaixo um exemplo de um método com a chamada ao Firebase Crash dentro do Android Studio.Firebase crash

Deixe seu like, cadastre seu email para receber novidades norodapé! Namastê!

porLuis Augusto Moretto

Agilidade no desenvolvimento de Software com o Google Appengine na Arquitetura do Citywatch.com.br

Visão geral do Google Appengine

O Google Appengine é uma plataforma para criação de aplicações nas nuvens adotada na Arquitetura de Software do Citywatch APP. Tal decisão foi embasada na produtividade, qualidade e agilidade que a plataforma propicia ao desenvolvimento de um projeto inovador como o Citywatch.

Permite a hospedagem de sistemas codificados nas linguagens Java, Phyton e PHP.  Tem alta escalabilidade sem a necessidade de gerenciar infraestruturas de alto tráfego. A plataforma oferece rapidez, confiabilidade, escalabilidade, controle de versão e a robustez da infraestrutura do Google no seu projeto!

Ambiente de Desenvolvimento, Homologação e Produção

A ITIL – Information Tecnology Infrastructure Library recomenda como boa prática em projetos de Tecnologia da Informação e Comunicação que a organização disponha de um ambiente de desenvolvimento, homologação e produção.  Os três ambientes devem ter a mesma configuração para que o processo de desenvolvimento, testes e implantação sejam realizados de forma consistente.

appengine escalonamento

Um cenário comum é a necessidade de se ter máquinas distintas (ou virtualizações) para cada um dos ambientes. Em cada estágio, a equipe de projeto implanta a versão correspondente no ambiente destino.

Isso é extremamente complexo, porque requer o conhecimento específico de cada ambiente e sua infraestrutura. Além disso requer um checklist de todas as alterações realizadas no código fonte do projeto para realizar a implantação.

Eu mesmo já cometi erros porque na hora de colocar em produção esqueci um campo do banco de dados… ou faltou um arquivo… sobrescreveu o arquivo errado…. parecia um dia sem fim.. sentimento de angustia começando a bater, gerente com a pergunta clássica: tá pronto?? 😛 Affz :X !#%%EDITORCONTENT%%amp;

Com a plataforma do Google Appengine é extremamente simples para criar estes três ambientes. Basta alterar as configurações do descritor xml dentro do projeto chamado de appengine-web.xml. A propriedade application é o nome do microserviço que vai rodar na plataforma.

Quando não é possível utilizar a mesma base de dados para realizar os testes e o ambiente de produção, deve-se criar um microserviço para cada ambiente. Caso contrário cada ambiente pode ser administrado como múltiplas versões rodando em paralelo na plataforma.

Escalonando e Clusterizando o Serviço

O escalonamento do microserviço dentro da plataforma do Google Appengine é feita no mesmo arquivo descritor da aplicação e da instância. Existem três opções possíveis para o escalonamento:

  1. Escalonamento automático;
  2. Escalonamento básico e;
  3. Escalonamento manual;

Para cada projeto deve ser avaliado os recursos necessários e configurar a infraestrutura de acordo com os requisitos e atributos da qualidade esperados.Na figura acima especifica-se que a instância do microserviço roda em uma infraestrutura b8, com o número máximo de instâncias concorrentes igual a 100 e o tempo de idle é de 10 minutos.

Para ver como funciona a clusterização e balanceamento de carga veja o exemplo do microserviço do Citywatch, assistindo ao video abaixo:

Faturamento

Para utilizar todos os recursos do Google AppEngine é necessário informar o cartão de crédito vinculado a sua conta.  Em estágio de encubação, as Startups não dispões de muitos recursos financeiros para investir em uma infraestrutura robusta, então o Appengine é uma excelente escolha. Você só paga quando começar a ter escala no seu projeto. E pode escalar sob demanda conforme seu público cresce!

Uma funcionalidade bem interessante do sistema de faturamento da infra é a possibilidade de estabelecer um orçamento máximo diário do serviço na nuvem.  Como exemplo abaixo configurei o projeto para um faturamento máximo diário de $0,25 dólares.

faturamento appengine

Gostou? deixe seu like, cadastre seu email e receba novidades. Até a próxima! Namastê!

porLuis Augusto Moretto

Scrum como metodologia de gerenciamento de projetos para gerar valor na sua empresa com agilidade!


scrum

O Scrum é uma metodologia de gerenciamento de projetos de software baseado na premissa ágil. Sua adoção soluciona a questão de longos ciclos de desenvolvimento e incompatibilidades entre os requisitos de um produto e a sua implementação.

Assim a Morettic, buscando entregar software funcionando e que, em curto espaço de tempo gere valor para o cliente, adotou a metodologia Scrum. Neste sentido dentro de nossos processos e em todos os estágios dos projetos valorizamos e promovemos a comunicação e o compartilhamento de informações e do conhecimento.

O objetivo é ter o feedback contínuo do cliente, validando assim nossos deliverables. A cada entrega estamos ajustando as necessidades e melhorando continuamente a qualidade dos produtos e serviços ondemand.

Assista ao vídeo com depoimentos de Luis Augusto Machado Moretto Founder da Morettic e Luiz Fernando Gamba  Diretor da Genimo e compreenda como o Scrum potencializa a geração de resultados e valor.


Para atingir estes resultados, adotamos algumas práticas como:

  1. Stories: Identifica quem é o usuário e o que ele deseja em uma única sentença;
  2. Sprint: Curto ciclos de desenvolvimento com “time box” de 2 a 4 semanas;
  3. Daily Meetings: Reuniões diárias para rever regularmente as melhorias incrementais feitas pela equipe de cada Sprint. Isso aumenta o nível de comunicação entre a equipe desenvolvimento, o cliente e reforça uma visão compartilhada para cada incremento feito;
  4. Dashboard: Painel ou quadro onde todos os stakeholders visualizem e compartilham diariamente as atividades do Sprint;

Junto com estas práticas temos um conjunto de valores que direcionam as pessoas e os processos:

“Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano”

Como visto o Scrum como metodologia é fácil de aprender mas sua maestria é complexa. Uma característica da metodologia é o sentimento de evolução do projeto que percebido por todos os stakeholders;

Ocorre que no primeiro Sprint de qualquer novo projeto falando de maneira metafórica, é como ter um novo carro. Ele é ótimo tem muitas características novas mas o motorista ainda está aprendendo o que todos os botões fazem. Neste estágio do projeto devem ser definidos elementos arquiteturais, comportamentais do produto ou serviço. Ainda assim o product owner está levantando todos os requisitos para o novo Sprint e ainda comunicando a equipe das demandas do Sprint atual.

Um indicador de acompanhamento do projeto é o Burndown chart. Usar o Burndown chart ao longo da Sprint, permite mensurar os pontos das histórias finalizadas ao longo dos dias e ter uma visibilidade do ritmo de trabalho da equipe, verificando se o ritmo está adequado para atingir a meta da Sprint, cumprindo com o que foi planejado.

Exemplo de um burndown chart. A linha vermelha é o planejado. A linha Azul é o como foi realizado o sprint.

Exemplo de um burndown chart. A linha vermelha é o planejado. A linha Azul é o como foi realizado o sprint.

Para dar suporte a metodologia e criar uma base de conhecimento, gerando assertividade por parte da Morettic, foi criado um ambiente de projetos ágeis. Este ambiente é baseado na ferramenta Mantis BT que possúi plugins para o Scrum. Além disso a ferramenta permite integrar o repositório de códigos como o GitHub, Svn etc. Assim todas as informações históricas são armazenadas permitindo ao final de cada Sprint gerar lições aprendidas e assim reconhecer as falhas e os acertos.

Gostou? Cadastre seu email no rodapé, curta nossa página no facebook, receba nossos boletins e aguarde novidades!

porLuis Augusto Moretto

CityWatch – Agora disponível para download em GetJar.com

getjarGetJar é maior loja de aplicativos mobile independente fundada na Lituânia em 2004, com escritórios em Vilnius, na Lituânia e San Francisco, Califórnia.

GetJar começou por desenvolvedores para desenvolvedores como uma plataforma de testes app beta e, em seguida, tornou-se a distribuição app tornando-se primeiro e maior loja aberta mercado de aplicativos e aplicativo gratuito no início de 2005. Por isso, pode-se dizer que GetJar é pioneira na distribuição de aplicativo móvel.

Assim para obter maior visibilidade em outros territórios, favorecer a busca do APP através dos mecanismos de indexação, expandir a rede de usuários e aprimorar continuamente o Citywatch.com.br, publicou-se uma versão na loja do GetJar .

O procedimento para publicação do Citywatch na loja foi relativamente simples. Após customizar o tamanho das imagens para o GetJar e  formatar os textos, seleciona-se as versões do APP as quais são compatíveis e para finalizar, ativa-se o APP. Todo o processo leva em torno de 1 hora. A loja possui ainda uma ferramenta de análise para avaliar as estatísticas de downloads e regiões.

Atualmente o Citywatch encontra-se em fase Beta e em estágio de implementação de uma parceria no estado de Santa Catarina. Essa parceria irá fomentar e desenvolver o APP reforçando a atuação. O segmento desta parceria é o imobiliário e a perspectiva é de lançar no dia 19/10/2016 o piloto do sistema. Em breve notícias da parceria!

http://www.getjar.com/categories/social-and-messaging-apps/more-social-apps/Citywatch-APP-900709

Citywatch.com.br – GetJar App Store

Gostou?

http://www.getjar.com/categories/social-and-messaging-apps/more-social-apps/Citywatch-APP-900709

http://citywatch.com.br

porLuis Augusto Moretto

Tappx – Rede de promoção para desenvolvedores de APP no Citywatch.com.br

untitled-1

Na última versão BETA do Citywatch.com.br, foi implementada a rede de promoção TAPPX. Esta ação foi resultado das seguintes necessidades identificadas no desenvolvimento da versão BETA do Citywatch APP:

  1. Expandir a rede de usuários do APP;
  2. Verificar a robustez do APP em diversos dispositivos e versões do Android;
  3. Coletar dados de erros com o Firebase crash Analytics;
  4. Avaliar a aceitação do APP em outros países;
  5. Validar a internacionalização do APP;

Para isso após análise das alternativas com base no custo benefício, chegou-se ao TAPPX, uma comunidade de desenvolvedores que fazem intercambio de propagandas entre os APPS publicadas na rede.

O processo de instalação das bibliotecas é simples com Android Studio e a chamada da promoção foi implementada em apenas 5 linhas de código. Toda a implementação no Android Studio, levou cerca de 30 minutos.  Abaixo alguns exemplos:

Biblioteca do TAPPX incorporada no Android Studio
Gradle do projeto para compilar a biblioteca TAPPX
Gradle do projeto para compilar a biblioteca TAPPX

Resultados

Os resultados obtidos foram satisfatórios. Quando a número de conversões obtidas no período de 7 dias chegou aos  1,81%. Este número representa  os usuários que clicaram no anúncio para fazer o download com base na promoção do APP.


Uma informação bem relevante foi que o país onde mais se obteve visualizações e cliques foi na Itália somando 213 visualizações. Apesar de ter o maior número de visualizações o APP não dispõe do idioma italiano em sua base de traduções.  O segundo mais visualizado foi na França com o total de 120. Durante o período de uma semana obteve-se visibilidade para o APP em países do continente Europeu, África, Oceania, America do Norte, Central e do Sul. Isto nos da evidência do potencial de expansão que a rede representa para Startups e ainda da Insights de estrátégias e ações a serem implantadas para desenvolver a rede do APP.

Considerações

A rede permite que você obtenha pontos extras para acelerar a promoção de seu app. Uma das formas utilizadas por nossa equipe foi a divulgação no twitter que resultou em 15.000 pontos para a promoção do Citywatch.com.br. A publicação no twitter consiste em divulgar o seu APP adicionando HASHTAGS como no tweet que incorporamos.

Gostou?
google-play-badge

porLuis Augusto Moretto

Lauching Next – Citywatch Release

1024_500_play

Submissão do APP – Lauching Next

Foi submetido nesta semana o release do Citywatch.com.br para o LAUCHING NEXT. Para quem não conhece  LAUCHING NEXT apresenta todos os dias mais promissoras  e novas startups do mundo.

Para que o processo de publicação de nosso APP o Citywatch seja acelerado e ganhe visibilidade, criamos uma campanha no Twitter.  Nosso objetivo é divulgar o APP, ampliando a rede de usuários e serviços ofertados.

Estamos no beta e em breve estaremos fazendo um pré lançamento! Contamos com sua participação. Compartilhe e curta! Muito Obrigado!
Em breve publicaremos o endereço de nosso release no site da LAUCHING NEXT para você!