Concrete Logo
Hamburger button

Aprendizados SVPG – Parte 2: CompraFácil

  • Blog
  • 7 de Fevereiro de 2014
Share

Continuando nossas “lean stories”, baseadas em conceitos aprendidos no workshop “How to Create Products Customer Love”, do Silicon Valley Product Group, e em experiências práticas da Concrete Solutions (veja o primeiro post da série aqui), vamos conversar um pouco sobre o valor de usar dados para decidir quais funcionalidades devem ser construídas em seu produto e a importância de falar com o seu cliente para obter feedback.

Contexto

A Cloudretail fez uma parceria com a empresa CompraFácil para desenvolver seus canais móveis (iPhone, iPad e Android app para smartphones e tablets). A parceria foi desenvolvida no modelo de revenue-share, ou seja, nós só ganhávamos se uma venda fosse fechada no CompraFácil a partir dos nossos aplicativos. É um modelo arriscado, mas que tem um ótimo potencial, até porque nos dava a oportunidade de operar os canais móveis com mais autonomia e nosso lucro seria proporcional ao trabalho que executássemos.

Posto isso, decidimos utilizar desde o início a suíte de mobile commerce do Cloudretail, porque assim conseguiríamos um time-to-market e atingiríamos uma visão multicanal mais rápido. A suíte faz o ciclo completo de e-commerce, desde listagem de categorias até detalhes de produto e carrinho, chegando até o fechamento do pedido. Nosso plano estava traçado: era só lançar os aplicativos e começar a fazer dinheiro em cima da base de usuários do CompraFácil.

comprafacilapps

Certo? Errado. Lançamos os aplicativos e conseguimos uma base de usuários relativamente boa, com a qual conseguiríamos trabalhar os clientes e começar a rodar os experimentos. Demorou um pouco para termos números expressivos, mas aos poucos vimos que a coisa estava começando a tomar tração, ainda que não fosse resolver o caixa de uma empresa ou vida dos seus empresários.

Métricas

Olhando o Analytics, logo logo percebemos algumas métricas que não estavam indo tão bem:

1. A quantidade de downloads vs. usuários ativos por mês: as pessoas baixavam a app, mas a quantidade de downloads não refletia os usuários ativos, ou seja, o cliente baixava a app mas não tinha recorrência de uso e demorava alguns dias para reabrir a app, se fizesse isso.

Isso é um pesadelo do ponto de vista de aquisição de usuário: estávamos investindo em campanhas de aquisição, mas as pessoas ou instalavam as apps, usavam algumas vezes e desinstalavam; ou deixavam a app instalada, mas não se lembravam de reabri-la após algum tempo.

métricas

2. Tempo médio de uso e telas por sessão:

Na média, as pessoas que usavam as apps corriqueiramente a usavam por pouco tempo e, pior, a quantidade de telas por sessão de uso também era baixa. Ou seja, não só elas estavam usando a app por pouco tempo como também estavam navegando pouco pelo aplicativo.

Diante desse cenário, escolhemos uma métrica para melhorar: a recorrência de uso dos aplicativos. O objetivo era fazer com que o cliente que tinha a app instalada a abrisse mais vezes em um período de tempo. Definimos o problema como: “usuários que instalaram o aplicativo não estão reabrindo o aplicativo em período curto de tempo” ou “instalação dos aplicativos não geram usuários ativos”.

Para este problema, definimos diversas hipóteses de solução, entre elas “enviar mail marketing para os usuários que se cadastraram na app com promoções do dia” e “escolher bons produtos oferecidos por bons preços e pôr em destaque no aplicativo, instigando o cliente a reabrir a app para ficar a par das promoções”.

A primeira era uma ótima ideia, mas impactamos uma base de usuários muito pequena e tínhamos um problema de deep linking. Também começamos a fazer um trabalho forte para garantir que todo dia tivéssemos produtos competitivos nos destaques, mas ainda assim não conseguimos criar o hábito em nossos usuários de sistematicamente abrir o nosso aplicativo para conferir as novidades.

