Todas as coisas distribuídas.
Werner Vogels 'weblog sobre a construção de sistemas distribuídos escaláveis e robustos.
Eventualmente consistente - revisitado.
Eu escrevi uma primeira versão desta publicação em modelos de consistência há cerca de um ano, mas nunca fui feliz com isso, como foi escrito com pressa e o tópico é importante o suficiente para receber um tratamento mais completo. A ACM Queue pediu-me para revisá-lo para uso em sua revista e aproveitei a oportunidade para melhorar o artigo. Esta é a nova versão.
Eventualmente consistente - Construir sistemas distribuídos confiáveis em escala mundial exige compensações entre consistência e disponibilidade.
Na base da computação em nuvem da Amazon, estão os serviços de infra-estrutura, como o S3 (Simple Storage Service) da Amazon, o SimpleDB e o EC2 (Elastic Compute Cloud) que fornecem recursos para a construção de plataformas de computação em escala da Internet e uma grande variedade de aplicativos. Os requisitos impostos a esses serviços de infra-estrutura são muito rigorosos; eles precisam marcar altas notas nas áreas de segurança, escalabilidade, disponibilidade, desempenho e custo-eficácia, e eles precisam atender a esses requisitos enquanto servem milhões de clientes em todo o mundo, continuamente.
Sob as coberturas, esses serviços são sistemas distribuídos maciços que operam em escala mundial. Essa escala cria desafios adicionais, porque quando um sistema processa trilhões e trilhões de solicitações, os eventos que normalmente têm uma baixa probabilidade de ocorrência agora estão garantidos e devem ser considerados para a frente no design e arquitetura do sistema. Dado o alcance global desses sistemas, utilizamos técnicas de replicação de forma ubíqua para garantir desempenho consistente e alta disponibilidade. Embora a replicação nos aproxima de nossos objetivos, não pode alcançá-los de forma perfeitamente transparente; Em uma série de condições, os clientes desses serviços serão confrontados com as conseqüências do uso de técnicas de replicação dentro dos serviços.
Uma das maneiras pelas quais isso se manifesta é o tipo de consistência de dados fornecido, particularmente quando o sistema distribuído subjacente fornece um eventual modelo de consistência para a replicação de dados. Ao projetar esses sistemas de grande escala na Amazon, usamos um conjunto de princípios orientadores e abstrações relacionadas à replicação de dados em grande escala e focamos os trade-offs entre alta disponibilidade e consistência de dados. Neste artigo, apresento alguns dos antecedentes relevantes que informaram nossa abordagem para fornecer sistemas distribuídos confiáveis que precisam operar em escala global. Uma versão anterior deste texto apareceu como publicação no blog All Things Distributed em dezembro de 2007 e foi muito melhorada com a ajuda de seus leitores.
Em um mundo ideal, haveria apenas um modelo de consistência: quando uma atualização é feita, todos os observadores veriam essa atualização. A primeira vez que isso surgiu como difícil de alcançar foi nos sistemas de banco de dados do final dos anos 70. A melhor "peça de período" sobre este tópico é "Notas sobre bancos de dados distribuídos" por Bruce Lindsay et al. 5 Ele estabelece os princípios fundamentais para a replicação do banco de dados e discute uma série de técnicas que lidam com a consistência. Muitas dessas técnicas tentam alcançar transparência de distribuição e mdash, ou seja, para o usuário do sistema, parece que existe apenas um sistema em vez de uma série de sistemas de colaboração. Muitos sistemas durante este tempo tomaram a abordagem de que era melhor deixar o sistema completo do que romper essa transparência. 2.
Em meados da década de 90, com o surgimento de sistemas Internet maiores, essas práticas foram revisadas. Naquela época, as pessoas começaram a considerar a idéia de que a disponibilidade era talvez a propriedade mais importante desses sistemas, mas eles estavam lutando com o que deveria ser negociado. Eric Brewer, professor de sistemas da Universidade da Califórnia, Berkeley e, naquela época, chefe da Inktomi, reuniu os diferentes trade-offs em um discurso principal na conferência PODC (Principes de Distribuição de Computação) em 2000. 1 Ele apresentou o CAP teorema, que afirma que de três propriedades de sistemas de dados compartilhados e mdash, consistência de dados, disponibilidade do sistema e tolerância à partição de rede e mdash, apenas dois podem ser alcançados em qualquer momento. Uma confirmação mais formal pode ser encontrada em um artigo de 2002 de Seth Gilbert e Nancy Lynch. 4.
Um sistema que não é tolerante às partições de rede pode alcançar a consistência e a disponibilidade dos dados, e muitas vezes o faz usando protocolos de transação. Para fazer isso funcionar, o cliente e os sistemas de armazenamento devem fazer parte do mesmo ambiente; eles falham como um todo sob certos cenários e, como tal, os clientes não podem observar partições. Uma observação importante é que em grandes sistemas de escala distribuída, as partições de rede são uma dada; portanto, a consistência e a disponibilidade não podem ser alcançadas ao mesmo tempo. Isso significa que há duas escolhas sobre o que deixar: a consistência relaxante permitirá que o sistema permaneça altamente disponível nas condições particionáveis, enquanto que fazer consistência uma prioridade significa que, sob certas condições, o sistema não estará disponível.
Ambas as opções exigem que o desenvolvedor do cliente esteja ciente do que o sistema está oferecendo. Se o sistema enfatiza a consistência, o desenvolvedor tem que lidar com o fato de que o sistema pode não estar disponível para tomar, por exemplo, uma gravação. Se essa escrita falhar por falta de disponibilidade do sistema, o desenvolvedor terá que lidar com o que fazer com os dados a serem escritos. Se o sistema enfatiza a disponibilidade, ele sempre pode aceitar a gravação, mas sob certas condições, uma leitura não refletirá o resultado de uma escrita recentemente concluída. O desenvolvedor então tem que decidir se o cliente precisa acessar a última atualização absoluta o tempo todo. Há uma variedade de aplicações que podem lidar com dados vagamente obsoletos, e são atendidos bem sob este modelo.
Em princípio, a propriedade de consistência dos sistemas de transação, conforme definido nas propriedades ACID (atomicidade, consistência, isolamento, durabilidade) é um tipo diferente de garantia de consistência. Em ACID, a consistência refere-se à garantia de que, quando uma transação é concluída, o banco de dados está em um estado consistente; por exemplo, ao transferir dinheiro de uma conta para outra, o valor total detido em ambas as contas não deve mudar. Nos sistemas baseados em ACID, esse tipo de consistência é muitas vezes da responsabilidade do desenvolvedor redigir a transação, mas pode ser assistido pelo banco de dados gerenciando restrições de integridade.
Consistência & mdash; Cliente e Servidor.
Existem duas maneiras de analisar a consistência. Um é do ponto de vista do desenvolvedor / cliente: como eles observam as atualizações de dados. O segundo caminho é do lado do servidor: como as atualizações fluem através do sistema e o que os sistemas de garantia podem dar com relação às atualizações.
O lado do cliente tem esses componentes:
Um sistema de armazenamento. Por enquanto, tratamos isso como uma caixa preta, mas deve-se supor que sob as capas é algo de grande escala e altamente distribuído, e que é construído para garantir durabilidade e disponibilidade. Processo A. Este é um processo que grava e lê do sistema de armazenamento. Processos B e C. Estes dois processos são independentes do processo A e são escritos e lidos a partir do sistema de armazenamento. É irrelevante se estes são realmente processos ou tópicos dentro do mesmo processo; O importante é que eles sejam independentes e precisam se comunicar para compartilhar informações.
A consistência do lado do cliente tem a ver com como e quando os observadores (neste caso, os processos A, B ou C) vêem as atualizações feitas em um objeto de dados nos sistemas de armazenamento. Nos exemplos a seguir que ilustram os diferentes tipos de consistência, o processo A fez uma atualização para um objeto de dados: consistência forte. Após a conclusão da atualização, qualquer acesso subseqüente (por A, B ou C) retornará o valor atualizado. Fraca consistência. O sistema não garante que os acessos subseqüentes retornem o valor atualizado. Uma série de condições precisam ser atendidas antes que o valor seja retornado. O período entre a atualização e o momento em que é garantido que qualquer observador verá sempre o valor atualizado é apelidado de janela de inconsistência. Consistente consistência. Esta é uma forma específica de consistência fraca; o sistema de armazenamento garante que se nenhuma nova atualização for feita para o objeto, eventualmente todos os acessos retornarão o último valor atualizado. Se não ocorrerem falhas, o tamanho máximo da janela de inconsistência pode ser determinado com base em fatores como atrasos de comunicação, a carga no sistema e o número de réplicas envolvidas no esquema de replicação. O sistema mais popular que implementa a eventual consistência é DNS (Domain Name System). As atualizações para um nome são distribuídas de acordo com um padrão configurado e em combinação com caches com controle de tempo; eventualmente, todos os clientes verão a atualização.
O modelo de consistência final tem uma série de variações que são importantes a considerar:
Consistência causal. Se o processo A se comunicou ao processo B, atualizou um item de dados, um acesso subsequente pelo processo B retornará o valor atualizado, e uma gravação é garantida para substituir a escrita anterior. O acesso pelo processo C que não possui relação causal ao processo A está sujeito às regras de consistência normal. Read-your-writes consistency. Este é um modelo importante em que o processo A, depois de atualizar um item de dados, sempre acessa o valor atualizado e nunca verá um valor mais antigo. Este é um caso especial do modelo de consistência causal. Consistência da sessão. Esta é uma versão prática do modelo anterior, onde um processo acessa o sistema de armazenamento no contexto de uma sessão. Enquanto a sessão existir, o sistema garante a consistência de leitura e escrita. Se a sessão terminar por causa de um determinado cenário de falha, é necessário criar uma nova sessão e as garantias não se sobrepõem às sessões. Consistência de leitura monotônica. Se um processo tiver visto um valor particular para o objeto, quaisquer acessos subseqüentes nunca retornarão quaisquer valores anteriores. Consistência de escrita monotônica. Nesse caso, o sistema garante a serialização das gravações pelo mesmo processo. Os sistemas que não garantem esse nível de consistência são notoriamente difíceis de programar.
Algumas dessas propriedades podem ser combinadas. Por exemplo, pode-se obter leituras monotônicas combinadas com a consistência do nível da sessão. Do ponto de vista prático, estas duas propriedades (leituras monotônicas e leituras) são mais desejáveis em um sistema de consistência, mas nem sempre é necessário. Essas duas propriedades tornam mais simples para os desenvolvedores criar aplicativos, permitindo ao sistema de armazenamento relaxar a consistência e fornecer alta disponibilidade.
Como você pode ver a partir dessas variações, são possíveis alguns cenários diferentes. Depende das aplicações específicas, quer seja ou não lidar com as consequências.
A consistência eventual não é uma propriedade esotérica de sistemas distribuídos extremos. Muitos RDBMS modernos (sistemas de gerenciamento de banco de dados relacionais) que fornecem confiabilidade de backup primário implementam suas técnicas de replicação em modos síncronos e assíncronos. No modo síncrono, a atualização da réplica faz parte da transação. No modo assíncrono, as atualizações chegam ao backup de forma retardada, muitas vezes através do envio de logs. No último modo se o primário falhar antes dos registros serem enviados, a leitura do backup promovido produzirá valores antigos e inconsistentes. Além disso, para suportar melhor desempenho de leitura escalável, os RDBMSs começaram a fornecer a capacidade de ler a partir do backup, que é um caso clássico de fornecer eventuais garantias de consistência em que as janelas de inconsistência dependem da periodicidade do envio de logs.
No lado do servidor, precisamos dar uma olhada mais profunda em como as atualizações fluem através do sistema para entender o que impulsiona os diferentes modos que o desenvolvedor que usa o sistema pode experimentar. Vamos estabelecer algumas definições antes de começar:
N = número de nós que armazenam réplicas dos dados.
W = o número de réplicas que precisam confirmar o recebimento da atualização antes da atualização ser concluída.
R = o número de réplicas que são contatadas quando um objeto de dados é acessado através de uma operação de leitura.
Se W + R & gt; N, então o conjunto de escrita e o conjunto de leitura sempre se sobrepõem e um pode garantir consistência forte. No cenário RDBMS de backup primário, que implementa replicação síncrona, N = 2, W = 2 e R = 1. Não importa de qual replica o cliente lê, sempre obterá uma resposta consistente. Na replicação assíncrona com a leitura do backup habilitado, N = 2, W = 1 e R = 1. Nesse caso R + W = N, e a consistência não pode ser garantida.
Os problemas com essas configurações, que são protocolos básicos de quorum, é que quando o sistema não pode gravar em nós W devido a falhas, a operação de gravação deve falhar, marcando a indisponibilidade do sistema. Com N = 3 e W = 3 e apenas dois nós disponíveis, o sistema terá que falhar a gravação.
Em sistemas de armazenamento distribuído que precisam fornecer alto desempenho e alta disponibilidade, o número de réplicas é, em geral, superior a dois. Os sistemas que se concentram exclusivamente na tolerância a falhas costumam usar N = 3 (com configurações W = 2 e R = 2). Os sistemas que precisam servir cargas de leitura muito altas geralmente replicam seus dados além do que é necessário para a tolerância a falhas; N pode ser dezenas ou mesmo centenas de nós, com R configurado para 1, de modo que uma única leitura retornará um resultado. Os sistemas que estão preocupados com a consistência são definidos como W = N para atualizações, o que pode diminuir a probabilidade de a gravação ter sucesso. Uma configuração comum para esses sistemas que estão preocupados com a tolerância a falhas, mas não a consistência, é executar com W = 1 para obter durabilidade mínima da atualização e, em seguida, confiar em uma técnica preguiçosa (epidemia) para atualizar as outras réplicas.
Como configurar N, W e R depende do que é o caso comum e qual caminho de desempenho precisa ser otimizado. Em R = 1 e N = W, otimizamos para o caso de leitura, e em W = 1 e R = N, otimizamos para uma escrita muito rápida. É claro, no último caso, a durabilidade não é garantida na presença de falhas, e se W & lt; (N + 1) / 2, existe a possibilidade de escrever conflitos quando os conjuntos de escrita não se sobrepõem.
A consistência fraca / eventual surge quando W + R & lt; = N, o que significa que existe a possibilidade de que o conjunto de leitura e gravação não se sobreponha. Se esta é uma configuração deliberada e não baseada em um caso de falha, dificilmente faz sentido ajustar R para qualquer coisa, exceto 1. Isso acontece em dois casos muito comuns: a primeira é a replicação maciça para escala de leitura mencionada anteriormente; O segundo é onde o acesso a dados é mais complicado. Em um modelo de valor-chave simples, é fácil comparar versões para determinar o valor mais recente escrito no sistema, mas em sistemas que retornam conjuntos de objetos, é mais difícil determinar qual o conjunto mais recente correto. Na maioria desses sistemas onde o conjunto de escrita é menor do que o conjunto de réplicas, existe um mecanismo que aplica as atualizações de maneira preguiçosa aos nós restantes no conjunto da réplica. O período até todas as réplicas foram atualizadas é a janela de inconsistência discutida antes. Se W + R & lt; = N, o sistema é vulnerável a leitura de nós que ainda não receberam as atualizações.
Seja ou não leitura-sua-escrita, sessão e consistência monotônica pode ser alcançada depende, em geral, da "adesão" dos clientes ao servidor que executa o protocolo distribuído para eles. Se este é o mesmo servidor de cada vez, então é relativamente fácil garantir a leitura de suas escritas e leituras monotônicas. Isso torna um pouco mais difícil gerenciar balanceamento de carga e tolerância a falhas, mas é uma solução simples. O uso de sessões, que são pegajosas, torna isso explícito e fornece um nível de exposição que os clientes podem argumentar.
Às vezes, o cliente implementa leituras e gravações monotônicas. Ao adicionar versões em gravações, o cliente descarta leituras de valores com versões anteriores à última versão.
As partições ocorrem quando alguns nós do sistema não conseguem alcançar outros nós, mas ambos os conjuntos são alcançáveis por grupos de clientes. Se você usar uma abordagem de quorum de maioria clássica, a partição que tem nós W do conjunto de réplicas pode continuar a receber atualizações enquanto a outra partição fica indisponível. O mesmo é verdadeiro para o conjunto de leitura. Dado que esses dois conjuntos se sobrepõem, por definição, o conjunto de minorias torna-se indisponível. As partições não ocorrem com freqüência, mas ocorrem entre os data centers, bem como dentro dos data centers.
Em algumas aplicações, a indisponibilidade de qualquer uma das partições é inaceitável, e é importante que os clientes que possam alcançar essa partição façam progresso. Nesse caso, ambos os lados atribuem um novo conjunto de nós de armazenamento para receber os dados, e uma operação de mesclagem é executada quando a partição cura. Por exemplo, dentro da Amazon, o carrinho usa esse sistema de escrita sempre; No caso da partição, um cliente pode continuar a colocar itens no carrinho, mesmo que o carrinho original funcione nas outras partições. O aplicativo de carrinho ajuda o sistema de armazenamento a unir os carros após a cicatrização da partição.
Um sistema que trouxe todas essas propriedades sob o controle explícito da arquitetura do aplicativo é o Dynamo da Amazon, um sistema de armazenamento de valor-chave que é usado internamente em muitos serviços que compõem a plataforma de comércio eletrônico da Amazon, bem como os Serviços da Web da Amazon. Um dos objetivos de design do Dynamo é permitir que o proprietário do serviço de aplicativos que crie uma instância do sistema de armazenamento do Dynamo e mdash, que normalmente abrange vários centros de dados e mdash; para fazer os trade-offs entre consistência, durabilidade, disponibilidade e desempenho a um determinado custo ponto. 3.
A inconsistência de dados em sistemas distribuídos confiáveis de grande escala deve ser tolerada por dois motivos: melhorar o desempenho de leitura e gravação em condições altamente concorrentes; e manipulação de casos de partição onde um modelo maioritário tornaria parte do sistema indisponível, embora os nós estejam funcionando.
Se as inconsistências são ou não aceitáveis depende da aplicação do cliente. Em todos os casos, o desenvolvedor precisa estar ciente de que as garantias de consistência são fornecidas pelos sistemas de armazenamento e precisam ser levadas em consideração ao desenvolver aplicativos. Há uma série de melhorias práticas para o eventual modelo de consistência, como a consistência do nível da sessão e as leituras monotônicas, que oferecem melhores ferramentas para o desenvolvedor. Muitas vezes o aplicativo é capaz de lidar com as eventuais garantias de consistência do sistema de armazenamento sem nenhum problema. Um caso popular específico é um site na qual podemos ter a noção de consistência percebida pelo usuário. Nesse cenário, a janela de inconsistência precisa ser menor que o tempo esperado para o cliente retornar para a próxima carga da página. Isso permite que as atualizações se propagem através do sistema antes que a próxima leitura seja esperada.
O objetivo deste artigo é aumentar a conscientização sobre a complexidade dos sistemas de engenharia que precisam operar em uma escala global e que exigem um ajuste cuidadoso para garantir que eles possam oferecer a durabilidade, disponibilidade e desempenho que suas aplicações exigem. Uma das ferramentas que o designer do sistema possui é o comprimento da janela de consistência, durante a qual os clientes dos sistemas são possivelmente expostos às realidades da engenharia de sistemas em larga escala.
Referências Brewer, E. A. 2000. Rumo a sistemas distribuídos robustos (resumo). Em Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (16-19 de julho, Portland, Oregon): 7 Uma conversa com Bruce Lindsay. 2004. ACM Queue 2 (8): 22-33. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., Vogels, W. 2007. Dínamo: o Amazon é altamente loja de valor-chave disponível. Em Procedimentos do 21º Simpósio ACM sobre Princípios de Sistemas Operacionais (Stevenson, Washington, outubro). Gilbert, S., Lynch, N. 2002. A conjectura de Brewer e a viabilidade de serviços Web consistentes, disponíveis e com tolerância a partições. Notícias do ACM SIGACT 33 (2). Lindsay, B. G., Selinger, P. G., et al. 1980. Notas sobre bancos de dados distribuídos. Em Bases de Dados Distribuídos, ed. EU . W. Draffan e F. Poole, 247-284. Cambridge: Cambridge University Press. Também disponível como IBM Research Report RJ2517, San Jose, Califórnia (julho de 1979).
Modelando o desempenho do sistema de negociação.
Decidir o tamanho da posição para o próximo comércio é um processo de duas perguntas:
O sistema está funcionando ou está quebrado? Qual é o tamanho da posição que maximiza o crescimento da conta, minimizando a probabilidade de sofrer uma perda séria?
O livro discute técnicas para modelar e analisar o desempenho do sistema comercial.
O Modeling Trading System Performance é uma sequela do meu livro anterior, Quantitative Trading Systems. O foco deste livro é sobre os aspectos práticos da negociação como um negócio. Os principais tópicos incluem:
Análise dos resultados da negociação, como expectativa, freqüência de negociação, período de retenção, índice de ganhos / perdas. Uso da simulação de Monte Carlo. Estimativa do potencial de lucro e redução. Como aplicar o dimensionamento da posição. Como saber se o sistema está funcionando ou está quebrado. Estatísticas para comerciantes.
A maioria do material no Modeling Trading System Performance é novo, tanto em termos de livros publicados pela Blue Owl Press quanto em outros materiais publicados.
Vários sistemas de negociação são analisados em detalhes. Tudo é completamente explicado, incluindo o uso de ferramentas gratuitas ou de baixo custo que lhe permitirão realizar análises semelhantes dos seus próprios sistemas de negociação. Além do Microsoft Excel, o livro é independente da plataforma. É igualmente aplicável às pessoas que usam TradeStation, MetaStock, AmiBroker, Wealth-Lab ou qualquer outra plataforma de desenvolvimento de sistemas comerciais.
Várias sabedoria comum, método tradicional e idéias e recomendações de vacas sagradas são examinadas em detalhes, com resultados que mostram que muitos deles são conselhos precários. Todas as ferramentas utilizadas são totalmente explicadas para que você possa repetir os testes usando seus próprios sistemas e dados.
Esses links abrem um arquivo pdf relacionado ao livro.
Existe apenas um programa para download para este livro. O botão abaixo baixa o programa Excel que executa os cálculos. O nome do arquivo baixado é MTSPSimulation. xla. txt. Remova o extra. txt do nome do arquivo e instale-o como um complemento do Excel.
O livro fornece instruções detalhadas para a instalação e uso deste complemento.
Graças a um dos nossos leitores que indicaram que os usuários do Excel 2018 e mais tarde precisam executar um passo extra ao carregar o suplemento. Esta página da Microsoft explica:
Você pode aprender mais sobre o livro, ler páginas adicionais, ler comentários e comprar uma cópia & # 8212; tudo na Amazon.
Por que a Amazon está comendo o mundo.
Códigos de acesso para as portas do cockpit United acidentalmente postadas on-line.
Zack Kanter é o co-fundador da Stedi.
Eu co-fundou uma inicialização de software em dezembro. Todos os meses, envie uma atualização aos nossos investidores para mantê-los atualizados sobre o nosso progresso. Mas o mês passado foi um pouco diferente - nossa indústria (varejo) está passando por uma transformação.
Em vez de simplesmente escrever sobre nossas notícias "internas", escrevi sobre o apocalipse iminente no mundo mais amplo do varejo. Mais especificamente, incluí alguns pensamentos sobre a Amazon e por que o seu comando de liderança só vai aumentar. A Amazon é a empresa mais impressionante da Terra, e acho que é uma das menos compreendidas. Algumas pessoas sugeriram que publicasse isso publicamente, então aqui vai.
A minha primeira empresa, um fabricante de peças de automóveis, vendido para a Amazon tanto como fornecedor (onde a Amazon emite ordens de compra para o produto a granel) e como "vendedor do mercado" (onde a Amazon tira um corte de produtos de vendedores de terceiros vendidos na Amazon ) - então eu tenho uma visão das operações internas da Amazon e iniciativas que muitas vezes não são discutidas publicamente.
Segui as outras várias ofertas da AWS e da Amazon por algum tempo, e a Amazon, como empresa, tornou-se uma obsessão pessoal minha. Tenho alguns pensamentos sobre a Amazônia e o iminente apocalipse de varejo que eu queria compartilhar para aqueles que estão interessados no futuro geral do varejo.
Consenso é que atingimos um ponto de inflexão e o setor de varejo está finalmente vendo alguns danos colaterais importantes do crescimento de monstro da Amazon - e as notícias mainstream / non-tech começaram a dar muito cobertura. Há muita discussão sobre se a vantagem da Amazon é sustentável ou se outros varejistas (ou seja, o Walmart) serão capazes de mitigar o domínio da Amazônia à medida que eles começam a replicar o modelo da Amazon.
A maioria das análises que eu li enfatizam as amplas vantagens da Amazon - o que chamarei de "fosso de ponto bala" - e depois avaliarei se cada programa é replicável por um varejista concorrente como o Walmart. Os programas são bem conhecidos pela maioria no mundo tecnológico; Os exemplos incluem Amazon Prime entrega de 2 dias (ou 1 hora), Amazon Marketplace (onde os vendedores de terceiros podem vender itens junto com a própria listagem da Amazon), as lojas Amazon Go (sites físicos, locais livres de caixa e o programa de drones da Amazônia).
A verdade é que cada um destes é viável para um grande concorrente replicar e é razoável pensar que o Walmart poderia construir ou adquirir esses recursos nos próximos anos. O componente-chave para entrega rentável de 2 dias (ou 1 hora) é a proximidade do cliente para um centro de distribuição. O Walmart já tem mais de 150 centros de distribuição - muito mais imagens quadradas agregadas do que os centros de atendimento da Amazon - embora estejam otimizados para reabastecer suas lojas (11.500!) Através da rede Walmart de (6.000 !! +) caminhões.
O Walmart tem uma capacidade comprovada para construir capacidade de distribuição e eles devem ser capazes de gerenciar a reconfiguração de sua rede para o preenchimento do comércio eletrônico sem muita dificuldade. E enquanto a Amazon está construindo toda a gama de soluções críticas de entrega da última milha (drones, robôs de entrega e uma rede de entrega humana sob demanda chamada Amazon Flex), existem muitas startups "de terceiros" em cada uma dessas áreas que poderia fornecer ao Walmart um grau razoável de paridade.
Tudo isso disse, acredito que a Amazon é a empresa mais defensável da Terra e nem começamos a entender a dimensão do seu domínio sobre os concorrentes. A liderança da Amazônia só crescerá na próxima década, e não acho que haja muito que qualquer outro varejista possa fazer para detê-la.
O motivo não é o ponto de bala que é falado nas manchetes, e não é a cultura da inovação ou a visão de Bezos como CEO (embora eu pense que a cultura da Amazon é incrível e Bezos é o CEO mais impressionante lá fora) . É o fato de que cada peça de Amazon está sendo construída com uma arquitetura orientada a serviços, e a Amazon está usando essa arquitetura para transformar sucessivamente cada peça da empresa em uma plataforma separada - e assim abrir cada peça para competição externa.
Lembro-me de ler sobre as armadilhas comuns de empresas verticalmente integradas quando estava na escola. Embora geralmente haja uma economia de custos convincente a partir da integração vertical (seja através de serviços de insenção ou aquisição de fornecedores / clientes), as margens aumentadas geralmente se evaporam ao longo do tempo, pois o "fornecedor" fica complacente com um "cliente" cativo e interno.
Existem grandes exemplos disso na indústria automotiva, onde as montadoras passaram por períodos alternados de aquisições de fornecedores e alienações subseqüentes à medida que os custos dos componentes subiram rapidamente. As divisões engordam e são ineficientes sem concorrência externa. As tentativas de mitigar isso através de comparação de lances competitiva / externa, contabilidades de custos e cotas detalhadas geralmente levam ao aumento da burocracia com pouco efeito na estrutura de custos real.
O exemplo mais óbvio da estrutura da SOA da Amazon é o Amazon Web Services (Steve Yegge escreveu um grande discurso sobre os começos desta volta em 2018). Devido ao momento da expansão incomparável da Amazon - hipertensão no início dos anos 2000, antes que SaaS de classe empresarial estivesse amplamente disponível - a Amazon precisava construir sua própria infra-estrutura tecnológica. O gênio financeiro de transformar essa infraestrutura em um produto externo (AWS) foi bem coberto - os ganhos foram tremendos, com a melhora de uma taxa anual de US $ 14 bilhões. Mas a bonança de receita é uma nota de rodapé em comparação com a visão organizacional negligenciada que a Amazon descobriu: ao criar uma peça operacional da empresa como uma plataforma, eles poderiam provar o futuro contra a ineficiência e a estagnação tecnológica.
(Foto de Drew Angerer / Getty Images)
Nos 10+ anos desde a estréia da AWS, a Amazon vem reconstruindo sistematicamente cada uma de suas ferramentas internas como um serviço de consumo externo. Um exemplo recente é o Amazon Connect da AWS - uma plataforma de centro de contato baseada em nuvem baseada em sítio que é baseada na mesma tecnologia usada nos próprios centros de atendimento da Amazon. Novamente, a "receita extra" aqui é ótima - mas o valor real é aprimorar as ferramentas internas da Amazon.
Se a Amazon Connect for uma falha comercial completa, a administração da Amazon terá um indicador quantificável (receita ou falta) que sugere que suas ferramentas internas estão significativamente atrasadas na competição. A Amazon substituiu a burocracia inútil e intensiva em tempo, como pesquisas internas e auditorias com um loop de feedback que gera dinheiro quando funciona - e rapidamente identifica problemas quando não. Eles dizem que o dinheiro ganho é uma aproximação razoável do valor que você está criando para o mundo, e a Amazon descobriu uma maneira de medir seu próprio valor em dezenas de áreas anteriormente invisíveis.
Mas isso é óbvio - todos sabemos sobre AWS. O incrível aqui é que esta estratégia - em uma das mais histéricas demonstrações de esforço na história da corporação moderna - permeou a Amazônia em todos os níveis. A Amazon lançou silenciosamente o acesso externo em recantos e recantos em todo o ecossistema, e essa é a longa cauda da disponibilidade de serviços externos que penso que será quase impossível replicar.
O exemplo mais amplo é o programa Fulfillment By Amazon (FBA). Se você já encomendou um produto da Amazon que diz "Vendido e cumprido pela Amazon", você viu a FBA em ação.
Com a FBA, a Amazon permite que os vendedores terceirizados enviem estoque em massa para a Amazon - A Amazon armazena esse inventário (que o vendedor ainda possui) no centro de atendimento da Amazon, envia o produto para o cliente Amazon quando a ordem é colocada e até mesmo lida com todos os retornos e atendimento ao cliente. As taxas são incrivelmente competitivas. E a FBA não se limita aos itens vendidos na Amazon - os vendedores também podem usar a opção "Cumprimento multicanal" da Amazon para enviar pedidos não-Amazon aos clientes do vendedor. Um exemplo disto seria se a Hydro Flask operasse sua própria loja separada de comércio eletrônico no Shopify - quando um cliente faz um pedido na loja Shopify, a Hydro Flask pode enviar a ordem para o FBA (você adivinhou - por meio de uma API externa) e FBA will ship it directly to the customer.
The benefit for Hydro Flask is obvious. They can have the product manufactured in China, and use a freight forwarder like Flexport to ship the product directly from the factory to Amazon’s warehouse — and thus avoid the headache (and overhead) of operating their own warehouse. For Amazon, the surface benefits are numerous: a) better utilization of excess capacity, b) increased shipping volume / leverage with UPS/FedEx, and c) revenue from the fulfillment services (which, combined with Marketplace commissions and “other third-party seller services,” totaled a whopping $6.4 billion in Q1 2017 — or 25 percent of Amazon’s total revenue).
But again, the enduring benefit here is the improvement that comes from opening up Amazon’s internal fulfillment operation to outside users. Fulfillment and shipping is Amazon’s largest cost center and, with a huge human component, it is the one that is most susceptible to bloat.
The level of discipline required to operate a multi-tenant, externally facing service like FBA yields tremendous benefit to the Amazon’s internal operation — this isn’t some hacked-together, homegrown tool that is hard-coded to Amazon’s own needs and thus nearly impossible to improve.
xIt is a relatively clean, abstracted, service-based interface that is “owned” by a separate team — a team with responsibilities to external customers. Bezos has imbued a sense of customer worship within Amazon (“Earth’s most customer-centric company”), and Amazon has three distinct group of customers to worship: e-commerce shoppers (Amazon), developers (AWS) and sellers (Amazon Marketplace/FBA).
As a side note, I think FBA will be extraordinarily difficult for another retailer to replicate. The technological and organizational complexity of commingling inventory from literally hundreds of thousands of sellers is mind-boggling — particularly when you factor in the permutations that result from different settings toggled on a seller-by-seller basis.
Their automated system for routing and splitting of inbound shipments to optimal fulfillment centers (based on capacity, historical geographic distribution of customers and who knows what else) is a nontrivial task in and of itself. Amazon has been at this for 10+ years (FBA was launched in 2006), and I think the investment in FBA is a substantial part of the reason for their failure to make a profit (or, really, their choice to not make a profit) for the large part of the last decade.
The error rate had to be tremendous to start — I personally know of several sellers who have been reimbursed for tens of thousands of dollars in inventory that Amazon lost, no questions asked. Setting aside the massive technical challenges, what other retailer has the stomach to sustain such incredible losses in a program for so many years?
It seems obvious to me that Amazon will move into small-parcel shipping (UPS/FedEx/USPS) within the next five years. They are thumbing through their income statement and picking off the largest categories to “productize” — first technology (AWS), then fulfillment (FBA), then COGS (the actual products themselves via Amazon’s various private label programs), and next shipping. They’ve already started operating their own fleet of 40 cargo planes and thousands of tractor-trailers. They’ve built out dozens of parcel-sorting centers to reduce the fees they pay to existing small parcel carriers. And it’s a natural fit for their services model — they have tremendous internal demand and their existing services customers are perfect early adopters.
The key advantage that Amazon has over any other enterprise service provider — from UPS and FedEx to Rackspace — is that they are forced to use their own services. UPS is a step removed from backlash due to lost/destroyed packages, shipping delays, terrible software and poor holiday capacity planning. Angry customers blame the retailer, and the retailer screams at UPS in turn. When Amazon is the service provider, they’re permanently dogfooding. There is nowhere for poor performance to hide. Amazon has built a feedback loop as a moat, and it is incredible to watch the flywheel start to pick up speed.
Amazon has committed to this idea at a granular level. Even when it comes to services that can’t be sold, Amazon is still making a push to expose the services externally. The perfect example of this is Amazon’s Marketplace Web Service (MWS) API — this is the set of services that Amazon Marketplace sellers can use to programmatically exchange data with Amazon. Amazon built out a service that they call the “Subscriptions API,” which gives the seller instant notification of any price change by any competitor — including Amazon itself!
Amazon is externally exposing the tools it uses to set its own prices in order to guarantee that the price listed on Amazon is as low as possible for the customer. This has spawned a whole ecosystem of third-party price-optimization tools called “repricers,” which use the MWS API to automatically respond to price changes in order to maximize sales for the Marketplace seller (the WSJ published a great piece on this back in March, aptly likening it to high-frequency trading). The beauty here is that Amazon doesn’t care if a seller undercuts Amazon’s price — Amazon takes a 12-15 percent commission on the sale regardless, and then collects FBA fees to boot.
I could go on and on with examples. I’m on the email list for updates from AWS, Amazon Marketplace, Amazon’s Vendor program and a handful of customer-facing programs — they are systemically productizing the entire company, honing what works, fixing what doesn’t and killing off everything else. All of this reminds me of a Bezos quote:
“I very frequently get the question: ‘What’s going to change in the next 10 years?’ And that is a very interesting question; it’s a very common one. I almost never get the question: ‘What’s not going to change in the next 10 years?’ And I submit to you that that second question is actually the more important of the two — because you can build a business strategy around the things that are stable in time. … [I]n our retail business, we know that customers want low prices, and I know that’s going to be true 10 years from now . They want fast delivery; they want vast selection. It’s impossible to imagine a future 10 years from now where a customer comes up and says, ‘Jeff I love Amazon; I just wish the prices were a little higher,’ [or] ‘I love Amazon; I just wish you’d deliver a little more slowly.’
Product assortment, low prices and fast delivery are the keys to Amazon winning the retail game. With Amazon Marketplace, sellers can list millions of the hottest new products far faster than Amazon’s Vendor team could ever hope to discover them. It has built out a high-frequency trading platform that guarantees price competitiveness — and delivers a guaranteed minimum 12 percent margin for Amazon. Fast delivery comes down to operational excellence and an exceptionally low cost of shipping, both of which are accomplished by opening FBA to external customers. I don’t think anyone understands The Innovator’s Dilemma better than Amazon, and they’ve implemented a systemic solution that will maintain an unbeatable advantage over competitive retailers.
So, my opinion is that Amazon is uncatchable. It took Amazon 10 years to perfect FBA. Even if Walmart could do it in 5, where will Amazon be by the time they roll it out? And I haven’t even begun to touch the surface of Amazon’s lesser-known, industry-shattering programs like Seller Fulfilled Prime and Direct Fulfillment. I’m not sure we’ll see a mass-market retailer compete successfully against Amazon within my lifetime — though I still think there is a substantial opportunity for vertical-specific retailers like Chewy to spin up and gain some ground in the short term.
Amazon will only be brought down by an anti-trust case (though that’s a long way off, given that they only have a small percentage of total retail volume today) or a paradigm shift in how we consume physical products — the scenario that comes to mind is widespread adoption of massively immersive VR combined with intravenous nutrition (Soylent in 20 years ) and universal basic income, which would obviate the need for physical products altogether. But that’s a ways off too.
Pesquisa.
As an industry, logistics is ripe for technology-driven disruption, and no company is better at leveraging technology to broaden margins than Amazon - logistics and delivery companies should be tracking these early days of Amazon‘s logistics play like hawks.
Freightos Resources.
What Shippers Want.
Freightos® is the world’s online marketplace for international shipping, powering over $1 billion in global trade every year. Freightos also provides Freightos AcceleRate™ software-as-a-service to automate pricing and routing for leading carriers, freight forwarders and shippers. Founded…
Freightos News.
Note: Zvi Schreiber is the CEO of Freightos, a logistics startup bringing international freight online for forwarders, shippers and oversized e-commerce.
Zvi’s recent article for TechCrunch, titled “Is Logistics About To Get Amazon’ed?” clearly indicates that logistics companies must keep pace with the technological innovation that Amazon is likely to deploy, and that Amazon Logistics Services may well emerge as a new platform in the next decade, unseating and disrupting existing freight leaders.
Zvi Schreiber: In November 2018, Beijing Century Joyo Courier Services registered with the U. S. government as an ocean shipping provider. E daí?
Well, Beijing Century Joyo Courier Services is a subsidiary of none other than Amazon. And earlier in the year, Amazon had already expanded its logistics presence with air transportation and trucking.
Amazon’s entry into the trillion-dollar freight industry can have huge impact on Amazon‘s international sellers, importers and end consumers. But within the context of Amazon‘s modus operandi, it may spell even broader change in one of the world’s largest industries.
Baird analyst Colin Sebastian, who has forecast for some time that Amazon will eventually offer Transportation & Logistics services to third parties, noted that Amazon called itself a “transportation service provider” for the first time in a regulatory filing and added this expense to its cost of sales.
“Cost of sales primarily consists of the purchase price of consumer products, digital media content costs where we record revenue gross, including Prime Video and Prime Music, packaging supplies, sortation and delivery centers and related equipment costs, and inbound and outbound shipping costs, including where we are the transportation service provider. Shipping costs to receive products from our suppliers are included in our inventory and recognized as cost of sales upon sale of products to our customers.”
The disclosure is not an entirely new revelation, just a confirmation of what was already being speculated about.
“We continue to expect Amazon to add logistics primarily to meet its own growth, but over time, and in incremental fashion, we believe it is likely that Amazon will offer this expertise to third parties to help subsidize those costs,” the analyst said.
The Rise of Amazon-as-a-Service.
In the past 20 years, Amazon‘s operating strategy has shifted from online retailer to B2B service provider, offering a stack of critical infrastructure as a service to other businesses.
“That’s a big part of what’s going on with Amazon Web Services, Fulfillment by Amazon, and Kindle Direct Publishing…We are creating powerful self-service platforms that allow thousands of people to boldly experiment and accomplish things that would otherwise be impossible or impractical.” Jeff Bezos, 2018 Annual Shareholder Letter.
Triggered by the drive to please customers or increase market share, Amazon‘s development process follows a clear structure:
Identify inefficiencies Develop a technological solution Scale the solution into a platform Offer the platform as a novel solution for third-party businesses.
For example, Amazon first created an efficient in-house computing cloud for their own IT, expanding it in-house before offering it to others in the form of Amazon Web Services. This same pattern has repeated in other sectors, including payments, e-commerce checkout and retail, as we’ll see below.
Crucially, competitors generally do not see the change coming. When the term “cloud computing” was first used in 1996, IBM and Microsoft certainly didn’t anticipate that their biggest competitor would be a bookstore!
Branching into X-as-a-Service in retail.
Amazon has steadily evolved its retail services over the past 20 years. In cases where operations were initially outsourced, Amazon developed in-house, technology-driven solutions. Once successful, these solutions were offered as an external service to third-party businesses.
In the online retail world, this process began with Amazon providing core e-commerce and packaging services, while wholesalers were responsible for sourcing books and warehousing them. Amazon team members would order books from wholesalers and stay up to 3 AM packing the books on the floor of Bezos’ garage. Delivery of the books would be outsourced to companies like UPS, as it still is today.
As the e-commerce platform improved, Amazon started offering it as a service to third-party vendors in 2000, resulting in the incredibly successful Amazon Marketplace. Today, more than two million third-party sellers account for 40 percent of Amazon’s sales.
Scale and improved technology repeated the pattern with more efficient warehousing, leading to the 2006 launch of Fulfillment By Amazon (FBA). Along the way, Amazon Payments was also launched as a service in 2007, although it has not been particularly successful. An additional service, an e-commerce shopping cart solution called Checkout for Amazon, was the next service to launch (2008), although it too never took off.
Expanding vertically across the supply chain.
After scaling into services, Amazon began broadening its position across the supply chain, beginning with consumer electronics.
This is one area where Amazon has seen its fair share of flops, including the Fire Phone and the Kindle Fire. While devices like the Kindle are effective as a content distribution strategy, product development has never reached the platform stage.
First foray into logistics.
In 2018, Amazon continued its expansion across the supply chain by focusing on logistics components that were previously outsourced - first inbound logistics and then, in 2018, home delivery.
More than $1 trillion is spent on international freight annually, powering a global fleet of ships, airplanes and trucks that move more than $19 trillion dollars worth of goods across borders every year. Huge ships that carry up to 18,000 shipping containers move 90 percent of everything consumers eat, use and wear (just check the label on your clothes or devices).
But the global freight industry is manual and inefficient. This is precisely the sweet spot for Amazon‘s approach of leveraging technology and scale to reduce costs. Amazon started by offering outsourced consolidation for international sellers in 2018, leveraging bulk discounts for cheaper U. S. import rates.
Delivery was an even more important nut to crack. The free shipping (and rapid Prime delivery) that delights Amazon customers cost more than $4.2 billion dollars in 2018 - nearly 5 percent of net sales. In addition, the lack of control over outsourced processes can also impact customer delight, like the courier shipping delays in the 2018 holiday season.
To reduce operating costs and dependencies on external providers, Amazon began to expand the role it played in delivery in 2018. In December 2018, The Seattle Times reported Amazon was in talks to lease an air fleet, while Amazon trucks started appearing on the road. For the first time, the iconic Amazon packages were delivered by Amazon employees, while Amazon also launched a crowdsourced delivery service.
While this is a brand new business for Amazon, no company is better at tech-driven efficiency. More than 30,000 robots at Amazon warehouses are a testament to how powerful automation can be in the supply chain. This same drive also explains Amazon’s parcel drone-delivery efforts.
The Non-Vessel Operating Common Carrier (NVOCC) play.
In this context, Amazon filing to function as a freight forwarder is as logical as it is bold. Amazon is entering a notoriously unautomated industry. Just getting pricing for freight quotes takes an average of more than 90 hours, and the industry is renowned for opaque pricing.
But Amazon‘s international revenue growth has stagnated, falling to a 12 percent growth in 2018 - modest in Amazon terms. Easier and cheaper shipping to Amazon sellers globally can revive growth, reduce Amazon’s own global shipping costs and provide more control over processes.
Implications for the logistics industry.
Amazon has made a habit of extending internal services into third-party services. If Amazon successfully reduces fulfillment and logistics costs in-house, it’s unlikely these services will remain limited to use within Amazon.
As an industry, logistics is ripe for technology-driven disruption. And no company is better at leveraging technology to broaden margins than Amazon. Logistics and delivery companies should be tracking these early days of Amazon‘s logistics play like hawks.
Unless the logistics companies can keep pace with the technological innovation that Amazon is likely to deploy, Amazon Logistics Services may emerge as a new platform in the next decade, unseating existing freight leaders.
While many business-to-business sales industries continue to expand sales online, the logistics industry has been slow to adopt online freight sales and booking, leaving ample space for ambitious forwarders to expand sales with new channels. Baixe Agora.
A roadmap for online freight services: Following suit from other industries, forward thinkers in the industry are already adopting online freight quotes and sales as a key differentiator, gaining an important competitive advantage in a crowded market space. Baixe Agora.
Você precisa estar logado para postar um comentário. Entrar.
24 | 7 Pro Team Picks.
24 | 7 Pro Team.
The 24|7 Team is your direct pipeline to solutions for your business challenges. It's your opportunity to have supply chain and logistics experts look at your specific challenges and needs, and give you free, no-obligation advice, solutions, and information.
The 24|7 Team will simplify the task of creating a database of likely partners, building your knowledge base, and preparing your Request for Proposal list.
Transportation RFP/RFI.
The Transportation RFP is your direct pipeline to solutions for your transportation challenges. It's your opportunity to have logistics experts look at your specific transportation challenges and needs, and give you free, no-obligation advice, solutions, and information specific to your request.
Choosing the perfect software or system can be an indomitable challenge. Using this transportation/TMS RFP will simplify the task of creating a database of likely partners, building your knowledge base, and preparing your Request for Proposal list.
Warehouse/DC Management RFP/RFI.
The Warehouse Management Systems (WMS) RFP is your direct pipeline to solutions for your WMS challenges. It's your opportunity to have logistics experts look at your specific WMS challenges and needs, and give you free, no-obligation advice, solutions, and information specific to your request.
Choosing the perfect WMS solution can be an indomitable challenge. Using this WMS RFP will simplify the task of creating a database of likely partners, building your knowledge base, and preparing your WMS Request for Proposal list.
Supply Chain RFP/RFI.
The Supply Chain RFP is your opportunity to have logistics experts look at your specific challenges and needs, and receive free, no-obligation advice, solutions, and information. It simplifies finding a pool of likely partners, building your knowledge base, and preparing your Request for Proposal list. The companies in the Logistics Planner have agreed to respond to your request for in-depth information and follow-up, and your request is totally confidential.
Software/Technology RFP/RFI.
The Software/Technology is your direct pipeline to solutions for your logistics information technology challenges. It's your opportunity to have logistics experts look at your specific technology challenges and needs, and give you free, no-obligation advice, solutions, and information specific to your request. Whether it's WMS, TMS, Mobile or Cloud, our pros can help.
The companies listed below have agreed to respond to your request for in-depth information and follow-up. Your request is totally confidential.
Executive Education RFI.
The Logistics and Supply Chain Education RFI can help you identify the schools, coursework, continuing education, distance learning and certification opportunities available from leading logistics educational institutions.
Upgrade and improve your logistics and supply chain skillsets. Whatever route you choose—advanced degree, executive education, certification or distance learning—the time and money you invest in your education today can pay off in continued career success tomorrow. Contact leading universities and professional institutions for the information you need to prepare for the future.
Third Party Logistics RFP/RFI.
This 3PL Request for Proposal (RFP)/Request for Information (RFI) can help you find the 3PL and 4PL providers that can meet your specific 3PL service challenges and needs. The 3PL companies below will provide free, no-obligation third-party logistics advice, solutions, and information.
Ask your 3PL questions, you'll get answers. Simply complete the information, and detail your 3PL challenges. Then, check off the third-party logistics companies that you want to review your request.
1. Choose an RFI topic.
2. Enter your contact information and challenge.
3. Select companies and optional categories.
24 | 7 Company Profiles.
3Gtms is the fastest growing, Tier-1 transportation management system (TMS) provider. It is dedicated to helping shippers and logistics service providers gain…
In Swisslog’s Americas region, we share a passion for designing, developing and delivering logistics automation systems and software that drive customer…
SMC³ is the one-stop knowledge hub for less than truckload technology, data and education. The API-powered…
In adhering to their “We´re Always There For You” signature commitment, PITT OHIO is dedicated to providing their customers with the best value in…
3PL Central is a leader among cloud-based supply chain software providers, offering warehouse management solutions that are robust, reliable, secure, cost-effective,…
We’re not just a provider, we’re your partner. At Frontier, we get to know your business and offer you tailored solutions designed to meet your demands and…
Amber Road provides a single, on-demand platform that automates and streamlines global trade. By helping organizations to comply with country-specific trade regulations,…
LEGACY Supply Chain Services is a third party logistics (3PL) provider. For over four decades, they’ve enhanced operations performance for businesses of…
24 | 7 Resources.
We’re not just a provider, we’re your partner. At Frontier, we get to know…
7 Ways Amazon Uses Big Data to Stalk You (AMZN)
Some customers may find it odd when a store knows a lot about them simply by the products they purchase. Amazon Inc. ( AMZN) is a leader in collecting, storing, processing and analyzing personal information from you and every other customer as a means of determining how customers are spending their money. The company uses predictive analytics for targeted marketing to increase customer satisfaction and build company loyalty. Although big data has helped Amazon evolve into a giant among online retail stores, what the company knows about you may feel a bit like stalking.
Personalized Recommendation System.
Amazon is a leader in using a comprehensive collaborative filtering engine (CFE). It analyzes what items you purchased previously, what is in your online shopping cart or on your wish list, which products you reviewed and rated, and what items you search for most. This information is used to recommend additional products that other customers purchased when buying those same items. For example, when you add a comedy DVD to your online shopping cart, similar movies purchased by other customers buying the same movie are also recommended for you to purchase. In this way, Amazon uses the power of suggestion to encourage you to buy on impulse as a means of further satisfying your shopping experience, and spending more money. This method increases the company’s revenue by up to 30% annually.
Book Recommendations From Kindle Highlighting.
After acquiring Goodreads in 2018, Amazon integrated the social networking service of approximately 25 million users into some Kindle functions. As a result, Kindle readers can highlight words and notes and share them with others as a means of discussing the book. Amazon regularly reviews words highlighted in your Kindle to determine what you are interested in learning about. The company may then send you additional e-book recommendations.
One-Click Ordering.
Because big data shows that you shop elsewhere unless your products are delivered quickly, Amazon created One-Click ordering. One-Click is a patented feature that is automatically enabled when you place your first order and enter a shipping address and payment method. When choosing One-Click ordering, you have 30 minutes in which you may change your mind about the purchase. After that, the product is automatically charged via your payment method and shipped to your address.
Anticipatory Shipping Model.
Amazon’s patented anticipatory shipping model uses big data for predicting what products you are likely to purchase, when you may buy them and where you might need the products. The items are sent to a local distribution center or warehouse so they will be ready for shipping once you order them. Amazon uses predictive analytics to increase its product sales and profit margins while decreasing its delivery time and overall expenses.
Supply Chain Optimization.
Because Amazon wants to fulfill your orders quickly, the company links with manufacturers and tracks their inventory. Amazon uses big data systems for choosing the warehouse closest to the vendor and/or you, the customer, to reduce shipping costs by 10 to 40%. Additionally, graph theory helps decide the best delivery schedule, route and product groupings to further reduce shipping expenses.
Price Optimization.
Big data is also used for managing Amazon’s prices to attract more customers and increase profits by an average of 25% annually. Prices are set according to your activity on the website, competitors’ pricing, product availability, item preferences, order history, expected profit margin and other factors. Product prices typically change every 10 minutes as big data is updated and analyzed. As a result, Amazon typically offers discounts on best-selling items and earns larger profits on less-popular items. For example, the cost of a novel on the New York Times best sellers list may be 25% less than the retail price, while a novel not on the list costs 10% more than the same book sold by a competitor.
Amazon Web Services.
Through Amazon Web Services, companies can create scalable big data applications and secure them without using hardware or maintaining infrastructure. Big data applications such as clickstream analytics, data warehousing, recommendation engines, fraud detection, event-driven ETL, and internet-of-things (IoT) processing are done through cloud-based computing. Companies may benefit from Amazon Web Services by analyzing customer demographics, spending habits and other pertinent information to more effectively cross-sell company products in ways similar to Amazon. In other words, these retailers can stalk you, as well.
