Sistemas de Recomenda??o procuram recomendar informa??o e produtos (como computadores, m?quinas fotogr?ficas, filmes, videos, m?sicas, livros, p?ginas de internet, etc.) que possam ser de interesse do usu?rio, esses sistemas procuram e identificam padr?es de interesse, perfil e consumo. A partir desses padr?es os sistemas de intelig?ncia artificial geram associa??es entre produtos e consumidores aplicando t?cnicas de filtragem colaborativa.

Sistemas de Recomenda??o processam as informa??es que o usu?rio d? ao site durante a navega??o e entregam dicas de produtos relacionados aos gostos e interesses do consumidor, fazendo parte dos sistemas de Behavioral Targeting, ou Marketing Comportamental.

Por?m s? a utiliza??o de Intelig?ncia Artificial, Filtragem Colaborativa e outras t?cnicas computacionais n?o garantem o aumento de convers?o, pois o consumidor precisa impactado de maneira positiva pelas recomenda??es, a seguir voc? encontrar? dicas e melhores pr?ticas de como direcionar o usu?rio-consumidor para uma melhor compra.

Elementos de uma vitrine

T?tulo

1. Utilize cores diferenciadas do layout do site;
2. Utilize n?meros: “60% das pessoas” constroi um fator de confian?a na cabe?a do consumidor.

Cores

1. Utilize cores contrastantes que d?em destaque para a se??o de recomenda??o. Cuidado para n?o sobrecarregar, a se??o deve parecer como um an?ncio.

Produtos

1. Oferece sempre poucas op??es. Apenas 3 ou 4 recomenda??es s?o suficientes.

Chamada para a??o (Call-to-action)

1. Se voc? utilizar mais de uma chamada pra a??o, tenha uma como principal com maior destaque dentro da se??o de recomenda??o.

Melhores pr?ticas

Confira as melhores pr?ticas para conseguir um maior ?ndice de convers?o de suas vitrines de recomenda??o.

Menos sempre ? mais

Tente o UpSell, pelo menos o Cross Sell

Exclua Recomenda??es

Descontos funcionam

Senso de urg?ncia

Continue testando

Sua loja utiliza sistemas de recomenda??es de produtos?

Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.

As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.

Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.

Preparação

Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.

Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.

Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.

Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio

A idéia

Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).

Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.

A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.

Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).

Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/

Planejando a execução

Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.

Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.

Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.

Dividindo tarefas

Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.

Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).

Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.

Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).

No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.

Logística

Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.

Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.

Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.

Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito

Execução

Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.

Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.

Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.

Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.

Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.

Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.

Tendência ao amadorismo

Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.

Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.

Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.

Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.

Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.

Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).

O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.

Lições aprendidas

O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).

Amadorismo

Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.

Equipe

Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.

No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.

Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo ).

Descanso

Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.

Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.

Design

Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)

Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.

Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.

A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.

Refactoring

Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.

O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.

Conclusão final

Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.

Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.

Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .

Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.

Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês

Já é notícia um pouco velha (do dia 15/Junho) mas eu achei que valia a pena postar aqui por conta da sua importância e pelo fato de pouca gente conhecer. Michael Scherotter (@synergist) postou uma atualização do Analytics Framwork para Silverlight 4. Para quem não conhece, o Analytics Framework é uma coleção de apis, Behaviors e Actions para integração de aplicações Silverlight e WPF com ferramentas de analytics e trends (como Google Analytics por exemplo).

O framework suporta nativamente uma série de serviços (Google Analytics, Nedstat, Omniture, Webtrekk, etc para citar alguns) e pode ser facilmente extendido. Se você deseja monitorar a utilização da sua aplicação Silverlight deve considerar o uso desse framework.

Alguns dos pontos mais interessantes desse framework estão listados abaixo:

• Suporta aplicações OOB
• Funciona mesmo se a aplicação estiver rodando offline (as métricas são salvas e serão enviadas para o servidor quando estiver online)
• Suporta o uso de mais de um serviço de analytics ao mesmo tempo
• Não afeta a performance da aplicação
• Pode ser totalmente configurado no Blend pois é implementado como uma série de Behaviors
• Suporta testes A/B
• Suporta protótipos SketchFlow
• Está integrado no Microsoft Silverlight Media Framework

Para mais informações acesse:

