Carol Billing

Esta documentação possui o objetivo de apresentar o processo de billing da Carol dando destaque aos recursos que compõem o billing e o custo associado.

Detalhamento dos Recursos do Billing

O billing apresenta o custo das tenants pertencentes ao Billing Account classificando o uso e custo por recursos. Desta forma, os gestores financeiros das tenants podem entender como os projetos e tenants estão consumindo os recursos na plataforma Carol e orientar os times em ações de eficiência de custos.

Este é um exemplo como o custo de uma Billing Account é classificado através dos recursos:

Esses são os possíveis recursos disponíveis na plataforma Carol:

Importante

A partir de dezembro de 2025, a Basic Fee da Plataforma Carol passou a ser dividida em novos componentes para dar mais transparência sobre quais custos compõem o valor e por que ele varia. O novo modelo inclui uma taxa dinâmica, calculada de acordo com o uso do projeto, sem valor mínimo fixo. Para viabilizar esse formato, foram implementados novos recursos de bilhetagem na plataforma.

• Taxa básica dinâmica: A taxa básica passa a ser calculada de forma dinâmica, considerando um conjunto de recursos compartilhados. O rateio ocorre com base no total de segundos em que cada tenant invoca recursos da Plataforma Carol.

• Suporte: O custo de suporte é dividido com base nos modelos de suporte da Google e no consumo de recursos GCP:

  • Suporte do projeto GCP: o custo é calculado conforme o volume de consumo de recursos GCP da tenant.
  • Suporte do projeto MDM Production: o custo é rateado entre os tenants que utilizam a Plataforma Carol, conforme o volume de consumo de recursos GCP.
  • Corporate GCP Support: o custo é rateado entre os consumidores conforme o volume de consumo de recursos GCP.

• Internal Storage: recursos da Plataforma Carol para armazenamento de dados internos, usados por Tasks e pelos logs das Tasks. O custo é rateado com base na utilização das Tasks da Carol, considerando os recursos de armazenamento relacionados a PostgreSQL (PG) e Bigtable (BT).

• Internal Cache: recursos da Carol para disponibilizar Named Queries com cache de forma otimizada.

• Ingestion: refere-se aos custos de mensageria, APIs e filas (Pub/Sub), vinculados aos recursos da Plataforma Carol necessários para permitir a ingestão de dados por meio dos processos de intake. O custo é rateado conforme o volume de ingestão de dados de cada tenant.

• Data Subscription: custo associado ao uso de Pub/Sub em projetos GCP específicos da tenant utilizados para Data Subscription. O custo é vinculado ao consumo desses recursos pela tenant.

• Cloud Storage: Custo associado aos recursos de armazenamento no Carol Data Storage. Este custo considera os SKUs Class A, Class B e Storage do Google Cloud Storage. Este recurso é medido em quantidade de GB (referente ao SKU de storage). Custo compreende o serviço Google Cloud Storage com todos os SKUs. Região padrão GCP: us-central1. Ação geradora do custo: Dados na staging area (dados de backup). Custo GCP: LINK

• Compute Engine Network: Custo associado à saída/entrada de rede na nuvem da Google. Este recurso é medido em quantidade de GB. Ação geradora do custo: custo de network pela comunicação com instâncias GCP.

• BigQuery: Custo associado ao armazenamento no BigQuery. Dados não alterados após 90 dias são automaticamente classificados para cobrança 50% mais barata, conforme a tabela de preços da Google. O valor inclui todos os SKUs do serviço BigQuery, incluindo a ingestão de dados em tempo real. Ação geradora do custo: armazenamento de dados Staging Area e Data Models. Custo GCP: LINK

• Realtime Storage: A partir de dezembro de 2025, a cobrança do Realtime Storage passou a ser dinâmica, baseada no custo real da plataforma para manter esse recurso. O custo contempla o Elasticsearch, o armazenamento de dados de configuração da Plataforma Carol e os Data Models com Realtime ativado. Esses custos são rateados entre as tenants que utilizam o recurso. Antes, era aplicado um valor fixo. No momento da mudança, os custos não irão flutuar; à medida que forem implementadas otimizações relacionadas ao Elasticsearch e aos demais componentes do Realtime, as reduções de custo serão refletidas diretamente no billing.

