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.
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


Tamanho, validade, acesso e lei em local storage vs cookies
Comparamos local storage vs cookies pelas specs: tamanho, validade, o que vai em cada request, HttpOnly, Secure, SameSite, Safari ITP e ePrivacy.


Como um atributo ausente decide cookie de sessão vs cookie persistente
Comparamos cookie de sessão vs cookie persistente pela RFC 6265 e pelo MDN: Expires e Max-Age, session restore, o teto de 400 dias e o consentimento na UE.


O que sete fornecedores publicam sobre retenção de dados de session replay
Comparamos a retenção de dados de session replay nas docs de FullStory, Hotjar, Clarity, LogRocket, PostHog, Sentry e Datadog, e o que o GDPR exige.


O que o rrweb grava e como funcionam suas opções de privacidade
Como o rrweb grava uma sessão como snapshot do DOM mais mutações, não vídeo: pacotes npm, licença MIT e opções de privacidade como maskAllInputs e blockClass.


O que conta como tráfego de referência e o que silenciosamente não conta
O tráfego de referência é decidido por duas regras. O GA4 lê o medium, o Matomo lê o host do referrer, e o header Referer descarta quase toda a URL.


O que realmente quebra em SameSite Lax vs Strict vs None
Decida entre SameSite Lax vs Strict vs None pelo texto da RFC e pelo padrão documentado do Chrome, incluindo a exigência de Secure e o que cada modo quebra.
Artigos relacionados
Como funciona um pixel de rastreamento e o que ele não consegue ver
O que um pixel de rastreamento entrega ao servidor, o que ele não consegue ler sem um script e por que as taxas de abertura de e-mail passaram a inflar.


Onde os padrões da redação de PII no session replay deixam dados expostos
Os padrões da redação de PII no session replay variam muito: o rrweb mascara só senhas, o Sentry mascara todo o texto e o Clarity mascara números e e-mails.


O que o tráfego Unassigned no GA4 realmente significa
Um canal sem regra correspondente: o tráfego Unassigned no GA4 não é um valor ausente como (not set). As regras do Google explicam a diferença.