moving-forwards-1431095-2-m

Push notification

Foi aí que surgiu a hipótese do push notification. Precisávamos de uma forma sistemática de atingir todos os clientes com instalações ativas e convidá-los a reabrir a app, e é exatamente isso que o push notification faz: alcança ativamente os usuários para trazer informações relacionadas ao seu aplicativo.

Um pequeno parênteses: o push notification não é nenhuma novidade, inclusive estava em nosso product backlog há algum tempo. Simplesmente não parecia ser a coisa mais prioritária a ser feita, era um belo “nice to have“. A hipótese de solução acabou formulada da seguinte forma: “enviar push notifcations com produtos em destaque para a nossa base de usuários para fazê-los reabrirem o aplicativo”.

Push

Ou seja, juntamos a parte das promoções e bons preços das outras hipóteses (é isso que move um usuário do CompraFácil) com uma forma ativa de alcançá-lo. Parecia ser uma hipótese fácil o suficiente de ser testada, mas tínhamos que tomar muito cuidado, porque nosso objetivo não era ficar semanas desenvolvendo a funcionalidade de push notification mais fantástica que as nossas mentes doentias pudessem conceber, mas “fazer com que os usuários com instalações ativas reabrissem o aplicativo sistematicamente”. Não podíamos perder isso de vista.

Primeiro Experimento: implementar o push

Ok, qual era o mínimo que poderíamos construir para validar se o push notification realmente ajudaria a resolver nosso problema? Bom, primeiro tínhamos que habilitar o push nas duas plataformas (APNS para iOS e GCM para Android). Feito isso, precisávamos construir um servidor para enviar os pushes. Ao invés de construirmos esse servidor, simplesmente usamos um serviço como Urban Airship. Criamos uma conta lá, entramos no tier free, configuramos os aplicativos e começamos a testar com os nossos usuários de QA (colegas de trabalho da Concrete Solutions).

Logo no primeiro dia da implementação funcionando em QA, eu comecei a enviar pushes de teste, alguns vários (diga-se de passagem). Como ainda estava testando, confesso que errei na mão e mandei bastante pushes. Foi aí que eu comecei a receber o feedback dos meus colegas:

angry

“Victor, isso é um saco! Não aguento mais receber pushes, aposto que os usuários vão desinstalar os aplicativos se receberem mais do que um push por semana”

Isso atingiu o time em cheio. Tínhamos pulado uma etapa crucial de validação que era perguntar para os nossos clientes se eles queriam o push. Sem dourar muito a pílula, decidimos lançar a atualização do aplicativo com o push notification mesmo assim e usar a ferramenta de segmentação do Urban Airship para enviar o push para apenas um grupo, para depois atingir todo mundo.

Nessa época, o push simplesmente abria a app na home, com produtos listados como destaques. Rodamos o experimento por uma semana e começamos a ver números bem interessantes, por exemplo: no dia em que o push era enviado, víamos um pico de acesso exatamente na hora de disparo do push. Além disso, comparativamente as pessoas usavam a app mais vezes e por mais tempo nos dias em que mandávamos as notificações.

Picos de acesso push

Ainda assim, não conseguimos encontrar uma correlação entre o envio do push e os pedidos fechados, que é em última instancia o KPI que mais importava para nós. Mas conseguimos dar uma sacudida na recorrência de uso do app, usuários ativos e tempo de visita. Ótimo.

Segundo Experimento: fale com os seus clientes.

Mesmo com o sucesso dos números, ainda tinha gente em um círculo próximo de mim falando que eu estava mandando muitos pushes e que isso deveria estar incomodando. Foi aí que tomamos o conselho do Steve Blank ao pé da letra e literalmente “got out of the building“. Compilamos uma lista de 80 clientes que foram impactados pelo push e eu liguei para cada um deles perguntando se eles tinham recebido o push, se sim, o que achavam, se isso incomodava, e como poderia tornar a notificação melhor.