• Networking: O custo de networking incide especificamente sobre Carol Apps e é rateado com base no consumo de cada tenant, considerando o total de segundos de uso das instâncias de Carol Apps, incluindo tráfego e egress.

• Compute Time: Este custo está associado à execução de Carol App em modo Batch e Online. O custo é classificado de acordo com o tamanho da instância alocada para executar o Carol App. Os tipos de instâncias possíveis são: c1.nano, c1.micro, c1.small, c1.medium, c1.large, c1.xlarge, c1.2xlarge, g1.v100.large, g1.v100.xlarge. Detalhes sobre os tipos de instâncias podem ser obtidos neste link: https://docs.carol.ai/docs/carol-app/carol-app-instance-type. Este recurso é medido em quantidade de horas. Ação geradora do custo: Execução de Carol App de acordo com a instância do POD.

• Slots Compartilhados: Custo associado aos Slots do BigQuery. Os slots são unidades computacionais usadas para processar queries no BigQuery. O rateio do custo ocorre conforme o total de segundos de uso de slots por cada tenant. Este recurso é utilizado para o processamento de dados e o treinamento de modelos de machine learning utilizando o recurso BQ ML. O custo do Slot é gerenciado pela Plataforma Carol para compartilhamento entre projetos, valores GCP apenas para referência. Ação geradora do custo: Consulta de dados na Plataforma Carol e processamento de dados SQL Processing. Custo GCP: LINK

