{"id":1213,"date":"2026-04-11T20:48:40","date_gmt":"2026-04-11T20:48:40","guid":{"rendered":"https:\/\/cms.funnelsheet.com\/?p=1213"},"modified":"2026-04-11T20:48:40","modified_gmt":"2026-04-11T20:48:40","slug":"how-to-set-up-tracking-for-a-business-running-ads-in-multiple-cities","status":"publish","type":"post","link":"https:\/\/cms.funnelsheet.com\/?p=1213","title":{"rendered":"How to Set Up Tracking for a Business Running Ads in Multiple Cities"},"content":{"rendered":"

Rastreamento para neg\u00f3cios que rodam an\u00fancios em v\u00e1rias cidades n\u00e3o \u00e9 apenas sobre dividir or\u00e7amentos entre regi\u00f5es. \u00c9 sobre manter a consist\u00eancia entre cidades, fusos hor\u00e1rios, landing pages locais e pontos de contato diferentes, tudo sem perder o fio da meada entre GA4, GTM Web, GTM Server-Side e a API de Convers\u00f5es da Meta. Quando cada cidade parece falar uma l\u00edngua diferente para os dados, a atribui\u00e7\u00e3o vira um quebra-cabe\u00e7a: cliques que somem, leads que n\u00e3o aparecem no CRM, dashboards que descompassam com a realidade de vendas. Este artigo parte de uma premissa direta: voc\u00ea precisa de um framework t\u00e9cnico que conecte cada clique a cada venda, respeitando a diversidade geogr\u00e1fica sem criar ru\u00eddos nos reports.<\/p>\n

Vamos direto ao ponto: voc\u00ea vai sair deste texto sabendo diagnosticar onde a captura falha, escolher a arquitetura certa (client-side vs server-side), estruturar UTMs e par\u00e2metros de cidade, configurar eventos no GA4 e na Meta CAPI, e ter um roteiro de valida\u00e7\u00e3o para evitar surpresas ao vivo. A tese \u00e9 simples: com uma conven\u00e7\u00e3o de cidade bem definida e um fluxo de dados consistente entre fontes, \u00e9 poss\u00edvel obter dados confi\u00e1veis para cada cidade, mantendo a vis\u00e3o consolidada na BigQuery e nos relat\u00f3rios do Looker Studio. Sem promessas vagas \u2013 apenas a\u00e7\u00f5es concretas.<\/p>\n\n\n

\"a<\/figure>\n \n\n

Por que rastrear cidades separadamente importa<\/h2>\n

Atribui\u00e7\u00e3o local vs global: n\u00e3o confunda o clique com a venda<\/h3>\n

Em campanhas que operam em v\u00e1rias cidades, o mesmo usu\u00e1rio pode tocar em an\u00fancios diferentes antes de converter. Sem uma distin\u00e7\u00e3o clara por cidade, voc\u00ea tende a medir o desempenho de forma global, ocultando varia\u00e7\u00f5es cruciais: uma cidade pode responder melhor a um canal, outra pode ter janela de decis\u00e3o mais longa. Quando o city \u00e9 capturado de forma consistente, voc\u00ea consegue alinhar o lucro de cada pra\u00e7a com o custo de aquisi\u00e7\u00e3o espec\u00edfico daquela localiza\u00e7\u00e3o, evitando distor\u00e7\u00f5es que empurram a estrat\u00e9gia para um \u00fanico eixo de atribui\u00e7\u00e3o.<\/p>\n\n\n

\"Linkedin<\/figure>\n \n\n

\u201cRastreamento com city dimension s\u00f3 funciona se voc\u00ea mant\u00e9m par\u00e2metros consistentes em todos os touchpoints.\u201d<\/p><\/blockquote>\n

Consist\u00eancia de dados entre plataformas: o que funciona em GA4 precisa refletir no CAPI e no Ads<\/h3>\n

GA4, Google Ads, Meta CAPI e o ecossistema de dados precisam falar a mesma l\u00edngua sobre cidade. Sem essa sinergia, um usu\u00e1rio pode ser contado como origem diferente entre fontes, levando a varia\u00e7\u00f5es de convers\u00e3o que confundem o planejamento de or\u00e7amento. A consist\u00eancia vem de uma conven\u00e7\u00e3o de cidade clara, de par\u00e2metros que trafeguem pelo data layer e de eventos que aceitem a dimens\u00e3o cidade como parte do contexto da convers\u00e3o.<\/p>\n

Cen\u00e1rios de convers\u00f5es offline: nem tudo acontece no clique<\/h3>\n

Em neg\u00f3cios que fecham via WhatsApp ou telefone, a cidade pode ser o \u00fanico fio condutor que cruza o contato inicial com a venda. Converter offline exige que voc\u00ea capture o city context desde o primeiro contato, mantenha essa informa\u00e7\u00e3o ao longo do funil e una o resultado offline com o toque digital correspondente. O desafio \u00e9 ter uma ponte est\u00e1vel entre dados online e o CRM, para evitar que convers\u00f5es offline fiquem \u201csoltas\u201d no relat\u00f3rio.<\/p>\n

Arquitetura de rastreamento para m\u00faltiplas cidades<\/h2>\n

Escolha entre client-side e server-side: limites claros de cada abordagem<\/h3>\n

Client-side tagging (GTM Web) \u00e9 r\u00e1pido para come\u00e7ar, mas pode sofrer com bloqueios de cookies, consents e limita\u00e7\u00f5es de precis\u00e3o quando acessa dados de cidades diferentes. Server-side tagging (GTM Server-Side) mitiga parte desses problemas, centraliza valida\u00e7\u00f5es e facilita a exporta\u00e7\u00e3o para GA4 e CAPI com menos ru\u00eddo. Em cen\u00e1rios de multi-cidades, a tend\u00eancia \u00e9 combinar: use o client-side para captura imediata de eventos de usu\u00e1rio e o server-side para harmonizar par\u00e2metros de cidade, valida\u00e7\u00f5es de dados sens\u00edveis e encaminhamento consistente para GA4 e para o back-end (BigQuery).<\/p>\n\n\n

\"a<\/figure>\n \n\n

Integra\u00e7\u00e3o GA4 + GTM Server-Side + Meta CAPI: uma tr\u00edade com foco em consist\u00eancia<\/h3>\n

Configure GA4 para receber o par\u00e2metro de cidade nos eventos, de prefer\u00eancia com um campo expl\u00edcito (city_code, city) que possa ser mapeado em relat\u00f3rios. No GTM Server-Side, crie uma camada de saneamento \u2013 valide e normalize os nomes de cidade, aplique masks de privacidade quando necess\u00e1rio e envie para GA4 e para a Meta CAPI com a mesma nomenclatura. A Meta CAPI traz a vantagem de reduzir perdas de dados por bloqueio de cookies, desde que a cidade esteja na payload compartilhada com o servidor. A ideia \u00e9 que cada toque, de qualquer cidade, seja registrado com o mesmo conjunto de atributos de cidade antes de ser consolidado.<\/p>\n

Normaliza\u00e7\u00e3o de cidade no dataLayer: a base de tudo<\/h3>\n

Defina uma conven\u00e7\u00e3o de city_code que seja utilizada em todas as p\u00e1ginas, independentemente da cidade. O dataLayer deve carregar esse par\u00e2metro desde o script inicial, com fallback para uma city-predefinida se a cidade do usu\u00e1rio n\u00e3o puder ser determinada. Em cada evento (page_view, click, form_submission, purchase), empurre city_code e city_name, para que as plataformas de dados possam correlacionar as a\u00e7\u00f5es com a cidade correta. Sem esse alinhamento, as varia\u00e7\u00f5es de cidade aparecem como ru\u00eddo nos funis de convers\u00e3o.<\/p>\n

\u201cA cidade n\u00e3o \u00e9 apenas um filtro; \u00e9 contexto de decis\u00e3o que precisa viajar com cada evento.\u201d<\/p><\/blockquote>\n

Passo a passo de implementa\u00e7\u00e3o<\/h2>\n

Abaixo est\u00e1 um roteiro acion\u00e1vel para colocar em pr\u00e1tica sem ficar preso a discuss\u00f5es te\u00f3ricas. Siga na ordem para minimizar retrabalho e garantir que a cidade seja parte intr\u00ednseca da hist\u00f3ria de cada convers\u00e3o.<\/p>\n

    \n
  1. Defina a conven\u00e7\u00e3o de city_code e city_name: adote uma nomenclatura clara (ex.: cidade_code = \u201cSaoPaulo\u201d, cidade_name = \u201cS\u00e3o Paulo\u201d) e aplique em todas as fontes de dados.<\/li>\n
  2. Padronize UTMs por cidade: adicione um par\u00e2metro UTM espec\u00edfico por cidade (utm_city) para facilitar a segmenta\u00e7\u00e3o cruzada entre campanhas e canais.<\/li>\n
  3. Configure o dataLayer para carregar city_code\/city_name desde as primeiras intera\u00e7\u00f5es: atualize o c\u00f3digo-fonte das p\u00e1ginas para garantir a disponibilidade desse contexto em eventos-chave.<\/li>\n
  4. Envie city_code nos eventos GA4: inclua city_code como par\u00e2metro de evento (por exemplo, event_name = \u201cpurchase\u201d, city = city_code) e crie dimens\u00f5es personalizadas se necess\u00e1rio.<\/li>\n
  5. Alimente a Meta CAPI com a mesma granularidade de cidade: garanta que a payload enviada ao CAPI contenha city_code e city_name para que as convers\u00f5es offline ou via servidor tamb\u00e9m incorporem o contexto geogr\u00e1fico.<\/li>\n
  6. Habilite GTM Server-Side com caminhos consistentes: configure um container server-side dedicado, valide pipelines de dados e implemente valida\u00e7\u00f5es para normalizar cidades antes de enviar para GA4 e CAPI.<\/li>\n
  7. Conecte GA4 a BigQuery e prepare dashboards com segmenta\u00e7\u00e3o por cidade: modele tables por cidade e crie Looker Studio com filtros por city_code para uma vis\u00e3o \u00e1gil de desempenho por cidade.<\/li>\n<\/ol>\n

    Valida\u00e7\u00e3o e monitoramento: como saber se o setup funciona<\/h2>\n

    Sinais de que o setup est\u00e1 quebrado<\/h3>\n

    Se voc\u00ea observar discrep\u00e2ncias entre GA4 e Meta CAPI para a mesma cidade, ou se as convers\u00f5es offline n\u00e3o aparecem no final do funil, \u00e9 sinal de que city_code n\u00e3o est\u00e1 sendo propagado consistentemente. Falhas comuns incluem dataLayer ausente no carregamento inicial, par\u00e2metros de cidade diferentes entre GTM Web e GTM Server-Side, ou UTMs que perdem o city context ap\u00f3s redirecionamentos.<\/p>\n

    Erros comuns de city parameter<\/h3>\n

    Evite city_code gen\u00e9rico (ex.: \u201cUnknown\u201d) e garanta fallback claro apenas quando estritamente necess\u00e1rio. Verifique que cada evento tem city_code v\u00e1lido. Em redirecionamentos, confirme que o city_code via URL n\u00e3o \u00e9 sobrescrito por par\u00e2metros de origem sem cidade, o que pode quebrar a atribui\u00e7\u00e3o por cidade.<\/p>\n

    Verifica\u00e7\u00e3o com BigQuery e Looker Studio<\/h3>\n

    Execute consultas que cruzem cities com canais, campanhas e janelas de convers\u00e3o. Compare os resultados com relat\u00f3rios nativos do GA4 para validar consist\u00eancia. Use Looker Studio para criar visualiza\u00e7\u00f5es r\u00e1pidas de varia\u00e7\u00f5es city-by-city e detectar anomalias antes que impactem a decis\u00e3o operacional.<\/p>\n

    Boas pr\u00e1ticas de governan\u00e7a e entreg\u00e1veis<\/h2>\n

    Padroniza\u00e7\u00e3o de contas e auditoria de dados por cidade<\/h3>\n

    Defina pol\u00edticas claras de naming conventions, mantenha um reposit\u00f3rio de mapeamento city_code -> city_name e documente qualquer mudan\u00e7a de nomenclatura. Duplique \u00edndices de city para cada ecossistema (GA4, GTM, CAPI, Ads) para facilitar auditorias r\u00e1pidas com clientes ou equipes t\u00e9cnicas.<\/p>\n

    Adapta\u00e7\u00e3o \u00e0 realidade do projeto ou do cliente<\/h3>\n

    Nem todo cliente tem back-end pronto para data import e offline conversions com city context. Nesses casos, comece com city_code no front-end, valide a consist\u00eancia entre GA4 e Google Ads, e planeje a matura\u00e7\u00e3o para server-side tagging e integra\u00e7\u00f5es com CRM. O importante \u00e9 deixar claro quais partes j\u00e1 est\u00e3o funcionando e quais dependem de evolu\u00e7\u00e3o do stack, para evitar promessas n\u00e3o entreg\u00e1veis.<\/p>\n

    Ferramentas de refer\u00eancia na pr\u00e1tica incluem GA4, GTM Web, GTM Server-Side, e a API de Convers\u00f5es da Meta. Consulte a documenta\u00e7\u00e3o oficial para detalhes t\u00e9cnicos de implementa\u00e7\u00e3o: a Google oferece guias sobre a coleta de eventos e par\u00e2metros no GA4, incluindo a estrutura de event parameters, e a Meta disponibiliza a documenta\u00e7\u00e3o da Conversions API para integra\u00e7\u00e3o com o servidor. Veja, por exemplo, a documenta\u00e7\u00e3o do GA4 e as notas t\u00e9cnicas da Conversions API para orientar decis\u00f5es de configura\u00e7\u00e3o:<\/p>\n

    documenta\u00e7\u00e3o oficial GA4<\/a> e Conversions API da Meta<\/a>.<\/p>\n

    Roteiro de valida\u00e7\u00e3o r\u00e1pida para multi-cidades<\/h2>\n

    Para fechar, trazemos um conjunto de crit\u00e9rios que ajudam a decidir rapidamente se o setup est\u00e1 pronto para produ\u00e7\u00e3o ou se precisa de ajustes finos antes de escalar para mais cidades:<\/p>\n

      \n
    • Todos os eventos relevantes (page_view, click, form_submission, purchase) transportam city_code com consist\u00eancia entre GA4 e CAPI.<\/li>\n
    • UTM_city est\u00e1 presente e \u00e9 \u00fanico por cidade, sem overlaps entre cidades ou canais.<\/li>\n
    • DataLayer carrega city_code desde o carregamento da p\u00e1gina e n\u00e3o \u00e9 sobrescrito por tr\u00e1fego de refer\u00eancia sem cidade.<\/li>\n
    • Relat\u00f3rios no BigQuery e Looker Studio conseguem segmentar por city_code sem quedas de agrega\u00e7\u00e3o ou discrep\u00e2ncias de contagem.<\/li>\n
    • Conversion window, atribui\u00e7\u00e3o e janela de toque est\u00e3o alinhadas entre GA4 e Google Ads para cada cidade.<\/li>\n
    • Relat\u00f3rios offline (WhatsApp\/CRM) refletem o mesmo city_code presente nos eventos online, permitindo uma vis\u00e3o unificada.<\/li>\n
    • Consent Mode v2 est\u00e1 configurado para lidar com privacidade, sem comprometer a necessidade de dados para city-based attribution.<\/li>\n<\/ul>\n

      Conclus\u00e3o pr\u00e1tica: o que voc\u00ea entrega ao final deste setup<\/h2>\n

      Ao final deste caminho, voc\u00ea ter\u00e1 uma infraestrutura que reconhece cidade como parte essencial do contexto de cada intera\u00e7\u00e3o, n\u00e3o apenas um filtro. A soma de GA4, GTM Server-Side e Meta CAPI, com city_code padronizado, oferece uma vis\u00e3o mais est\u00e1vel de custo por aquisi\u00e7\u00e3o, convers\u00f5es por cidade e impacto de campanhas multicanal. O pr\u00f3ximo passo \u00e9 mapear as cidades-alvo, alinhar UTMs por cidade, e iniciar o rollout com um piloto em duas ou tr\u00eas pra\u00e7as antes de escalar. Se h\u00e1 d\u00favidas sobre governan\u00e7a, a orienta\u00e7\u00e3o \u00e9 manter um roteiro de auditoria mensal e documentar qualquer mudan\u00e7a de nomenclatura ou de fluxo de dados. Em resumo, a cidade deixa de ser ru\u00eddo e passa a ser \u00e2ncora de decis\u00e3o operacional para a performance de m\u00eddia paga.<\/p>","protected":false},"excerpt":{"rendered":"

      Rastreamento para neg\u00f3cios que rodam an\u00fancios em v\u00e1rias cidades n\u00e3o \u00e9 apenas sobre dividir or\u00e7amentos entre regi\u00f5es. \u00c9 sobre manter a consist\u00eancia entre cidades, fusos hor\u00e1rios, landing pages locais e pontos de contato diferentes, tudo sem perder o fio da meada entre GA4, GTM Web, GTM Server-Side e a API de Convers\u00f5es da Meta. Quando…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[4],"tags":[444,13,14,17,443],"content_language":[5],"class_list":["post-1213","post","type-post","status-publish","format-standard","hentry","category-blogen","tag-api-de-conversoes-da-meta","tag-ga4","tag-gtm-server-side","tag-gtm-web","tag-rastreamento-de-anuncios","content_language-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=\/wp\/v2\/posts\/1213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1213"}],"version-history":[{"count":0,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=\/wp\/v2\/posts\/1213\/revisions"}],"wp:attachment":[{"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1213"},{"taxonomy":"content_language","embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcontent_language&post=1213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}