TL;DR, Resposta rápida
8 min de leituraO limite de 7 dias dos cookies no Safari corta qualquer cookie gravado via JavaScript para uma validade de sete dias, não importa qual validade o script pediu. A Intelligent Tracking Prevention do WebKit encurta esse limite para 24 horas quando o cookie é gravado logo depois de um clique entre sites com parâmetros de URL do tipo tracking. Cookies gravados pelo servidor via cabeçalho de resposta Set-Cookie, incluindo cookies HttpOnly, não entram em nenhum dos dois limites.
O que é o limite de 7 dias dos cookies no Safari?
A Intelligent Tracking Prevention da Apple aplica o limite de 7 dias dos cookies no Safari cortando a validade de qualquer cookie gravado via JavaScript para sete dias a partir da criação, não importa a data de validade que o script pediu. Um script que chama document.cookie e pede validade de um ano recebe sete dias em vez disso; o Safari reescreve a validade em silêncio e não devolve nenhum erro para a página que gravou o cookie. O limite vale para o armazenamento do cookie no dispositivo, não para se o site pode continuar pedindo ao visitante que se autentique de novo.
Por que a Apple criou a Intelligent Tracking Prevention?
A Apple construiu a Intelligent Tracking Prevention dentro do WebKit para impedir que rastreadores usassem cookies de longa duração gravados por script como identificador permanente depois que o acesso a cookies entre sites foi restringido. Versões anteriores da ITP bloqueavam cookies third-party que seguiam um visitante por sites sem relação entre si; os rastreadores reagiram gravando o identificador deles em um cookie first-party de cada site via JavaScript, o que continuava funcionando porque um cookie first-party nunca era bloqueado. O limite de 7 dias fechou essa brecha ao fazer qualquer cookie do lado do cliente, first-party ou não, expirar em um relógio curto.

Quando o limite cai para 24 horas em vez de 7 dias?
O WebKit encurta o limite para 24 horas quando um cookie é gravado via JavaScript logo depois de uma navegação entre sites cuja URL carrega decoração de link, como um parâmetro de query usado para passar um ID de clique ou de campanha, e o domínio de origem é um que o classificador embarcado do WebKit marcou como capaz de rastreamento entre sites. Essa regra mira exatamente o padrão que um clique em anúncio produz: um visitante clica em um anúncio, chega por um redirecionamento com um parâmetro de rastreamento, e a página de destino grava esse parâmetro num cookie na hora. Sem o limite mais curto, esse fluxo teria mantido os 7 dias completos.
| Tipo de cookie | Gravado por | Limite da ITP |
|---|---|---|
| Cookie padrão de JavaScript | document.cookie | 7 dias |
| Cookie de JavaScript depois de um clique marcado num link decorado | document.cookie | 24 horas |
| Cookie de resposta do servidor, com qualquer configuração de HttpOnly | Cabeçalho Set-Cookie | Sem limite da ITP |
| Cookie de sessão sem validade definida | Qualquer um dos dois | Fecha com a sessão do navegador, sem limite da ITP |
document.cookie entra no limite; um cookie escrito pelo servidor não.O que sobrevive ao limite de 7 dias dos cookies no Safari?
Cookies gravados diretamente pelo servidor via cabeçalho de resposta Set-Cookie sobrevivem ao limite de 7 dias dos cookies no Safari intactos, já que o limite só reescreve a validade de cookies que uma página grava via JavaScript no lado do cliente. Um cookie de sessão sem atributo Expires ou Max-Age também sobrevive ao limite na prática, já que ele já termina quando a sessão do navegador fecha, antes de sete dias para a maioria dos visitantes. O que não sobrevive é qualquer identificador que um script de rastreamento depende de document.cookie para persistir além de uma semana sem o visitante voltar direto ao site.
Cookies HttpOnly gravados pelo servidor também têm limite?
Não. Um cookie HttpOnly só pode ser criado e lido via cabeçalho de resposta Set-Cookie do servidor, já que o HttpOnly existe justamente para impedir que o JavaScript toque no cookie, e o limite do Safari para cookies de script só vale para cookies que o JavaScript escreveu. Um cookie de sessão de login, um token CSRF, ou qualquer outro cookie que o seu backend grava e marca como HttpOnly mantém a validade que o servidor atribuiu a ele, sem nenhuma reescrita de sete dias ou 24 horas pela ITP.
O que o limite de 7 dias dos cookies no Safari quebra na atribuição?
O limite de 7 dias dos cookies no Safari quebra qualquer modelo de atribuição que depende de um cookie do lado do cliente para ligar um clique em anúncio a uma conversão mais de uma semana depois, e encurta essa janela para um único dia quando o clique carregava uma URL de rastreamento decorada. Uma venda B2B com um ciclo de vendas de três semanas, uma comissão de afiliado reivindicada numa visita de retorno dez dias depois do primeiro clique, ou uma campanha de remarketing que mede uma janela de atribuição de duas semanas perdem, no Safari, o cookie do lado do cliente que teria ligado o clique original à conversão final, bem antes de a conversão acontecer. O visitante não some do site; só some o cookie gravado por JavaScript que teria ligado duas visitas separadas.

