Front de lojas virtuais: segmentação e aluguel

O valor do aluguel do ponto de venda de uma loja física está diretamente associado à quantidade de pessoas que habitualmente transitam por ele, por isso, parte da despesa com propaganda da loja está implícita no aluguel[1]. O lojista virtual também arca com o “aluguel” de seu “ponto de venda” a pagar à empresa que desenvolveu o front (tal como um locador), só que, pelo seu ponto ninguém naturalmente transita. A análise deste aluguel é o tema central deste artigo em complemento ao artigo “Precificação e custo de produção de software”.

Com base nas diferenciações de produto e de políticas comerciais dos desenvolvedores de front de lojas virtuais, este artigo deriva uma segmentação do mercado de lojistas consumidores de front[2] , analisa modelos de precificação através de suas métricas e restrições e, por fim, formaliza algumas das regras de precificação em uso, permitindo comparar os modelos entre si.

A – Introdução

O mercado brasileiro de desenvolvedores de front de lojas virtuais tem seguido o padrão habitual de crescimento de empresas de software. No fim dos anos 90 e início de 2000 alguns desenvolvedores de software produziram fronts de lojas virtuais sob demanda ainda carregadas de características próprias do ramo de negócio ao qual se destinavam, período em que as oportunidades de entrada no mercado estavam abertas a pequenos e ousados empresários. Com o aumento da demanda, os desenvolvedores bem-sucedidos começaram a generalizar suas particulares soluções a fim de ganhar maior flexibilidade e abrangência funcional em busca de ganho de escala, dando a largada para a concentração do mercado por meio de fusões e aquisições, bloqueando a entrada de novos concorrentes[3]. Basta notar que atualmente há duas empresas estrangeiras disputando a liderança do mercado de pequenos lojistas e poucas empresas nacionais de grande porte oferecendo soluções especificas para cada segmento de mercado com diferentes marcas.

B – Estrutura e mercado

A estrutura do mercado de software de front de lojas pode ser considerada como um monopólio concorrencial, onde todos os concorrentes oferecem produtos com as funções indispensáveis aos seus fins. Porém, cada um deles se esforça para diferenciá-los por meio de funções complementares, desempenho, navegabilidade, prontidão do suporte técnico, frequência de atualizações, possibilidades de personalização, variedade de templates[4], percentual de uptime[5], abrangência de integração (prevenção de fraude, meios de pagamento, marketplaces e transportadoras) etc. Os produtos são oferecidos aos lojistas por assinatura (aluguel da licença de uso) cujo processamento e armazenamento de dados são executados em nuvem.

C – Segmentação

Esta variedade de ofertas de front está diretamente associada a segmentação do mercado de lojistas virtuais, cujos segmentos são coincidentes com as regras de comercialização praticadas pelos prestadores de serviço, especificamente pela precificação.

O primeiro nível de segmentação é composto por dois grupos: lojistas dispostos a pagar um aluguel a preço fixo e lojistas que aceitam pagar um aluguel a preço variável, ainda que sujeito a diferentes indicadores.

1. Aluguel a preço fixo

Como os custos de produção para os desenvolvedor têm um componente variável, aqueles que optam por praticarem preços fixos impõem restrições de volume e de funcionalidades aos seus produtos, ambas limitando seus custos de produção.

A restrição de uso delimita o custo do processamento em nuvem, impedindo que o lojista exceda determinados níveis de transações e de armazenamento, usando barreiras relativas à quantidade de itens cadastrados, de visitas e/ou de usuários simultâneos. A restrição funcional serve como fator limitante do custo de instalação e do suporte técnico, estando implícita no tipo de loja a ser oferecido. Tais imposições permitem identificar o mercado ao qual este tipo de oferta se destina: lojistas iniciantes e/ou de pequeno porte.

A estratégia básica de expansão do faturamento dos desenvolvedores que operam neste mercado é estender a base de clientes com sacrifício da margem, objetivando o aumento da massa de lucro. Para tanto, são compelidos à redução de investimentos em P&D (restrição de versionamento), minimização das despesas com suporte, promoção de melhorias funcionais somente sob forte pressão dos clientes e simplificação da instalação e da operacionalidade.

O quadro abaixo sintetiza os grupos de precificação com valor fixo mensal.

Quadro 1: preço fixo

Grupo

Variáveis que limitam o uso de recursos



Visitas

Itens

Usuários

1 LV


x


2 XT

X

x


3 LI

X

x

x

2. Aluguel a preço variável

Podem ser identificados quatro grupos de precificação de ofertas de serviço de front a preço variável, cada um deles com seu próprio método de mensuração do serviço prestado.

2.1. Pageview

