# PRM por User Agent: atribuição melhor, governança ainda necessária

A expansão do Partner Revenue Measurement por User Agent é pequena na implementação e relevante na leitura econômica de soluções SaaS e ISV na AWS. Eu gosto do movimento, mas trataria isso como telemetria de atribuição, não como sistema financeiro primário.

- URL: https://fernando.moretes.com/blog/prm-por-user-agent-atribuicao-melhor-governanca-ainda-necessaria-partner-reve

- Markdown: https://fernando.moretes.com/blog/prm-por-user-agent-atribuicao-melhor-governanca-ainda-necessaria-partner-reve/article.md?lang=pt

- Published: 2026-09-01T19:57:50.117Z

- Category: IA & Agentes

- Tags: AWS, Partner Revenue Measurement, CloudTrail, Marketplace, FinOps, ISV, Governance

- Reading time: 7 min

- Source: [Partner Revenue Measurement expands service coverage for User Agent string capability](https://aws.amazon.com/about-aws/whats-new/2026/08/partner-revenue-measurement-user-agent-expansion/)

---

A notícia de 31 de agosto de 2026 sobre a ampliação do Partner Revenue Measurement para mais serviços via User Agent parece, à primeira vista, um detalhe de ecossistema para parceiros AWS. Eu leio de outro jeito: é mais uma peça na convergência entre telemetria operacional, monetização de produto e governança comercial. O mecanismo continua simples: aplicações de parceiros que fazem chamadas regulares para APIs AWS incluem um identificador no User Agent no formato `APN_1.1/pc_<AWS Marketplace product-code>$`; a AWS usa eventos de plano de controle registrados no CloudTrail, quando aplicável, para atribuir consumo agregado a produtos de parceiros. O valor está em reduzir zonas cegas. O risco está em confundir atribuição mensal agregada com contabilidade de custo, billing detalhado ou prova absoluta de adoção.

## O que foi confirmado

- **24** — serviços listados para User Agent. A documentação atual de serviços incluídos lista 24 códigos de serviço, incluindo EC2, S3, RDS, CloudFront, EventBridge, Kinesis, WAF e Shield.
- **17 dias** — latência de disponibilidade do dashboard. A documentação do Attributed Revenue informa processamento mensal e disponibilidade 17 dias após o fim do mês anterior.
- **1 KB** — tamanho máximo do campo `userAgent` no CloudTrail. O CloudTrail documenta limite de 1 KB para `userAgent`, com truncamento em condições de tamanho de evento.

## O que realmente mudou

A mudança não exige uma nova biblioteca, um novo agente nem uma integração pesada. Parceiros que já colocaram o User Agent no formato exigido passam a se beneficiar da cobertura ampliada automaticamente, segundo a própria AWS. Isso é importante porque, em arquiteturas reais, o produto raramente gera consumo em apenas um serviço. Um conector de dados pode tocar S3, Glue, EventBridge, CloudWatch Logs e Kinesis; uma plataforma de segurança pode chamar WAF, Shield, CloudFront, Route 53, EC2 e ELB; uma ferramenta DevOps pode operar CodeBuild, ECS e DynamoDB. Se a atribuição só enxerga uma fatia, a conversa comercial fica enviesada.

O ponto técnico é que a AWS está usando uma evidência que já existe no plano de controle: chamadas de API registradas no CloudTrail. Isso favorece soluções que automatizam criação, atualização, inspeção ou operação de recursos AWS. Não favorece igualmente workloads puramente passivos, tráfego de plano de dados sem operação de controle mensal, ou componentes que rodam uma vez e desaparecem. Para mim, a expansão transforma o User Agent em uma instrumentação de baixo atrito para ISVs, mas não elimina a necessidade de combinar métodos: Marketplace Metering quando o produto é AMI ou ML vendido pelo Marketplace, Resource Tagging quando há recursos persistentes atribuíveis, e User Agent quando a evidência natural é a ação da aplicação.

## Como a atribuição por User Agent entra no ciclo operacional

O desenho mostra a fronteira correta: a aplicação emite chamadas instrumentadas; CloudTrail registra evidência operacional; PRM consolida receita atribuída; o parceiro usa isso para produto e parceria, não para substituir FinOps granular.

### 🏢 Produto do parceiro

- Aplicação ISV SDK/CLI AWS (compute)
- Application ID APN_1.1/pc_<code>$ (security)

### ☁️ Conta AWS do cliente

- APIs AWS suportadas chamadas de plano de controle (edge)
- Serviços medidos EC2, S3, RDS, Kinesis... (data)
- AWS CloudTrail campo userAgent (security)

### 📊 AWS Partner Central

- Partner Revenue Measurement consolidação mensal (data)
- Attributed Revenue Dashboard produto, serviço, mês (frontend)

### 🧭 Gestão

- FinOps e produto hipóteses e reconciliação (user)

### Fluxos

- app -> ua: configura uma vez por runtime
- ua -> api: anexa User Agent nas chamadas regulares
- api -> services: opera recursos suportados
- api -> trail: gera eventos com userAgent
- trail -> prm: evidência para atribuição
- prm -> dash: agrega por produto, serviço e mês
- dash -> finops: orienta análise comercial

## Onde brilha

O melhor caso de uso é um produto que opera ambientes AWS em nome do cliente: provisionadores, gateways de dados, plataformas de observabilidade, ferramentas de segurança, automação de backup, aceleradores de landing zone, motores de integração e produtos de modernização. Nesses cenários, colocar o identificador no SDK reduz dependência de tags em recursos que talvez o parceiro nem controle diretamente. Também evita o conflito clássico do `aws-apn-id`: um recurso só pode ter uma chave com esse nome, então dois parceiros não conseguem compartilhar a mesma marcação no mesmo recurso sem uma decisão explícita de propriedade.

Em ambientes financeiros, esse detalhe operacional faz diferença. Uma plataforma de governança que cria regras de EventBridge, atualiza WAF, grava configuração em S3 e consulta CloudWatch Logs precisa demonstrar valor de forma auditável, mas sem invadir a contabilidade do cliente. O User Agent entrega um sinal de baixa sensibilidade: ele mostra que a solução dirigiu consumo de determinados serviços, agregado por produto e período, sem expor no dashboard detalhes de workload que deveriam continuar no domínio do cliente. Essa separação é saudável. O parceiro ganha uma visão de impacto; o cliente mantém controle sobre dados financeiros detalhados, Cost Explorer, CUR, tags internas e centros de custo.

## Forças da abordagem

- Baixo atrito de adoção: a configuração pode ser feita por Application ID via arquivo compartilhado, variável de ambiente ou propriedade JVM, dependendo do SDK e da ferramenta.
- Boa aderência a automação: produtos que fazem chamadas recorrentes de API conseguem gerar evidência de uso sem exigir mutação de tags em todos os recursos.
- Menos conflito em ecossistemas com múltiplos parceiros: o User Agent pertence à chamada feita pela solução, enquanto tags competem pelo mesmo recurso.
- Governança comercial mais objetiva: o dashboard consolida produto, serviço e mês, o que ajuda liderança de produto, alianças e FinOps a discutirem tendências com uma base comum.

## Onde dói

O limite principal é semântico: uma chamada de controle não equivale automaticamente a causalidade financeira perfeita. Se a aplicação cria um recurso uma vez e depois o cliente opera diretamente por meses, a evidência por User Agent pode ficar fraca, porque a própria documentação indica que operações mensais de API em recursos são necessárias para ocorrer atribuição. O inverso também merece cuidado: uma automação pode tocar um recurso que já existia e, dependendo das regras de PRM, gerar atribuição que precisa ser interpretada no contexto correto de produto, contrato e operação.

Outro ponto é que `userAgent` não foi desenhado como ledger financeiro. No CloudTrail ele identifica o agente da requisição, tem tamanho máximo documentado de 1 KB e pode sofrer truncamento quando o evento passa por limites de tamanho. Em chamadas originadas por serviços AWS, o campo pode refletir o serviço chamador, não necessariamente o cliente SDK original. Portanto, eu não construiria um processo de remuneração variável, repasse financeiro ou SLA contratual apenas em cima do dashboard de receita atribuída. Usaria o dashboard como evidência agregada e tendência; para reconciliação, cruzaria com Marketplace, CUR, contratos, IDs de oportunidade, tags internas e dados consentidos do cliente.

> **Não trate PRM como Cost Explorer do parceiro:** O Attributed Revenue Dashboard é agregado por produto, serviço e período de faturamento, com disponibilidade mensal. Ele é excelente para direção, cobertura e conversa de parceria; ele não substitui CUR, Cost Explorer, chargeback, showback, budgets, anomalias de custo ou trilhas de auditoria internas do cliente.

## Como eu adotaria em uma solução real

Eu começaria pela matriz de causalidade do produto, não pelo código. Para cada capability, eu mapearia quais chamadas AWS são feitas pela solução, em qual conta, em qual região, com qual frequência e com qual relação com o valor entregue. Em uma plataforma SaaS que gerencia recursos no tenant do cliente, eu exigiria um runtime wrapper único para clientes AWS SDK: Node.js v3, boto3, Java v2, Go v2 ou o stack usado pela aplicação. Esse wrapper colocaria o Application ID uma vez, impediria strings divergentes por microserviço e emitiria um log estruturado por chamada crítica: `aws.service`, `aws.operation`, `aws.region`, `productCodeConfigured=true`, `requestId` quando disponível, e resultado.

Na esteira de CI/CD, eu adicionaria testes de contrato que validam presença do `AWS_SDK_UA_APP_ID` ou configuração equivalente no container, Lambda, job ECS, CodeBuild ou runner que realmente faz chamadas AWS. Em produção, eu verificaria amostras no CloudTrail Lake ou nos logs entregues ao S3, procurando o prefixo `APN_1.1/pc_` no campo `userAgent`. Para contas com SCPs e permission boundaries, eu não daria permissão extra só por causa do PRM; a instrumentação deve acompanhar chamadas que a solução já está autorizada a fazer. Segurança vem antes de atribuição.

## Roteiro de adoção que eu aprovaria

1. **1. Defina a fronteira de responsabilidade** — Liste apenas chamadas feitas diretamente pela solução do parceiro. A documentação da AWS alerta para não configurar User Agent em chamadas iniciadas pelo cliente e independentes da solução.

2. **2. Centralize a configuração** — Use Application ID no SDK, variável `AWS_SDK_UA_APP_ID`, arquivo `~/.aws/config` ou propriedade JVM conforme o runtime. Evite copiar strings em dezenas de clientes manualmente.

3. **3. Valide em CloudTrail antes de celebrar o dashboard** — Faça chamadas reais de teste, confirme `userAgent`, `eventSource`, `eventName`, `awsRegion` e `requestID`. Depois acompanhe a janela mensal do dashboard, sabendo que a disponibilidade documentada é 17 dias após o fim do mês.

4. **4. Combine métodos quando necessário** — Use tags em recursos persistentes quando fizer sentido, Marketplace Metering para AMI/ML elegíveis, e User Agent para automações de API. Nenhum método isolado modela todo tipo de produto.

5. **5. Crie reconciliação mensal** — Compare tendência do PRM com contratos, consumo esperado, release notes, incidentes, expansão de clientes e mudanças de arquitetura. A pergunta operacional é: o sinal faz sentido?

## User Agent, tags e Marketplace Metering
| Critério | Melhor uso | Risco principal | Controle recomendado |
| --- | --- | --- | --- |
| User Agent | Soluções que fazem chamadas regulares de API/CLI em contas do cliente ou do parceiro. | Confundir chamada operacional com causalidade financeira completa. | Wrapper único de SDK, teste de configuração e amostragem em CloudTrail. |
| Resource Tagging | Recursos persistentes claramente associados ao produto. | Conflito do `aws-apn-id`, drift em IaC e remoção de tag por qualquer usuário com acesso adequado. | Tagging via IaC, política de tags, AWS Config e acordo explícito com o cliente. |
| Marketplace Metering | AMI e produtos ML comprados e consumidos via AWS Marketplace. | Cobertura limitada ao modelo de produto elegível. | Validação de listing, product code e fluxo comercial no Marketplace. |

## A leitura Well-Architected

Pelo pilar de excelência operacional, eu gosto da ampliação porque ela força uma disciplina que muitas empresas adiam: instrumentar a própria pegada operacional. Um produto maduro sabe quais APIs chama, por que chama, qual retry policy aplica, qual idempotency token usa e qual impacto de custo pode induzir. Se a solução cria buckets S3, tabelas DynamoDB, streams Kinesis ou regras EventBridge, o PRM por User Agent deve ser consequência de uma arquitetura já observável, não um enfeite comercial colocado no fim.

Pelo pilar de segurança, eu seria conservador. O identificador de produto não deve vazar segredo, tenant ID, nome de cliente, ambiente ou contrato. O formato publicado usa product code do Marketplace, não dados sensíveis. Eu manteria esse padrão rigidamente e bloquearia tentativas de colocar contexto comercial no User Agent. Em organizações reguladas, também revisaria documentação de privacidade e DPA: ainda que o dashboard seja agregado, a origem do sinal passa por eventos de controle, e isso precisa estar descrito no modelo de transparência com clientes.

Pelo pilar de custo, o benefício é indireto. PRM não reduz fatura, mas ajuda a comparar onde o produto realmente movimenta consumo AWS. Isso melhora roadmap: talvez o produto esteja vendendo uma história de analytics, mas a receita atribuída aparece em EC2 e RDS; talvez a promessa serverless gere mais CloudWatch Logs que Lambda. Esses desvios são arquitetura falando com negócio.

## Controles por pilar

- **security**: Não coloque dados de cliente no User Agent. Garanta que a string seja apenas o formato APN com product code, valide permissões mínimas e preserve segregação entre contas de parceiro e cliente.
- **reliability**: Configure User Agent no ponto comum de criação de clientes SDK para evitar cobertura parcial. Monitore falhas de chamada, throttling e retries para não confundir ausência de atribuição com ausência de valor.

## Anti-padrões que eu evitaria

- Colocar o User Agent em automações genéricas do cliente que não pertencem ao produto do parceiro.
- Adicionar tenant, e-mail, nome de cliente ou oportunidade comercial dentro do User Agent para tentar criar granularidade indevida.
- Usar o dashboard mensal como prova única para comissionamento, renovação ou disputa de consumo.
- Fazer tagging manual em recursos gerenciados por Terraform, CDK ou CloudFormation, causando drift e perda de confiança operacional.
- Instrumentar só os serviços atualmente medidos e esquecer que a AWS recomenda aplicar PRM aos serviços e recursos com os quais a solução interage para reduzir retrabalho quando a cobertura crescer.

> **Minha nota de curadoria:** Eu implementaria User Agent em qualquer produto parceiro sério que opera AWS via SDK, mas colocaria isso sob o mesmo rigor de observabilidade, segurança e FinOps. A lição prática é simples: sinais comerciais fracos viram discussões políticas; sinais operacionais bem instrumentados viram conversas objetivas. Ainda assim, eu nunca prometeria precisão de ledger com uma fonte agregada mensal. Para sistemas financeiros, a arquitetura boa é a que separa evidência, atribuição, faturamento e decisão executiva.

## Referências verificadas

- [AWS What's New: Partner Revenue Measurement expands service coverage for User Agent string capability](https://aws.amazon.com/about-aws/whats-new/2026/08/partner-revenue-measurement-user-agent-expansion/)
- [AWS PRM Documentation: Included AWS Services for User Agent string](https://docs.aws.amazon.com/PRM/latest/aws-prm-onboarding-guide/user-agent-included-services.html)
- [AWS PRM Documentation: Automated User Agent](https://docs.aws.amazon.com/PRM/latest/aws-prm-onboarding-guide/automated-user-agent.html)
- [AWS PRM Documentation: Troubleshooting Partner Revenue Measurement](https://docs.aws.amazon.com/PRM/latest/aws-prm-onboarding-guide/troubleshooting.html)
- [AWS Partner Central Documentation: Attributed Revenue](https://docs.aws.amazon.com/partner-central/latest/getting-started/partner-analytics-attributed-revenue.html)
- [AWS CloudTrail Documentation: Record contents and userAgent field](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html)
- [AWS PRM Documentation: Manual Resource Tagging implementation](https://docs.aws.amazon.com/PRM/latest/aws-prm-onboarding-guide/manual-tagging.html)
- [fieldnotes: Attributed Revenue Dashboards - almost completing the PRM puzzle](https://fieldnotes.awyspr.com/2026-04-22-attributed-revenue-dashboards.html)

## Veredito

Minha recomendação é adotar. Para parceiros AWS, especialmente ISVs que operam workloads de clientes via APIs, a expansão do PRM por User Agent melhora a visibilidade de impacto com custo técnico baixo e sem exigir uma nova superfície operacional. A nota não é maior porque a capacidade ainda depende de cobertura de serviços, eventos de plano de controle, processamento mensal e interpretação cuidadosa. Eu colocaria no backlog imediato de plataformas parceiras, com três condições: configuração centralizada, validação por CloudTrail e reconciliação mensal com FinOps e dados comerciais. Como tecnologia de atribuição, é forte; como sistema financeiro de verdade, precisa continuar cercada por controles.

**Rating:** 8/10