Como as equipes contornam o limite de 7 dias dos cookies no Safari?
As equipes contornam o limite de 7 dias dos cookies no Safari movendo a gravação do cookie do JavaScript no lado do cliente para o servidor, já que um cabeçalho de resposta Set-Cookie do seu próprio domínio first-party não entra em nenhum dos dois limites da ITP. O tracking do lado do servidor grava o cookie identificador como parte da resposta HTTP em vez de uma chamada de script, e marcá-lo como HttpOnly tira ele completamente do alcance da ITP e ainda impede que qualquer script do lado do cliente leia ou mexa nele. Revisar quais dos seus cookies first-party e third-party ainda são gravados por JavaScript é o primeiro passo para achar cada identificador que esse limite pode expirar sem avisar.
O outro caminho é parar de depender de qualquer cookie para atribuição. A Flowsery entrega analytics sem cookies e hospedada na UE que conecta sessões a receita sem gravar nenhum identificador num cookie, então as configurações do Safari de um visitante e as regras de validade da Apple não têm nada para expirar desde o início.
Perguntas frequentes
O limite de 7 dias dos cookies no Safari vale para o Chrome ou o Firefox?
Não. Os limites de 7 dias e de 24 horas vêm da Intelligent Tracking Prevention do WebKit, que roda no Safari e em todo navegador construído sobre o WebKit, incluindo o Safari no iOS e no iPadOS. O Chrome e o Firefox rodam seus próprios sistemas de prevenção de rastreamento, separados, com regras diferentes e limites de duração diferente.
Um site pode reiniciar o relógio dos 7 dias do cookie?
Só se o cookie for reescrito pelo servidor via cabeçalho Set-Cookie, ou se o visitante voltar direto ao site e o script da página gravar o cookie de novo antes de os sete dias acabarem; qualquer uma das duas ações começa uma janela nova de sete dias. Um cookie que nunca é renovado antes do sétimo dia expira e some, e o visitante precisa ser identificado de novo como se o cookie nunca tivesse existido.
O limite de 7 dias dos cookies no Safari também bloqueia cookies third-party?
Cookies third-party são bloqueados pelo Safari de cara, sob uma regra separada da ITP, e nunca chegam nem perto da questão dos sete dias. O limite de 7 dias mira especificamente os cookies first-party que o JavaScript grava, que é justo a saída que os rastreadores usaram assim que os cookies third-party pararam de funcionar.
Limpar os dados do site no Safari reinicia o limite do cookie?
Limpar os dados do site apaga o cookie na hora em vez de reiniciar o limite dele, então o site começa do zero na próxima vez que o visitante chega, exatamente como se sete dias já tivessem passado. O limite regula quanto tempo um cookie existente pode viver, não como o cookie se comporta depois de removido manualmente.
O armazenamento local tem o mesmo limite que os cookies?
Esta página cobre só o limite dos cookies, já que é a regra específica descrita aqui. Mecanismos de armazenamento do lado do cliente diferentes de cookies entram em outras partes da Intelligent Tracking Prevention, com condições próprias para quando os dados armazenados de um domínio são apagados, então trate limites de cookies e outros limites de armazenamento como regras separadas em vez de supor que um implica o outro.
Flowsery
Teste gratuito
Painel em tempo real
Rastreamento de metas
Rastreamento sem cookies
Por que alguns sites ainda veem atribuição funcionar além de 7 dias no Safari?
Um site continua funcionando além de sete dias quando nunca dependeu de um cookie gravado por JavaScript para a ligação entre clique e conversão, porque grava o cookie identificador pelo servidor com Set-Cookie, ou porque identifica o visitante de novo por um login em vez de um cookie. Sites que medem conversões sem nenhum cookie, via correspondência de sessão do lado do servidor ou uma abordagem de analytics sem cookies, nunca entram no limite porque não existe cookie gravável por script para a ITP expirar.
O limite de 7 dias dos cookies no Safari vale para cookies que o JavaScript só lê, ou apenas para os que ele grava?
O limite só vale quando o JavaScript grava um cookie por document.cookie, não quando apenas o lê. Um cookie gravado pelo servidor que um script só lê mantém a validade definida pelo cabeçalho Set-Cookie, porque só as gravações feitas por script são reescritas. Cookies HttpOnly eliminam até esse acesso de leitura, mas a regra de gravação já cobre a leitura de qualquer cookie que o JavaScript conseguiria ver de outra forma.
Um link de afiliado ativa o limite de 24 horas em vez do de 7 dias?
Só se o link de afiliado carregar parâmetros de rastreamento decorados, como um ID de clique ou de campanha na URL, e o domínio de referência for um que o classificador do WebKit sinalizou como capaz de rastreamento cross-site. Sem as duas condições, um link de afiliado continua sob o limite padrão de 7 dias para qualquer cookie gravado por JavaScript. O exemplo de afiliado citado neste post, uma comissão reivindicada dez dias após o primeiro clique, já fica fora da janela de 7 dias, então o limite mais curto só pioraria essa lacuna.
O limite de 7 dias dos cookies no Safari também vale para scripts de analytics third-party?
Sim, se o script gravar o cookie por document.cookie no próprio domínio da página, porque o limite de 7 dias cobre qualquer cookie definido no lado do cliente, first-party ou não. O que importa para o ITP é como o cookie foi gravado, não qual empresa escreveu o script. Uma tag de analytics third-party que ainda depende de document.cookie para seu identificador perde esse identificador em sete dias, do mesmo jeito que um script de rastreamento first-party.
O limite de 24 horas pode encurtar um cookie que já existia antes do clique no anúncio?
O limite de 24 horas só entra em ação para um cookie gravado logo depois do próprio clique cross-site decorado; ele não age para trás sobre um cookie que já existia no dispositivo. Um cookie gravado pelo JavaScript antes de o visitante clicar no anúncio continua sob o limite que valia quando foi criado, geralmente o padrão de 7 dias. O clique pode iniciar um cookie novo e mais limitado, mas não altera de forma retroativa um que já está em contagem.
Este artigo foi útil?
Diga-nos o que pensa!
Veja-nos mais no Google
Um clique marca a Flowsery como fonte preferida e nossos artigos passam a aparecer mais acima nas suas Principais notícias, no modo IA e nas visões gerais com IA.
Antes de ir...
Flowsery
Analytics orientado para receitas para o seu site
Rastreie cada visitante, fonte e conversão em tempo real. Simples, poderoso e sem cookies.
Painel em tempo real
Rastreamento de metas
Rastreamento sem cookies
Termos relacionados do glossário