talk2

Para surpresa de quase todo mundo, absolutamente TODOS os entrevistados disseram que não se importavam com o push, e que na verdade até gostavam de receber, “pois era uma forma de avisá-los das boas promoções”. Alguns até me pediram para ser mais específico, por exemplo: “Se você pudesse me mandar apenas os pushes das categorias de eletrodomésticos eu vou achar isso muito legal”.

Essa entrevista qualitativa junto com as métricas de churn (desinstalação do app) nos deram o indicativo de que o push não só resolvia parte dos nossos problemas, como ainda era relevante para as pessoas. Hora de continuar iterando sobre essa hipótese.

comemoração

Terceiro experimento: push notifications para onde?

Muitas vezes enviávamos um push sobre um produto, o usuário caia na home e tinha que procurar esse produto nos destaques, o que era uma experiência ruim. Além disso, não víamos causalidade entre o produto sobre o qual falávamos no push e os pedidos que eram feitos naquele dia. Por isso, decidimos implementar o push que enviava o usuário direto para a tela de detalhe do produto. A partir dali, era só apertar “comprar” e seguir até o pedido fechado. Para nossa surpresa, o push específico de um produto não gerava vendas daquele produto, mas o tempo de uso da app e a quantidade de telas por sessão continuavam a aumentar.

Decidimos extrapolar um pouco e implementamos a possibilidade de enviar push notifications para 6 lugares em específico na app:

– home

– lista de produtos de uma categoria

– resultado de uma busca

– carrinho

– categoria

– detalhe de um produto

Assim, começamos a ter maleabilidade para experimentar, por exemplo, campanhas de push notifications para abandono de carrinho oferecendo desconto em produtos deixados no carrinho. Também decidimos que seria muito difícil acertar um produto específico que atendesse a todos os nossos usuários. Então, mandando produtos de uma categoria, poderíamos ter mais chance de converter um usuário diretamente a partir do push. Medimos a partir daí a taxa de conversão de cada um dos tipos de pushes e o perfil da pessoa impactada.

caminhos

Os resultados e aprendizados disso talvez sejam longos demais para serem descritos aqui, mas vale dizer que conseguimos aprender coisas que não imaginávamos sobre o comportamento do usuário, e o melhor:

“Uma notificação não incomoda, desde que ela seja relevante, contextualizada e personalizada para quem recebe”.

Quarto experimento: Segmentação é tudo!

Sabendo que contexto e relevância são importantes, começamos a fazer tracks dos hábitos de uso dos usuários e chegamos a conseguir mandar um desconto em ar condicionado apenas para os usuários que acessaram a categoria “Ar Condicionado” alguma vez na vida pelo app. Seguimos iterando nesse sentido, de forma a entender como conseguíamos aumentar a taxa de conversão sem ser ofensivo e invasivo para os nossos clientes.

segmentar

O ponto final dessa história não chega nem a ser o aprendizado em si, mas sim o método e o mindset que foi aplicado desde o início até o final dela:

1) Usamos dados para entender o que deveríamos melhorar em nosso aplicativo;

2) Concebemos hipóteses de soluções associadas ao problema;

3) Implementamos o mínimo possível (MVP) para validar a maioria das hipóteses;

4) Falamos com os nossos clientes para saber qualitativamente se estávamos indo na direção correta;

5) Olhamos as mesmas métricas que queríamos melhorar e vimos se elas eram impactadas após os experimentos;

6) rinse and repeat.

No próximo post, vou falar de um outro exemplo sobre como conseguimos validar hipóteses de soluções em um e-commerce web, ao qual não tínhamos nem acesso ao código fonte.

Gostou da história? Tem alguma dúvida ou quer saber mais sobre push notifications? Deixe seu comentário aqui embaixo!