No primeiro grupo, o preço do aluguel é diretamente relacionado à quantidade de pageviews acessadas, cuja taxa decresce com a quantidade. Este modelo tem sido usada por desenvolvedores tradicionais de ERP com processamento em nuvem. Em geral, tais empresas têm adquirido soluções de front de loja e, com grande esforço técnico e operacional, integrando-as ao seu back-office. O objetivo tem sido possibilitar que sua base instalada possa vender por meio do novo canal de vendas e, ao mesmo tempo, impedir a entrada de concorrentes em seus clientes. Caso a venda online do cliente ultrapasse um limite máximo de pageviews previamente estabelecido, o modelo de precificação passa a ser por taxa incidente sobre o valor do pedido faturado pelo canal.

Para reduzir o custo neste modelo de precificação, o lojista deve aumentar a taxa de conversão e/ou diminuir a média de pageviews por visita (one click), tarefas, como se sabe, nada fáceis.

2.2. Quantidade de pedidos

O segundo grupo, direcionado a um mercado de porte intermediário, estabelece uma taxa incidente sobre a quantidade de pedidos pagos e crescente em relação ao tipo de loja. Dado que são desconsideradas aas variáveis indicativas do nível de uso (quantidade de visitas, de pageviews, de itens ou de usuários), a contenção do uso de recursos computacionais provém da restrição funcional das lojas ofertadas.

Sob esta política comercial, o aumento da taxa de conversão interessa a ambas as partes. No entanto, sob o ponto de vista da despesa do lojista com o aluguel do front, a queda da taxa de conversão não o afeta, mas reduz a receita do desenvolvedor. Neste segmento, há maior interesse do desenvolvedor em investir em P&D a fim de ganhar o mercado dos egressos do aluguel a preço fixo que ainda não têm recursos para entrar no segmento de custo variável baseado em valor do pedido.

2.3. Gigabytes transferidos

Neste modelo, o preço cobrado do lojista é um reflexo direto do custo de produção do desenvolvedor do front, pois, a quantidade de gigabytes transferidos pelo site do lojista mede tanto a despesa do desenvolvedor do front com seu fornecedor de computação em nuvem como o consumo realizado pelo lojista em suas operações. Este modelo, sem qualquer restrição, ao fornecer a composição detalhada das despesas, permite ao lojista analisá-las e modificar seus processos visando reduzir o aluguel.

2.4. Valor do pedido

O quarto grupo estabelece uma taxa incidente sobre o valor do pedido com pagamento aprovado. Os lojistas criticam este modelo por admitir prestador de serviço como “sócio”. Os desenvolvedores se defendem argumentando que o custo da não conversão é totalmente absorvido por eles. A opção do lojista em remunerar o prestador por pageview ou por visita implica que ele assume a incerteza da venda, obrigando-o a aumentar a taxa de conversão e/ou reduzir a quantidade média de pageviews a fim de reduzir custos. A opção do lojista em remunerar o prestador somente quando da efetividade e valor da venda implica transferir para o prestador o ônus da incerteza da venda (visitas não convertidas em pedidos aprovados) excedente ao custo fixo[6].

Este segmento é composto por lojas com grande volume de pedidos, exigentes em termos de desempenho, nível de disponibilidade funcional e ávidas por possuírem as mais atuais funcionalidades que aumentem a conversão. Justamente neste último requisito se concentram inesgotáveis e convincentes argumentos de marketing dos fornecedores de front – o clássico “com isso você vai vender 20% a mais” -, baseados no contínuo esforço em incorporar em suas soluções todo o manancial de habilidades do vendedor presencial, quase sempre, omitindo a natureza acentuadamente sistêmica do processo de venda não presencial.

Os prestadores de serviço que usam este tipo de precificação se diferenciam pelos fatores usados na redução da taxa: uns usam o porte do cliente e outros o prazo para creditar o lojista. A redução da taxa em função do porte do cliente evidencia o caráter regressivo desta política (quanto maior for o porte do varejista, menor a incidência do aluguel do front sobre seu faturamento), evitando que os grandes varejistas optem por produzirem seus próprios fronts.

Valor do pedido: porte do cliente

O primeiro subgrupo reduz a taxa na relação direta com o porte do cliente por três modos distintos: (i) valor mínimo anual a ser pago pelo lojista com aplicação de sobretaxa incidente nas vendas por marketplace; (ii) quantidade de usuários simultâneos e (iii) quantidade máxima de visitas e de itens cadastrados. Em essência, todas as regras de redução de taxas são relativamente equivalentes, pois; grandes lojistas (i) faturam alto; (ii) ofertam grande variedade de artigos (itens cadastrados); (iii) têm marcas fortes e (iv) investem em propaganda (diretamente relacionada com a quantidade de visitas ao site).

Valor do pedido: prazo de crédito ao lojista

Num segundo subgrupo, a loja e o gateway são integrados, assim, a taxa incidente sobre o valor do pedido varia na relação inversa com o prazo do crédito ao lojista.

O valor do faturamento do cliente é o que interessa aos desenvolvedores que optam por esta política de preço. Desse modo, os embates entre eles ocorrem no mercado de grandes lojistas desprovidos de desenvolvimento próprio. Isso exige: alto nível de serviços (suporte e uptime); atualizações frequentes (inovações e acompanhamento da concorrência) e alto desempenho operacional (processamento de alto volume de pedidos).