Por que o tráfego direto é o balde de tudo que o analytics não conseguiu atribuir
Sessões caem no tráfego direto quando referrer e tag de campanha não sobrevivem ao salto. As causas: políticas de referrer, apps, PDFs, redirects, QR codes.


Como funciona o web analytics, e onde ele para
Uma definição direta de web analytics, o que um script de rastreamento coleta, as métricas principais e suas leituras erradas.


Como funciona o session replay e o que ele não vê
O session replay reconstrói uma visita a partir de mutações do DOM e eventos de entrada, não de vídeo. Veja o que captura, o que o mascaramento esconde.


O que estes números revelam sobre a taxa de rejeição média por setor
Nove setores rastreados mostram uma taxa de rejeição média por setor documentada, entre 35.76% e 48.38%, segundo dados da Databox de setembro de 2024.


Como aplicar a fórmula do valor médio do pedido passo a passo
A fórmula do valor médio do pedido divide a receita total pelos pedidos, e um único cupom de desconto pode distorcer cada número que uma equipe reporta.


O que a duração média de sessão realmente mede
Na analytics clássica, a duração média de sessão dá zero tempo registrado à última página vista de cada sessão, o que puxa a média para baixo silenciosamente.
Artigos relacionados


Por que beforeunload vs pagehide decide se o analytics sobrevive
Comparar beforeunload vs pagehide mostra por que o celular pula beforeunload, bloqueia o bfcache e pagehide envia dados de forma confiável com sendBeacon.


Como a impressão digital do navegador te identifica sem um cookie
Canvas, fontes instaladas, tamanho de tela e fuso horário, combinados pela impressão digital do navegador em um identificador que sobrevive à exclusão.


O modelo de relatório de bug que nenhum revisor rejeita
Um modelo de relatório de bug nomeia cada campo que um revisor espera, dos passos para reproduzir até a gravidade, ou o ticket incompleto é rejeitado.