• http://blogs.msdn.com/b/synergist/archive/2010/06/15/microsoft-silverlight-analytics-framework-updated-for-silverlight-4.aspx
• http://msaf.codeplex.com/
• http://live.visitmix.com/MIX10/Sessions/CL24 (apresentação feita no MIX10)
• https://www112.livemeeting.com/cc/microsoft/view?id=H9494W (Using the Microsoft Silverlight Analytics Framework)
• https://www112.livemeeting.com/cc/microsoft/view?id=MRGR8S (Building Components for MSAF)

Hoje em dia, e no momento em que estamos “agarrados” a muitas redes sociais como o Twitter, Facebook, Vimeo e outros, é interessante manter-mo-nos sempre a par de algumas estatísticas deste tipo de sites, como por exemplo, a quantidade de pessoas que nos seguem.

No caso concreto do iPhone, há várias aplicações como o Analytics (Google) ou TweetDeck (Twitter) que nos permitem aceder a esse tipo de estatísticas, mas sofrem do mesmo problema. Só podemos utilizar uma de cada vez, e torna-se um inconveniente o facto de andar a navegar de aplicação em aplicação. Torna-se então necessário arranjar aplicações que nos permitam aceder a esse tipo de informações de forma rápida a concisa.

Assim, podemos pensar que existem dois tipos de aplicações para o iPhone.

1. As que se dedicam a fazer apenas uma coisa, e geralmente bem (por exemplo, jogos, aplicações dedicadas a um objectivo apenas, etc);
2. As que agregam vários serviços e tentam fazer várias coisas ao mesmo tempo;

Neste caso, venho falar de uma aplicação que agrega características deste segundo grupo, ou seja, uma aplicação que agrega muitos serviços.

Falando então da aplicação que me fez criar este post, Ego. Com este nome curioso, esta aplicação permite-nos ter, no mesmo sítio, acesso a várias estatísticas de vários sites.

A saber:

1. Twitter;
2. Vimeo;
3. Feedburner;
4. Google Analytics;
5. SquareSpace;
6. Ember;
7. Mint;

O interface é bastante interessante, colorido, e minimalista, o que torna a utilização da aplicação uma maravilha! Vai ficar pelo meu iPhone por muitos meses de certeza. Sem mais demoras, aqui fica o site da aplicação. Vão ver que vale mesmo a pena!

Ego for iPhone

eu assisti aqui no MIX10 a uma belissima palestra sobre como mensurar o que o usuário faz numa aplicação Silverlight (desde cliques até consumo de vídeos) e reportar isso para um serviço de analytics.   pra minha e nossa alegria esse framework…(read more)

Similar Posts:

• II. ControleAtividade – Análise de Requisitos
• OFF – Não vai desistir, Vai?
• TUTORIAL JAVA + FLEX NA PRÁTICA 6/6
• Google Analytics + Adobe Flex (Flash)
• Formatando e Somando Datas no Flex

O Google Analytics é uma ferramenta fabulosa para medir o uso do seu site. Você define metas de conversão, verifica como os visitantes chegam até você e tem uma infinidade de outras informações à disposição, extremamente úteis para analisar o desempenho do seu site ou o impacto de uma modificação no mesmo.

Para que isso seja possível é necessário inserir um código JavaScript no site, depois de criar um conta no Analytics e cadastrá-lo lá. O processo é simples e rápido.

Os sites em Flash ou as aplicações em Flex, que não executam JavaScript diretamente, não podiam se beneficiar dessa ferramenta. Não podiam, mas agora podem. O Google lançou uma biblioteca de rastreamento, que pode ser usado através de componentes visuais ou AS3, tanto no Flash quanto no Flex. Veja o artigo publicado no blog do Analytics sobre o assunto.

Ainda não testei o recurso, mas postarei mais detalhes assim que tiver utilizado a biblioteca.

Outros posts

• Charge – o Google dominando o mundo
• Pluralização “irregular”
• RichTextEditor customizado com suporte a XHTML no Flex
• Recuperando dados de HD formatado
• Campanha para eliminar browsers antigos da rede
• Definindo a ordem inicial de um DataGrid no Flex 3
• Trocando seis por meia dúzia
• As dez tecnologias dos próximos anos
• O grande colisor de Hadrons
• Melhor visualizado em browsers com precisão cirúrgica …

© Elvis for Elvis Fernandes, 2008. |
Permalink |
2 comentários |
Adicione ao
del.icio.us


Tags: análise, analytics, desempenho, site