Geolocalização de clientes

Fase I - Estudo

Título da Ideia

Geolocalização de Clientes

Objetivos

Desenvolver uma PoC que, utilizando um consumer de um tópico Kafka, envie mensagens contendo chamadas, anúncios e promoções para clientes dentro de uma área referente à posição geográfica de determinada estação radio-base ,

Desenvolver uma PoC que, por meio de um sistema que lê mensagens de um tópico Kafka, envie chamadas, anúncios e promoções para clientes localizados na área de cobertura de uma determinada estação rádio-base.

Conceito

A pesquisa é impulsionada pela necessidade de comunicação eficiente e imediata com os clientes, especialmente em ambientes urbanos onde a concorrência é alta. Assim, insere-se no contexto macro do marketing digital, utilizando tecnologias móveis para alcançar os consumidores.

Há empresas que já utilizam tecnologias de geofencing (exemplo McDonalds [[1]] para identificar quando um cliente que pediu, por exemplo, pelo aplicativo, está chegando para retirar ou enviar promoções a clientes que estão nas proximidades de suas lojas.

Em um nível mais social, também estamos com um projeto semelhante envio de mensagens para pessoas de acordo com riscos climáticos em determinada localização Alerta Inteligente.

Podem existir horizontes para esse tema em automação de campanhas e até mesmo integrações com IA, que busquem maior assertividade, por exemplo, no público-alvo.

Características e Tecnologias 

Apache Kafka: Plataforma de streaming distribuído usada para construir pipelines de dados em tempo real, que envolve os componentes abaixo.

• Kafka Producer: Responsável por enviar mensagens para um tópico Kafka. As informações abrangem dados dos clientes conectados, como o número de telefone, e dados da torre em que o dispositivo está conectado, como o ponto de geolocalização.
• Kafka Topic: Um canal de comunicação onde as mensagens são publicadas pelo producer e consumidas pelo consumer.
• Kafka Consumer: O componente que consome as mensagens do tópico Kafka e as processa para posterior envio via SMS ou WhatsApp.

API de Mensagens (SMS/WhatsApp): Serviço para envio de mensagens (seja próprio ou terceiro).

Linguagem de Programação: Principalmente Python e outras que supram a necessidade de uma interface de registro das promoções.

Desafios:

• Gerenciamento de Volume de Dados: Lidar com grandes volumes de dados e garantir que o sistema continue performando bem sob alta carga.
• Conformidade com a LGPD na implementação pós PoC: Garantir que o sistema esteja em conformidade com as leis de proteção de dados, obtendo consentimento dos usuários e protegendo suas informações pessoais.

Estudo Dirigido

Características principais da tecnologia:

• Apache Kafka, plataforma de streaming distribuído usada para construir pipelines de dados em tempo real.
• API de Mensagens (SMS/WhatsApp): Serviço para envio de mensagens.

Para aprofundar a viabilidade do projeto, as seguintes atividades deverão ser conduzidas:

• Configuração de fluxos para controle do envio das promoções de forma automática.
• Avaliação das normas de LGPD, em relação ao consentimento dos clientes.
• Validação do código com a equipe de segurança da informação.

Fase II - Ensino

Conteúdo

Material da apresentação final inclui:

• Vídeo contextualizando sobre do caso de uso
• Vídeo explicando o código
• Vídeo demonstrando a aplicação rodando
• Vídeo da apresentação final
• https://www.canva.com/design/DAGp84_SLR8/uHX1kJw9ixG8KZ5Fyab7TQ/edit?ui=eyJIIjp7IkEiOnRydWV9fQ

Apresentação

O projeto foi apresentado dia 12/06/2025 para:

• Matheus Pereira dos Santos (Product Manager- Algar Telecom)
• Saymon Yury Costa Silva (Consultor em Tecnologia - Algar Telecom)

Metodologia

As abordagens utilizadas no projeto incluem:

• Estudos sobre Apache Kafka, Kafka Producer, Kafka Topic, Kafka Consumer.
• Construção de uma aplicação integrando os seguintes componentes:
  • Servidor KAFKA
  • APN
  • APIs de mensageria (WhatsApp e SMS)
  • Banco de dados com as promoções cadastradas

Hipóteses

Questões que envolvem a pesquisa:

• Necessária análise das normas LGPD.
• É necessária a validação do código com a equipe de segurança da informação.
• Necessária a configuração de fluxos para controle do envio das promoções é necessária para a construção real do produto.

O que se espera como resultado?

• Aumentar engajamento com ofertas contextuais.
• Criar experiências personalizadas baseadas em localização.
• Estabelecer vantagem competitiva no mercado.

Fase III - Exemplo de Caso de Negócio

Product Backlog

• Integração com tópico Kafka para consumir dados de geolocalização dos clientes em tempo real.

• Implementação de algoritmo para calcular distância entre ERBs e lojas emissoras de promoções.

• Interface para cadastro e gestão de promoções no banco de dados.

• Integração com APIs de mensageria (SMS e WhatsApp).

• Implementação de controles de fluxo para limitar volume de mensagens e garantir conformidade com a LGPD.

• Dashboards de monitoramento para acompanhar engajamento das campanhas.

• Documentação técnica e treinamento dos usuários.

Benefícios para quem for oferecer esta solução

• Geração de novas receitas através de campanhas direcionadas por localização.

• Maior efetividade nas campanhas de marketing, com maior ROI.

• Vantagem competitiva frente a concorrentes com comunicação mais personalizada.

• Criação de novos produtos e serviços baseados em geofencing.

• Fortalecimento da marca por proporcionar experiências relevantes aos clientes.

• Possibilidade de firmar novas parcerias com varejistas ou anunciantes.

Benefícios para o usuário

• Recebimento de ofertas e promoções mais relevantes e personalizadas.

• Melhor experiência de atendimento ao receber mensagens oportunas e contextualizadas.

• Maior engajamento e satisfação com a operadora/provedor.

• Redução de mensagens irrelevantes ou “spam”.

Direcionadores chave para esta iniciativa

• Crescente uso do mobile para consumo e comunicação.

• Maior exigência dos clientes por personalização.

• Oportunidade de monetização da infraestrutura já existente (dados e ERBs).

• Pressão competitiva do mercado para adoção de estratégias baseadas em dados.

Possíveis modelos de negócios

• Modelo B2B2C: venda do serviço para varejistas enviarem promoções a clientes.

• Inclusão como parte de um pacote premium para grandes clientes corporativos.

• Cobrança por campanha (pay-per-campaign) ou por volume de mensagens enviadas.

• Parcerias de revenue-sharing com anunciantes.

Pesquisa de Mercado e Análise de Tendências

• Mercado de mobile marketing cresce acima de 10% ao ano no Brasil.

• Tendência de hiperpersonalização de campanhas (behavioral + geolocation).

• Regulamentação cada vez mais exigente (LGPD e GDPR-like) reforça necessidade de soluções compliance-ready.

• Concorrência de Big Techs e OTTs com soluções próprias.

Análise de Concorrentes e Soluções Existentes

• Concorrentes: plataformas como Twilio, Sinch e Infobip já oferecem APIs com geofencing.

• Diferença: integração direta com a infraestrutura da rede (ERBs), sem depender apenas de dados GPS do cliente.

• Oportunidade: menor custo para os anunciantes e maior precisão na segmentação.

Público - Alvo

• Segmento B2B: redes varejistas, shoppings centers, supermercados, restaurantes de fast-food.

• Segmento B2C: clientes finais que já possuem relacionamento com a operadora/provedor.

• Características: consumidores urbanos, alta penetração de smartphone, sensíveis a promoções.

Cenários e Oportunidades

• Parceria com grandes varejistas para pilotos.

• Desenvolvimento interno da PoC para domínio completo da tecnologia.

• Possibilidade de terceirizar somente o envio das mensagens (API).

Premissas Financeiras

• Custos: desenvolvimento interno, infraestrutura Kafka, APIs de mensageria.

• Receitas: venda de campanhas para anunciantes ou mensalidades para uso da plataforma.

• Projeção inicial: break-even em até 12 meses com penetração de 5% no mercado-alvo.

• Ajustes: previsão de 3% de reajuste anual nos custos operacionais.

Riscos do Projeto

• Tecnológicos: alta latência na rede pode comprometer a eficácia.

• Financeiros: baixo volume inicial de adesão pelos clientes.

• Mercado: concorrentes podem antecipar soluções similares.

• Regulatórios: necessidade de adaptação à LGPD.

• Mitigação: PoC para testes em pequena escala, validação legal contínua, arquitetura escalável.

Business Case

• Apresentação:
  • https://www.canva.com/design/DAGpayy9hzc/0aryG3PwO05RSyOZtM1zaw/edit?utm_content=DAGpayy9hzc&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton

Alinhamento com Lei do Bem

• Projeto possui algum elemento tecnologicamente novo ou inovador?

Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada

• Projeto possui barreira ou desafio tecnológico superável?

Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese

• Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?

Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto

• Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?

Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa? 
Anexar cópia do contrato

Fase IV - Protótipo orientado ao Negócio

Escopo

Explique o escopo deste protótipo

Limitações

Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.

PoC

Desenvolva um PoC (Proof of Concept)

Privacidade (LGPD)

• Avaliar condições referentes à Lei Geral de Proteção de Dados

Detalhamento Técnico

Descreva especificamente os aspectos técnicos desta pesquisa

Histórico

Responsável: Luigi Negrini

Obtenção de acessos e liberação de firewall

• Desde 31/10/2024 estamos em processos de obtenção de acesso ao ambiente de homologação. Mesmo que outras atividades/estudos tenham sido feitos, a pesquisa fica travada nesse ponto.
• Em 05/11/2024 foi obtido o primeiro acesso pela blazon (LINUX STREAM-MONIOT-HML), entretanto foi identificado que é necessário um chamado de liberação no firewall pelo Jira SGD (SRV-1009021).
• No dia 17/11/24, houve sucesso na liberação do firewall, mas não consigo acessar o servidor de homologação via Telnet.
• Entre 19/11/24 e 21/11/24 (SRV-1010895), foi validado que ocorre um reset ao chegar no IP destino e, então a tratativa deve ser dada diretamente com o administrador da aplicação. Estou em tentativa de contato com Geovanne para obter um direcionamento.
• 10/12/24 acabamos de identificar com Weglison que os IPs que solicitamos acesso pelos chamados anteriores não são especificamente para o ambiente de homologação. Foi solicitada nova regra de firewall (SRV-1018467)
• 12/12/24 a regra foi atendida e houve o mesmo problema de possivelmente a aplicação barrar a conexão. Conversando com Weglison, foi entendido que a aplicação não barra a conexão, entretanto para identificar os possíveis problemas é necessário um troubleshooting juntamente com o criador da regra de firewall. O troubleshooting se deu hoje (18/12/24) pela manhã. O próximo direcionamento é conversar com o pessoal de rede e fazer novos testes tentando acessar a aplicação já com um consumidor.py do tópico kafka.
• 27/12/24 consegui consumir o tópico do teste enviado pelo Weglison. Não foi possível consumir o tópico almejado (ACCOUNTING_ENRICHED_STREAM) por erro de código (função decode), mas foi possível conectar!
• 06/01/25 foi informado que haveria um ajuste por parte do Weglison no tópico do Kafka.
• 08/01/25 ajuste no tópico foi concluído.

Desenvolvimento

• 13/01/25 resolvido o problema com a função decode. A obtenção dos dados via código foi realizada de forma completa.
• 14/01/25 desenvolvimento com algoritmo que identifica a distância entre a loja que quer emitir uma promoção e a torre de transmissão a qual estão conectados os dispositivos dos clientes.
• 15/01/25 reunião sobre LGPD (Cell Broadcast, com impacto direto no Geolocalização) - conclusão é que a nível de Poc não há impacto, mas para uma implementação comercial, requer discussão mais detalhada.
• 22/01/25 reunião com Ericson (Cell Broadcast) para conversar sobre a solução com CDRs para obtenção de geolocalização de clientes. E houve a obtenção do mapa de distribuição de ERBs.
• 28/01/25 feita a integração da interface/banco ao consumidor kafka.
• 29/01/25 reunião com Adriano Graziosi e time de SMS para entendermos como funciona o envio de SMS.
• 13/02/25 foram realizados testes de envio SMS no ambiente de homologação, mas não houve sucesso no recebimento do SMS.
• 17/02/25 reunião para entendimento do uso da API para envio de mensagem via WhatsApp.
• 21/02/25 houve a conclusão de que, exclusivamente para os testes desse tema, poderá ser usado o ambiente de produção. Foi solicitada a liberação para o uso do ambiente de produção para envio de SMS.
• 06/03/25 A solicitação foi atendida, os testes foram realizados, mas houve um erro que foi consertado no dia seguinte. Ainda no dia 06, foram recebidos os retornos da reunião do dia 17/02 para realização dos testes para envio via WhatsApp, obtivemos sucesso!
• 07/03/25 Reunião de debug com Israel e sucesso no envio de SMS!
• 11/03/25 Reunião com Cesar Augusto, Weglison e Geovanne para alinhamento sobre obtenção de dados de telefones via tópico kafka de homologação. Para realizar esse desenvolvimento, é preciso configurar uma APN nos dispositivos (inicialmente, Luigi, Paula, Luiz, Xandão e Ivan).
• 13/03/25 Enviado formalmente o e-mail para o Cesar solicitando a configuração da APN. O delay entre o dia 11 e 13 foi decorrente da confirmação de inclusão ou não do número da Eliane nesses testes iniciais; foi entendido que o mesmo entrará apenas para a apresentação contendo a demonstração final.

Pesquisadores

• Luigi Negrini
• Paula Nunes