{"id":988,"date":"2026-04-01T22:29:20","date_gmt":"2026-04-01T22:29:20","guid":{"rendered":"https:\/\/cms.funnelsheet.com\/?p=988"},"modified":"2026-04-01T22:29:20","modified_gmt":"2026-04-01T22:29:20","slug":"how-to-fix-duplicate-ga4-events-without-losing-historical-data","status":"publish","type":"post","link":"https:\/\/cms.funnelsheet.com\/?p=988","title":{"rendered":"How to Fix Duplicate GA4 Events Without Losing Historical Data"},"content":{"rendered":"<p>Duplicidade de eventos no GA4 \u00e9 um dos problemas mais corrosivos de rastreamento que managers de m\u00eddia paga enfrentam hoje. Voc\u00ea investe tempo no GA4, no GTM Web e, \u00e0s vezes, no GTM Server-Side, mas aparece uma repeti\u00e7\u00e3o de envios que distorce a atribui\u00e7\u00e3o, inflige ru\u00eddo ao funil e corr\u00f3i a confian\u00e7a em relat\u00f3rios. O desafio n\u00e3o \u00e9 apenas eliminar os duplicados; \u00e9 fazer isso sem perder dados hist\u00f3ricos j\u00e1 coletados, sem quebrar integra\u00e7\u00f5es (CRM, WhatsApp, plataformas de automa\u00e7\u00e3o) e sem exigir uma reconfigura\u00e7\u00e3o de alto risco no ecossistema de dados. Este artigo parte de um diagn\u00f3stico direto: como corrigir eventos duplicados no GA4 sem sacrificarmos o que j\u00e1 foi registrado, mantendo a compatibilidade com BigQuery, Looker Studio e as integra\u00e7\u00f5es de terceiros que voc\u00ea j\u00e1 usa. Ao terminar, voc\u00ea ter\u00e1 um plano claro de diagn\u00f3stico, uma abordagem de implementa\u00e7\u00e3o idempotente e um roteiro de valida\u00e7\u00e3o para n\u00e3o retroceder dados hist\u00f3ricos.<\/p>\n<p>O problema n\u00e3o \u00e9 apenas t\u00e9cnico; \u00e9 operacional. Duplicatas costumam nascer quando v\u00e1rias fontes disparam o mesmo evento quase simultaneamente (pense em envio simult\u00e2neo do GTM Web e do GTM Server-Side, ou disparos de p\u00e1gina que acionam o mesmo evento duas vezes). Em muitos cen\u00e1rios, a solu\u00e7\u00e3o passa por adotar um mecanismo de idempot\u00eancia \u2014 ou seja, tratar eventos repetidos como o mesmo evento \u00fanico \u2014 e, ao mesmo tempo, consolidar o envio centralizado para reduzir gaps entre plataformas. Este texto assume um cen\u00e1rio realista: voc\u00ea j\u00e1 tem GA4, GTM Web, GTM Server-Side e, possivelmente, uma integra\u00e7\u00e3o de CRM ou WhatsApp, e quer uma corre\u00e7\u00e3o pr\u00e1tica sem reinventar o ecossistema inteiro. Vamos direto ao ponto: diagn\u00f3stico, estrat\u00e9gias t\u00e9cnicas, passos de implementa\u00e7\u00e3o e armadilhas comuns a evitar.<\/p>\n\n\n                        <figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1161\" height=\"1200\" src=\"https:\/\/cms.funnelsheet.com\/wp-content\/uploads\/2026\/04\/2gjp_az2o_i.jpg\" alt=\"a hard drive is shown on a white surface\" class=\"wp-image-899\" srcset=\"https:\/\/cms.funnelsheet.com\/wp-content\/uploads\/2026\/04\/2gjp_az2o_i.jpg 1161w, https:\/\/cms.funnelsheet.com\/wp-content\/uploads\/2026\/04\/2gjp_az2o_i-290x300.jpg 290w, https:\/\/cms.funnelsheet.com\/wp-content\/uploads\/2026\/04\/2gjp_az2o_i-991x1024.jpg 991w, https:\/\/cms.funnelsheet.com\/wp-content\/uploads\/2026\/04\/2gjp_az2o_i-768x794.jpg 768w\" sizes=\"auto, (max-width: 1161px) 100vw, 1161px\" \/><\/figure>\n                        \n\n<h2>Diagn\u00f3stico dos seus eventos duplicados no GA4<\/h2>\n<h3>Origem das duplicatas: client-side vs server-side<\/h3>\n<p>Antes de aplicar uma corre\u00e7\u00e3o, identifique onde o duplicado surge. Em muitos casos, o problema aparece quando o evento \u00e9 enviado tanto do lado do cliente (navegador) quanto do servidor (GTM Server-Side) para o GA4. O resultado \u00e9 a mesma a\u00e7\u00e3o registrada duas vezes, com IDs de usu\u00e1rio ou de evento diferentes, mas com o tempo de ocorr\u00eancia muito pr\u00f3ximo. Outra fonte frequente \u00e9 o disparo duplo dentro de uma mesma p\u00e1gina: um gatilho que aciona o evento v\u00e1rias vezes por erro de configura\u00e7\u00e3o ou por re-carregamento de elementos (single-page apps, ou SPA) que n\u00e3o cancela o envio anterior. A origem precisa dita o rem\u00e9dio: se o problema \u00e9 cliente duplicando, a solu\u00e7\u00e3o passa pela deduplica\u00e7\u00e3o no client-side com uma checagem de idempot\u00eancia; se \u00e9 servidor, a corre\u00e7\u00e3o tende a passar por centralizar envio e filtrar duplicatas antes do GA4.<\/p>\n<blockquote><p>Duplicatas costumam nascer de envios paralelos: GTM no cliente e GTM Server-Side capturam a mesma a\u00e7\u00e3o. O resultado \u00e9 um ataque de ru\u00eddo que o GA4 n\u00e3o sabe como reconciliar sem uma estrat\u00e9gia de deduplica\u00e7\u00e3o consciente.<\/p><\/blockquote>\n<h3>Sinais de duplica\u00e7\u00e3o: onde procurar e como confirmar<\/h3>\n<p>Use uma combina\u00e7\u00e3o de fontes para confirmar duplica\u00e7\u00e3o: a interface do GA4 pode mostrar cliques e eventos que parecem sobrepostos; o BigQuery oferece granularidade para identificar eventos com o mesmo event_name, user_pseudo_id e timestamp muito pr\u00f3ximos; os dados no data layer ajudam a entender se o evento est\u00e1 chegando de fontes distintas. Em muitos casos, a corre\u00e7\u00e3o passa por incluir um identificador \u00fanico de envio (event_id) que permita ao GA4 reconhecer e descartar tentativas repetidas de envio. Se voc\u00ea perceber que, ap\u00f3s uma altera\u00e7\u00e3o recente, o GA4 come\u00e7a a mostrar picos de eventos que n\u00e3o correspondem ao volume de cliques, j\u00e1 \u00e9 um sinal para uma checagem de duplica\u00e7\u00e3o.<\/p>\n<blockquote><p>O problema n\u00e3o \u00e9 apenas perder dados; \u00e9 perder a linha de tempo de eventos cr\u00edticos para atribui\u00e7\u00e3o multi-toque. A corre\u00e7\u00e3o precisa manter a integridade hist\u00f3rica, n\u00e3o apagar o passado.<\/p><\/blockquote>\n<h2>Abordagens t\u00e9cnicas para eliminar duplicatas sem perder dados hist\u00f3ricos<\/h2>\n<h3>Idempot\u00eancia com event_id e deduplica\u00e7\u00e3o no recebimento<\/h3>\n<p>Uma pr\u00e1tica comum e eficaz \u00e9 introduzir um identificador \u00fanico por envio de evento (event_id) e fazer com que o sistema aceite apenas o primeiro envio de um event_id espec\u00edfico. No GA4, isso requer um n\u00edvel de controle no envio \u2014 particularmente quando voc\u00ea utiliza GTM Server-Side \u2014 para registrar e reusar um identificador de evento \u00fanico. A ideia \u00e9 simples: toda vez que um evento chega, o pipeline valida se aquele event_id j\u00e1 foi processado; se sim, ele \u00e9 descartado. Se n\u00e3o, ele \u00e9 registrado e aceito. Essa abordagem evita duplica\u00e7\u00e3o sem apagar dados hist\u00f3ricos porque os eventos j\u00e1 coletados permanecem intactos; apenas os envios duplicados posteriores s\u00e3o filtrados na etapa de ingest\u00e3o.<\/p>\n<h3>Centralizar envios via GTM Server-Side e reduzir duplicatas<\/h3>\n<p>Ao mover a l\u00f3gica de envio para GTM Server-Side, voc\u00ea ganha controle sobre a origem dos envios e pode aplicar filtros antes que os dados atinjam GA4. No servidor, \u00e9 poss\u00edvel implementar regras de deduplica\u00e7\u00e3o com base em event_id, timestamps ou combina\u00e7\u00f5es de user_pseudo_id + event_name + source. Al\u00e9m disso, a Server-Side Tagging facilita a gest\u00e3o de consentimento (Consent Mode v2) e a harmoniza\u00e7\u00e3o de dados entre GA4 e outras camadas de dados, reduzindo a probabilidade de envios redundantes vindos de coletoras no cliente. A documenta\u00e7\u00e3o oficial de GTM Server-Side descreve como estruturar esse fluxo e quais pontos de integra\u00e7\u00e3o observar ao migrar para o servidor. <a href=\"https:\/\/developers.google.com\/tag-manager\/serverside\" target=\"_blank\" rel=\"noopener\">GTM Server-Side<\/a>.<\/p>\n<h3>Alinhamento de janelas de coleta e regras de envio<\/h3>\n<p>Outra pe\u00e7a importante \u00e9 alinhar a janela de coleta entre plataformas: o GA4 pode aceitar um evento com atraso ou duplicado se o mesmo usu\u00e1rio realiza a\u00e7\u00f5es quase simult\u00e2neas por diferentes gatilhos. Definir regras simples, como disparar apenas um evento por intervalo de 1\u20132 segundos para determinadas a\u00e7\u00f5es (ex.: clique em um bot\u00e3o que abre um formulario), pode evitar o envio duplicado sem depender de mudan\u00e7as extensas no pipeline. Essa pr\u00e1tica funciona bem quando combinada com event_id \u00fanico, j\u00e1 que o segundo envio dentro da mesma janela \u00e9 filtrado automaticamente pelo destino de dados.<\/p>\n<h2>Passos pr\u00e1ticos para corre\u00e7\u00e3o sem perder dados hist\u00f3ricos<\/h2>\n<p>Abaixo est\u00e1 um roteiro pr\u00e1tico, com passos acion\u00e1veis, para voc\u00ea aplicar agora. Esta se\u00e7\u00e3o funciona como um checklist de valida\u00e7\u00e3o que evita surpresas e mant\u00e9m o hist\u00f3rico intacto. Use a sequ\u00eancia para mitigar duplica\u00e7\u00e3o, sem precisar reprocessar dados j\u00e1 coletados.<\/p>\n<ol>\n<li>Mapear as fontes de envio: identifique quais gatilhos (cliente vs servidor) podem estar duplicando eventos. Verifique GTM Web, GTM Server-Side, integra\u00e7\u00f5es de CRM e automa\u00e7\u00e3o (WhatsApp, leads via formul\u00e1rio, eventos de p\u00e1gina).<\/li>\n<li>Definir event_id \u00fanico por envio: crie um identificador est\u00e1vel para cada envio de evento. Garanta que o event_id n\u00e3o seja recalculado em retransmiss\u00f5es e registre-o junto com o evento.<\/li>\n<li>Implementar deduplica\u00e7\u00e3o no recebimento: configure o GTM Server-Side para rejeitar eventos com event_id j\u00e1 registrado. Em ambientes sem server-side, implemente uma checagem similar na camada de envio de dados do cliente ou na API de recebimento do GA4.<\/li>\n<li>Consolidar envios no pipeline: sempre que poss\u00edvel, centralize o envio de eventos cr\u00edticos no GTM Server-Side para reduzir a duplica\u00e7\u00e3o originada de chamadas paralelas.<\/li>\n<li>Ajustar data layer e gatilhos: revise os gatilhos que possam disparar o mesmo evento v\u00e1rias vezes. Remova duplica\u00e7\u00e3o de triggers, normalize datas e timestamps, e garanta que o data layer n\u00e3o empurre o mesmo evento repetidamente.<\/li>\n<li>Executar valida\u00e7\u00e3o de dados: compare eventos com BigQuery e com o pr\u00f3prio GA4 em per\u00edodos de refer\u00eancia. Use um conjunto de dados para confirmar que a contagem por event_name + event_id n\u00e3o apresenta duplicatas novas ap\u00f3s a implementa\u00e7\u00e3o, mantendo os dados hist\u00f3ricos inalterados.<\/li>\n<\/ol>\n<p>Valide com um plano de QA claro: crie cen\u00e1rios de teste (a\u00e7\u00e3o simples, como preenchimento de formul\u00e1rio, clique em CTA e compra fict\u00edcia) e registre se cada evento \u00e9 enviado uma \u00fanica vez com o event_id correto. Essa auditoria \u00e9 essencial para evitar regress\u00f5es em produ\u00e7\u00e3o.<\/p>\n<h2>Quando esta abordagem faz sentido e quando n\u00e3o faz<\/h2>\n<h3>Quando a deduplica\u00e7\u00e3o baseada em event_id \u00e9 indicada<\/h3>\n<p>Quando voc\u00ea tem controle suficiente sobre o pipeline de envio, especialmente com GTM Server-Side, e precisa manter hist\u00f3rico enquanto elimina duplicatas. A idempot\u00eancia funciona bem em cen\u00e1rios onde as a\u00e7\u00f5es geram eventos repetidos por retrabalho de c\u00f3digo, reenvio de formul\u00e1rios ou redirecionamentos que acionam o mesmo evento v\u00e1rias vezes.<\/p>\n<h3>Quando centralizar no servidor n\u00e3o \u00e9 vi\u00e1vel<\/h3>\n<p>Se a migra\u00e7\u00e3o para GTM Server-Side \u00e9 invi\u00e1vel por custo, complexidade ou prazos, ainda \u00e9 poss\u00edvel reduzir duplicatas com regras no cliente e valida\u00e7\u00f5es simples no lado do recebimento. No entanto, o grau de controle \u00e9 menor e o risco de duplica\u00e7\u00e3o residual aumenta.<\/p>\n<h3>Limites reais em dados offline, CRM e consentimento<\/h3>\n<p>Ao lidar com dados first-party, CRMs e integra\u00e7\u00f5es que dependem de exported events (p. ex., sincroniza\u00e7\u00e3o com BigQuery ou envio de convers\u00f5es offline), lembre-se: nem todo sistema comporta deduplica\u00e7\u00e3o perfeita. Em cen\u00e1rios com Consent Mode v2 ou LGPD, h\u00e1 vari\u00e1veis adicionais que afetam como e quando os eventos s\u00e3o enviados e gravados. \u00c9 comum precisar de uma abordagem h\u00edbrida que combine deduplica\u00e7\u00e3o no recebimento com controles de consentimento na origem.<\/p>\n<h2>Erros comuns com corre\u00e7\u00f5es pr\u00e1ticas<\/h2>\n<h3>Erro comum: n\u00e3o preserva dados hist\u00f3ricos ao tentar deduplicar<\/h3>\n<p>Corre\u00e7\u00e3o pr\u00e1tica: documente exatamente quais eventos e IDs estavam presentes antes da mudan\u00e7a e, se necess\u00e1rio, exporte um snapshot de dados para BigQuery para compara\u00e7\u00e3o. N\u00e3o apague nada existente; apenas filtre duplicatas futuras na ingest\u00e3o.<\/p>\n<h3>Erro comum: event_id mal projetado n\u00e3o \u00e9 \u00fanico<\/h3>\n<p>Corre\u00e7\u00e3o pr\u00e1tica: defina um esquema de event_id que combine uma parte fixa (identificador de origem) com um timestamp de envio em alta resolu\u00e7\u00e3o e um contador local para cada evento \u00fanico por sess\u00e3o.<\/p>\n<h3>Erro comum: depend\u00eancia excessiva de GTM Web sem valida\u00e7\u00e3o do servidor<\/h3>\n<p>Corre\u00e7\u00e3o pr\u00e1tica: implemente uma camada de deduplica\u00e7\u00e3o no GTM Server-Side para todos os eventos que passam pelo servidor; reforce a consist\u00eancia entre o que chega pelo cliente e o que \u00e9 registrado no servidor.<\/p>\n<h2>Quest\u00f5es operacionais: como adaptar \u00e0 realidade do projeto<\/h2>\n<h3>Se voc\u00ea gerencia contas de clientes ou trabalha em ag\u00eancia<\/h3>\n<p>Padronize o uso de event_id entre clientes e cen\u00e1rios de integra\u00e7\u00e3o. Documente as regras de deduplica\u00e7\u00e3o, incluindo como lidar com duplicidade entre GA4, CRM e plataformas de mensagens (WhatsApp). Oriente a equipe de dev a manter uma pol\u00edtica de envio \u00fanica para eventos cr\u00edticos, com o event_id sendo o \u00fanico determinante de \u201cnovo envio\u201d.<\/p>\n<h3>Para squads t\u00e9cnicas com prazos apertados<\/h3>\n<p>Priorize a implementa\u00e7\u00e3o do event_id e a deduplica\u00e7\u00e3o no servidor como primeiro passo. Em paralelo, institucionalize uma rotina de valida\u00e7\u00e3o de dados com BigQuery para monitorar varia\u00e7\u00f5es inesperadas ap\u00f3s cada deploy. Isso reduz o tempo de resposta a incidentes e acelera a confian\u00e7a em dados que alimentam decis\u00f5es de neg\u00f3cio.<\/p>\n<h2>Valida\u00e7\u00e3o e continuidade<\/h2>\n<p>Com o plano em pr\u00e1tica, voc\u00ea precisa de valida\u00e7\u00e3o cont\u00ednua. Use uma rotina de checagem entre GA4, BigQuery e sua camada CRM para confirmar que n\u00e3o h\u00e1 picos an\u00f4malos de eventos repetidos e que os eventos hist\u00f3ricos permanecem inalterados. A implementa\u00e7\u00e3o de GTM Server-Side n\u00e3o \u00e9 apenas uma mudan\u00e7a de infraestrutura; \u00e9 uma mudan\u00e7a de disciplina de dados. Trate-a como uma melhoria de governan\u00e7a de dados, n\u00e3o apenas como uma remenda t\u00e9cnica de curto prazo. A consist\u00eancia entre GA4, Looker Studio e o CRM \u00e9 o que sustenta a confian\u00e7a dos seus stakeholders e evita retrabalho.<\/p>\n<p>Vale mencionar que a integra\u00e7\u00e3o entre GA4 e plataformas como BigQuery facilita a auditoria de duplicatas ao longo do tempo. Em cen\u00e1rios complexos, a combina\u00e7\u00e3o de event_id \u00fanico com exporta\u00e7\u00e3o para BigQuery permite cruzar logs de envio com recibos de entrega no GA4 e no CRM, identificando com precis\u00e3o onde o rastro de dados se rompeu e ajustando o fluxo sem apagar dados hist\u00f3ricos. Para quem busca refer\u00eancias t\u00e9cnicas oficiais, vale consultar a documenta\u00e7\u00e3o de GTM Server-Side e da pilha GA4 para confirmar as melhores pr\u00e1ticas de deduplica\u00e7\u00e3o e envio de eventos.<\/p>\n<p>Para entender melhor a pr\u00e1tica de rastreamento com foco em deduplica\u00e7\u00e3o, confira a documenta\u00e7\u00e3o oficial do GTM Server-Side e recursos de atribui\u00e7\u00e3o de dados da Google. Al\u00e9m disso, conte\u00fados sobre como o GCLID \u00e9 gerado e usado no ecossistema de an\u00fancios ajudam a entender onde a duplica\u00e7\u00e3o tende a nascer e como evit\u00e1-la sem sacrificar a qualidade da atribui\u00e7\u00e3o. <a href=\"https:\/\/developers.google.com\/tag-manager\/serverside\" target=\"_blank\" rel=\"noopener\">GTM Server-Side<\/a> \u2022 <a href=\"https:\/\/support.google.com\/google-ads\/answer\/237544?hl=pt-BR\" target=\"_blank\" rel=\"noopener\">GCLID e auto-tagging no Google Ads<\/a> \u2022 <a href=\"https:\/\/support.google.com\/analytics\/answer\/1008080?hl=pt-BR\" target=\"_blank\" rel=\"noopener\">Medidas de eventos no GA4<\/a> \u2022 <a href=\"https:\/\/www.thinkwithgoogle.com\/intl\/pt-br\/marketing-cloud\/measurement\/\" target=\"_blank\" rel=\"noopener\">Think with Google \u2014 Medi\u00e7\u00e3o e atribui\u00e7\u00e3o<\/a>.<\/p>\n<p>Se quiser uma checagem r\u00e1pida com o seu time, comece revisando se o event_id est\u00e1 presente em todos os envios cr\u00edticos e se ele \u00e9 realmente \u00fanico por envio. Em seguida, valide um conjunto de eventos no GA4 e no BigQuery para confirmar que n\u00e3o h\u00e1 duplicatas que apare\u00e7am apenas em certa janela temporal. A partir da\u00ed, implemente o fluxo de deduplica\u00e7\u00e3o no servidor e adapte os gatilhos de cliente para n\u00e3o disparar mais de uma vez em a\u00e7\u00f5es r\u00e1pidas. O objetivo \u00e9 ter uma linha de base est\u00e1vel \u2014 e, com isso, dados que resistem a auditorias e a escrut\u00ednio de clientes e stakeholders.<\/p>\n<p>Em caso de d\u00favidas espec\u00edficas sobre a integra\u00e7\u00e3o com o seu CRM (HubSpot, RD Station, ou outro) ou com canais de mensagens (WhatsApp Business API), a recomenda\u00e7\u00e3o \u00e9 conduzir uma auditoria de ponta a ponta com um profissional de rastreamento que possa mapear cada ponto de entrada de dados, cada transforma\u00e7\u00e3o no data layer e cada envio para GA4. Mesmo que a corre\u00e7\u00e3o pare\u00e7a simples em teoria, a pr\u00e1tica envolve dozens de pequenos ajustes que, juntos, mant\u00eam a integridade hist\u00f3rica sem interromper a atribui\u00e7\u00e3o.<\/p>\n<p>Se voc\u00ea pretende evoluir para uma arquitetura mais s\u00f3lida, considere documentar internamente seu &#8220;playbook&#8221; de deduplica\u00e7\u00e3o: regras de event_id, gatilhos de envio, crit\u00e9rios de deduplica\u00e7\u00e3o no servidor e rotinas de valida\u00e7\u00e3o de dados. Essa documenta\u00e7\u00e3o facilita a manuten\u00e7\u00e3o, evita retrabalho em campanhas futuras e facilita o onboarding de novos membros da equipe, devs ou clientes. E, claro, se a solu\u00e7\u00e3o exigir mudan\u00e7as estruturais, como a migra\u00e7\u00e3o mais profunda para GTM Server-Side, busque um diagn\u00f3stico t\u00e9cnico espec\u00edfico antes de implementar \u2014 cada cen\u00e1rio tem suas particularidades, e o custo de um erro pode ser alto se n\u00e3o for planejado.<\/p>\n<p>Pr\u00f3ximo passo: leve este plano para a sua equipe de dados e tecnologia, defina um cronograma de implementa\u00e7\u00e3o com entreg\u00e1veis claros e inicie a valida\u00e7\u00e3o com um conjunto de eventos de alto impacto (convers\u00f5es, formul\u00e1rios, chamadas de WhatsApp). O sucesso n\u00e3o est\u00e1 apenas em eliminar duplicatas; est\u00e1 em manter dados hist\u00f3ricos confi\u00e1veis enquanto fornece uma vis\u00e3o clara de performance para o neg\u00f3cio.<\/p>","protected":false},"excerpt":{"rendered":"<p>Duplicidade de eventos no GA4 \u00e9 um dos problemas mais corrosivos de rastreamento que managers de m\u00eddia paga enfrentam hoje. Voc\u00ea investe tempo no GA4, no GTM Web e, \u00e0s vezes, no GTM Server-Side, mas aparece uma repeti\u00e7\u00e3o de envios que distorce a atribui\u00e7\u00e3o, inflige ru\u00eddo ao funil e corr\u00f3i a confian\u00e7a em relat\u00f3rios. O&hellip;<\/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":[20,118,13,14,17],"content_language":[5],"class_list":["post-988","post","type-post","status-publish","format-standard","hentry","category-blogen","tag-bigquery","tag-duplicidade-de-eventos","tag-ga4","tag-gtm-server-side","tag-gtm-web","content_language-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=\/wp\/v2\/posts\/988","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=988"}],"version-history":[{"count":0,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=\/wp\/v2\/posts\/988\/revisions"}],"wp:attachment":[{"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=988"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=988"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=988"},{"taxonomy":"content_language","embeddable":true,"href":"https:\/\/cms.funnelsheet.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcontent_language&post=988"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}