Como este mercado é relativamente pequeno no Brasil, os desenvolvedores são obrigados a também operarem no mercado externo em busca de ganhos de escala.

O quadro abaixo sintetiza os grupos de precificação variável.

Quadro 2: Preço variável

Grupo

Métrica

Variáveis que afetam o decréscimo da taxa por aumento de volume



Incidência

da taxa

Canal

Pagto incluso

Qtde Visitas

QtdeItens

Page

views

Tipo Loja

Qtde

Usuários

Valor

Mínimo

1

Pageview





x




2

Qt pedido






x



3

Giga transf.









3.1

Vl pedido

x







x

3.2

Vl pedido







x


3.3

Vl pedido



x

x





3.4

Vl pedido


x







 

D – Fórmulas e comparação entre modelos de precificação variável[7]

Variáveis e taxas usadas na precificação

Para analisar os diferentes modelos de precificação entre si, vamos usar dados de mercado e de cada loja em particular. Dados de cada loja: valor do faturamento = V; quantidade mensal de pedidos = p[7]; ticket médio = V/p = v; taxa de conversão = c; número de visitas = p/c e média de pageviews por visita = z. Dados de mercado: taxa cobrada por pedido pago = r; taxa sobre o valor faturado = t; taxa cobrada por pageview = k e custo Fixo = CF por faixa do indicador de uso.

Formulação dos custos por modelo

Modelos

Custo Total

Quantidade de pedidos

r.p + CF

Quantidade de pageviews

k.z.p/c + CF

% valor faturado, diferencial por canal

t.p.v + CF

Exemplos

Para calcular simplificadamente o aluguel do front por modelo de precificação em função da sua respectiva variável determinante vamos usar os seguintes, considerando os custos fixos médios praticados pelo mercado: ticket médio (v) = R$ 250,00; taxa de conversão (c) = 1,5%; quantidade mensal de pedidos (p) = 400 e quantidade de pageview por visita (z) = 6.

Os custos totais por modalidade e por pedido seriam:

      • Custo/quantidade de pedidos = r.p + CF = r.400 + 200

      • Custo/ pageview, = k.z.p/c + CF = k.6.400/0,015 + 960 = k.160000 + 960

      • Custo/valor faturado = t.p.v + CF = t.400.250 + 1500 = t.100000 + 1500

Algumas comparações:

  1. O custo baseado no valor do pedido (t) seria inferior ao custo baseado na quantidade de pedidos quando r.400 + 200 ≥ t.100000 + 1500, ou r ≥ t.250 + 3,25. Tomando t = 0,025, então a taxa sobre a quantidade de pedidos (r) deve ser superior a 9,5.

  2. O custo baseado no valor do pedido (t) seria inferior ao custo por pageview (k) quando k.160000 + 960 ≥ t.100000 + 1500 ou k ≥ t.0,625 + 0,003. Tomando t = 0,025, então a taxa por quantidade de pedidos k deve ser superior a 0,019‬.

 

Fernando Di Giorgi,
setembro de 2019

 

[1]  Maiores detalhes sobre o assunto estão em https://www.ecommercebrasil.com.br/artigos/o-ponto-no-e-commerce/
[2] Uso o termo front de loja virtual ao invés de plataforma por este último termo ter um significado bem mais amplo, para detalhes veja http://www.fernandodigiorgi.blog.br/2018/03/15/plataformas-digitais-classificacao-mercado-e-modalidades-de-trabalho/
[3] Tratando-se de software, o processo de concentração é mais acelerado e mais impeditivo aos entrantes no mercado. O líder estabelece padrões, conta com abundância de mão de obra com conhecimentos operacionais de sua solução, usufrui da contribuição gratuita dos usuários no apontamento de erros e na sugestão de melhorias, reduz o custo de suporte, estende sua abrangência funcional pela automação de procedimentos excepcionais e, sobretudo, dispõe de capital para aquisições.
[4] Modelos preestabelecidos de lojas que evitam o trabalho de configuração do usuário.
[5] Percentual do tempo em que o sistema está operacionalmente disponível sobre o tempo total
[6] O percentual cobrado sobre o valor do pedido é uma outra discussão fora do contexto deste artigo, mas é bom lembrar que numa cadeia produtiva, lucros excessivos de um elo implica a dedução dos lucros dos demais.
[7] Para evitar fórmulas mais extensas, serão omitidas as taxas diferenciadas por canal.
[8] Se houver taxa adicional por canal de venda, a fórmula deve incluir pl = quantidade de pedido da loja, pm = quantidade de pedidos do marketplace, vl = ticket médio da loja, vm = ticket médio do marketplace e tl = tx usada na loja, tm = tx taxa usada para o marketplace)

 

 

Compartilhe

Categorias

Artigos mais recentes

Tags