• Slots On-Demand: Têm a mesma finalidade dos Slots Compartilhados; neste caso, porém, são atribuídos diretamente à tenant em questão, com um custo mais elevado. Nessa configuração, utilizamos Slots Standard (https://cloud.google.com/bigquery/docs/slots), que apresentam um custo reduzido. Os Slots On-Demand são cobrados pela Google conforme as seguintes regras:

  • Alocação mínima de slots por 60 segundos: mesmo que a query executada dure apenas alguns segundos, os slots alocados serão cobrados por um período mínimo de 60 segundos.

  • Alocação mínima de slots determinada pela complexidade da query e pela quantidade de dados nas tabelas: a atribuição dos slots ocorre de forma dinâmica pela Google e impacta diretamente no custo do projeto.

  • Realizamos a alocação máxima de slots para evitar custos inesperados e não planejados.

    Mais detalhes sobre Slots podem ser encontrados aqui.

    Custo GCP: LINK

• Recurso de Baixa Latência (Baseado em AlloyDB):

  Nota : Até o final de 2026, os custos deste recurso para fins experimentais e PoCs serão subsidiados, sendo apresentados no billing com um crédito equivalente que anula a cobrança. A partir de 2027, o repasse de custos será efetivado para todas as áreas (para ambientes produtivos os repasses já serão efetuados).

  • Composição e Categorias: O custo (que inclui infraestrutura, ingestão por rateio e repasse direto do GCP) aparecerá dividido nas seguintes categorias no seu billing:
    • Low Latency Storage: Refere-se ao armazenamento de dados no Baixa Latência (em GB).
    • Low Latency Computation: Refere-se à infraestrutura e computação necessárias para processar queries e executar as pipelines de baixa latência.
    • Low Latency Ingestion: Refere-se aos custos relacionados à infraestrutura para receber e armazenar os dados.
    • Low Latency Infrastructure: Refere-se aos custos relacionados à infraestrutura base do Baixa Latência.
    • Low Latency CREDIT: Linha correspondente ao crédito gerado para anular os custos durante o período de isenção para PoCs e experimentos.

• Recurso Spark: Uso e execução de pipelines em Spark diretamente pela interface da Plataforma IDeIA (pipelines de processamento de dados e pipelines de qualidade de dados).

  • Recursos Tarifados: A utilização do Spark será contabilizada e cobrada no seu projeto através dos seguintes recursos listados no billing:
    • Ideia GCS Backup: Recurso utilizado para representar custos de backup após a eliminação de dados do GCS. O custo está vinculado à quantidade de GB armazenados em backup (por 30 dias).
    • REFI_SPARK_SQL_WEBSOCKET: Custo vinculado aos recursos de execução interativa das pipelines Spark. O custo está vinculado ao tempo de uso do recurso.
    • REFI_SPARK_SQL_PIPELINE: Correspondente ao módulo utilizado para processamento de dados.

• Google Maps: Este recurso é específico para Carol Apps integrando com o recurso Google Maps. A quantidade deste recurso é definida pela quantidade de requisições. Ação geradora do custo: Carol App integrado com Google Maps.

• Sentry: Este recurso é específico para o produto Clock-In e é direcionado apenas para tenants com o Clock-In instalado. O valor total do Sentry é rateado entre todas as tenants que utilizam o produto Clock-In. Solução para monitoramento e debug do produto Clock-In. Ação geradora do custo: Apenas para projetos Clock-In.

• Cloud Dataflow Batch: Este recurso define a quantidade de horas utilizadas para o processamento de dados, podendo ser a consolidação de dados no Carol Data Storage ou o processamento de dados através do SQL Processing. A quantidade é medida em horas de uso do recurso. Ação geradora do custo: horas utilizadas para popular um Data Model ou consolidar dados (CDS). Custo GCP: LINK

• Cloud Dataflow Streaming: Refere-se ao custo de processamento dos dados durante a ingestão. Este recurso define a quantidade de uso do Dataflow Streaming na ingestão de dados para a tenant. O custo é definido pelo rateio do recurso entre as tenants na Plataforma Carol. Ação geradora do custo: Ingestão de dados na Plataforma Carol.

• Carol Insights Studio: Este recurso está associado ao recurso Carol Insights Studio (Metabase). O custo é definido por usuário. Ação geradora do custo: usuários ativos no módulo Carol Insights Studio. É possível acompanhar os usuários ativos pelo Carol Billing.

• GitHub Users: Este recurso está associado aos usuários GitHub disponibilizados pela Plataforma Carol. A cobrança ocorre por usuário, considerando um valor unitário para cada usuário associado ao recurso.

• BigQuery BI Engine: Este recurso é utilizado por tenants explorando o cache in-memory do BigQuery para otimização de queries. A quantidade é definida pela quantidade de GB alocados. A ativação do recurso deve ocorrer através de issue no Jira. Considere limitações do BI Engine descritas neste site. Ação geradora do custo: Tenants que solicitaram a habilitação do recurso estão sujeitas ao custo conforme memória alocada ao projeto. Custo GCP: LINK

• E-Mail: Este recurso define a quantidade de e-mails enviados pela tenant, a definição de quantidade é determinada pelo número de e-mails enviados. Ação geradora do custo: envio de e-mails pela tenant e Carol Apps instalado na tenant (exemplo: Clock-In).

• SMS: Este recurso define quantos SMS a tenant enviou, a definição da quantidade é determinada pelo número de SMS enviados. Ação geradora do custo: envio de SMS pela tenant e Carol Apps instalado na tenant (exemplo: Clock-In).

Operações na plataforma e seus impactos no Billing

Abaixo estão mapeadas operações comuns realizadas na plataforma e quais componentes de custo são impactados por cada uma. Isso ajuda a entender a relação direta entre ações e custos.

Ingerir Dados na Plataforma

Quando você envia dados para a plataforma através dos processos de intake, os custos abaixo são acionados simultaneamente:

Componente	Descrição
Ingestion	Custos de mensageria, APIs e filas (Pub/Sub) que processam o fluxo de dados enviado
Cloud Dataflow Streaming	Processamento em tempo real dos dados ingeridos
Cloud Storage	Dados armazenados na staging area (backup)
BigQuery	Armazenamento dos dados na Staging Area e futuros Data Models

---

Executar pipelines de processamento

Quando você executa uma pipeline para processar, transformar ou consolidar dados:

Componente	Descrição
Cloud Dataflow Batch	Processa e transforma dados em lotes para popular data models ou consolidar dados (CDS)
Slots Compartilhados	Unidades computacionais do BigQuery usadas no processamento de dados SQL Processing
BigQuery	Armazenamento dos Data Models gerados pelas pipelines

Dica: Otimize suas queries usando particionamento e clustering. Pipelines ineficientes executadas múltiplas vezes impactam significativamente os custos. Consulte as práticas de SQL Processing Efficiency.

---

Executar queries e análises

Quando analistas ou sistemas executam queries para explorar ou visualizar dados:

Componente	Descrição
Slots Compartilhados	Potência computacional utilizada para processar as queries
BigQuery BI Engine	Se habilitado, fornece cache in-memory para otimizar queries repetidas

Dica: Se sua tenant faz queries repetitivas frequentemente, habilitar o BigQuery BI Engine pode reduzir custos significativamente. Solicite a habilitação via Jira.

---

Executar Carol Apps

Quando você executa uma Carol App (processamento, visualização ou integração):

Componente	Descrição
Compute Time	Horas de execução da App no pod alocado, variando conforme o tamanho da instância (c1.nano até g1.v100.xlarge)
Networking	Tráfego de entrada/saída gerado durante a execução, incluindo comunicação com instâncias GCP
Google Maps	Se a App integra com o serviço Google Maps
SMS	Se a App envia SMS (exemplo: Clock-In)
E-Mail	Se a App envia e-mails (exemplo: Clock-In)
Sentry	Se Clock-In está instalado, monitoramento e debug são rateados entre tenants

Dica: Escolha o tamanho de instância apropriado para sua necessidade. Uma App executada centenas de vezes com resultado idêntico gera custo multiplicado.

Como exportar os dados de billing e trabalhar em planilhas eletrônicas

O processo de billing permite exportar os dados para gerar visualizações customizadas. Isso é possível através do botão Download Invoice:

Com o arquivo, é possível enviar para o Google Drive e abrir no Google Sheets:

Uma vez que os dados foram carregados no Google Sheets, é possível aplicar visualizações em uma pivot table, conforme imagem abaixo:

Pontos de destaque:

• As colunas A-M estão selecionadas.
• Vá no menu Insert e depois em Pivot table

Com a Pivot Table criada, você pode configurar a visualização desejada, na visualização abaixo está sendo plotado os recursos por mês.

Detalhes da configuração:

• Rows: selecionado o que será as linhas da pivot table, no caso resource.
• Columns: selecionado o que será as colunas, neste caso selecionado year_month
• Values: o que será o valor no cruzamento dos dados de rows e columns, neste caso o total_cost de cada recurso em cada ano/mês.

Nota

É possível exportar os dados de diversos meses e colocar todos dentro do mesmo Google Sheet para compor visualizações comparativas entre meses.

Boas Práticas e recomendações

Recomendações:

• Realtime: ao invés do uso do realtime recomendamos o uso de TOTVS Apps com banco de dados de baixa latência (dados podem ser integrados com Data Subscription, consulte a documentação correspondente).

O que pode elevar o custo de um projeto:

• Volume de dados: alta Ingestão de dados na plataforma (exemplo, full-load diário dos dados)
• Processamento de dados: processamento de dados gerando volume de dados acima do normal (custos de storage e ingestão de dados processados)
• Pipelines Ineficientes: Execução das pipelines frequentemente e sem eficiência do SQL processing (vide documentação).

O que pode ser feito para reduzir custos:

• Verificar se o dado utilizado já existe na plataforma: O recurso de compartilhamento de dados “Share Data” não gera uma cópia de dados, quando ele é compartilhado é feita uma leitura (view) da origem do dado, economizando ingestão e storage.
• Trazer somente os dados necessários: Quando subir dados para a plataforma trazer somente as linhas e colunas necessárias para o projeto.
• Periodicidade de carga de dados: Avaliar a necessidade de carga de dados e atualizações. (A carga em batch (em lotes e executadas em escalas) pode ser mais eficiente que a carga online).
• Política de retenção de dados: Analisar quanto dado realmente é necessário eu ter armazenado para os indicadores.
• Pipelines e consultas otimizadas: Ter boas práticas na construção de pipelines e na construção de consultas no BigQuery, processando dados ou construindo insights sempre utilizando a partição da tabela e / ou os atributos definidos no cluster da tabela.

Informação de billing de produtos que utilizam a plataforma de dados Carol

• Clock-in: O billing de clock-in ocorre para o segmento, o valor informado é o valor de custo, não sendo o valor pago pelo cliente que utiliza o produto.
• Tenant que possuem aplicativos que com partnumber cadastrados no CRM é possível trazer a informação de recorrente mensal (MRR) dos clientes, como exemplo a imagem abaixo, para exibi-lo, é necessário clicar em "See MRR over costs". O valor recorrente mensal é representado pela linha, com os valores projetados no eixo Z (lado direito), enquanto os custos são representados pelas barras, projetados no eixo X (lado esquerdo).