TL;DR, Respuesta rápida
9 min de lecturaEl límite de 7 días de cookies de Safari recorta cualquier cookie puesta mediante JavaScript a una caducidad de siete días, sin importar la caducidad que el script haya pedido. La Intelligent Tracking Prevention de WebKit acorta ese límite a 24 horas cuando la cookie se pone justo después de un clic entre sitios que lleva parámetros de URL de tipo tracking. Las cookies que pone el servidor mediante un encabezado de respuesta Set-Cookie, incluidas las cookies HttpOnly, no están sujetas a ninguno de los dos límites.
¿Qué es el límite de 7 días de cookies de Safari?
La Intelligent Tracking Prevention de Apple impone el límite de 7 días de cookies de Safari recortando la caducidad de cualquier cookie puesta mediante JavaScript a siete días desde su creación, sin importar la fecha de caducidad que el script haya pedido. Un script que llama a document.cookie y pide una caducidad de un año recibe siete días en su lugar; Safari reescribe la caducidad en silencio y no devuelve ningún error a la página que puso la cookie. El límite se aplica al almacenamiento de la cookie en el dispositivo, no a si el sitio puede seguir pidiendo al visitante que se autentique de nuevo.
¿Por qué introdujo Apple la Intelligent Tracking Prevention?
Apple construyó la Intelligent Tracking Prevention dentro de WebKit para impedir que los rastreadores usaran cookies de larga duración puestas por script como identificador persistente una vez que se restringió el acceso entre sitios a las cookies. Versiones anteriores de ITP bloqueaban las cookies third-party que rastreaban a un visitante entre sitios sin relación; los rastreadores respondieron escribiendo su identificador en una cookie first-party de cada sitio mediante JavaScript, lo que seguía funcionando porque una cookie first-party nunca se bloqueaba. El límite de 7 días cerró ese hueco haciendo que cualquier cookie del lado del cliente, first-party o no, caduque en un reloj corto.

¿Cuándo baja el límite a 24 horas en vez de 7 días?
WebKit acorta el límite a 24 horas cuando una cookie se pone mediante JavaScript justo después de una navegación entre sitios cuya URL lleva decoración de enlace, como un parámetro de consulta usado para transmitir un ID de clic o de campaña, y el dominio de referencia es uno que el clasificador en el dispositivo de WebKit ha marcado como capaz de rastreo entre sitios. Esta regla apunta exactamente al patrón que produce un clic en un anuncio: un visitante hace clic en un anuncio, aterriza a través de una redirección que lleva un parámetro de tracking, y la página de aterrizaje escribe de inmediato ese parámetro en una cookie. Sin el límite más corto, ese flujo habría conservado los 7 días completos.
| Tipo de cookie | Puesta por | Límite de ITP |
|---|---|---|
| Cookie estándar de JavaScript | document.cookie | 7 días |
| Cookie de JavaScript tras un clic marcado en un enlace decorado | document.cookie | 24 horas |
| Cookie de respuesta del servidor, con cualquier ajuste de HttpOnly | Encabezado Set-Cookie | Sin límite de ITP |
| Cookie de sesión sin caducidad definida | Cualquiera de las dos | Termina con la sesión del navegador, sin límite de ITP |
document.cookie cae bajo el límite; una cookie escrita por el servidor no.¿Qué sobrevive al límite de 7 días de cookies de Safari?
Las cookies que pone directamente el servidor mediante un encabezado de respuesta Set-Cookie sobreviven al límite de 7 días de cookies de Safari sin verse afectadas, ya que el límite solo reescribe la caducidad de las cookies que una página pone mediante JavaScript del lado del cliente. Una cookie de sesión sin atributo Expires ni Max-Age también sobrevive al límite en la práctica, ya que de todos modos termina cuando se cierra la sesión del navegador, antes de siete días para la mayoría de los visitantes. Lo que no sobrevive es cualquier identificador que un script de tracking dependa de document.cookie para persistir más de una semana sin que el visitante vuelva directamente al sitio.
¿Las cookies HttpOnly puestas por el servidor también tienen límite?
No. Una cookie HttpOnly solo se puede crear y leer mediante un encabezado de respuesta Set-Cookie del servidor, ya que HttpOnly existe justamente para impedir que JavaScript toque la cookie por completo, y el límite de Safari para cookies de script solo se aplica a las cookies que escribió JavaScript. Una cookie de sesión de inicio de sesión, un token CSRF o cualquier otra cookie que tu backend ponga y marque como HttpOnly conserva la caducidad que le asignó el servidor, sin ninguna reescritura de siete días o 24 horas por parte de ITP.
¿Qué rompe el límite de 7 días de cookies de Safari en la atribución?
El límite de 7 días de cookies de Safari rompe cualquier modelo de atribución que dependa de una cookie del lado del cliente para conectar un clic en un anuncio con una conversión más de una semana después, y acorta esa ventana a un solo día cuando el clic llevaba una URL de tracking decorada. Una venta B2B con un ciclo de venta de tres semanas, una comisión de afiliado reclamada en una visita de retorno diez días después del primer clic, o una campaña de remarketing que mide una ventana de atribución de dos semanas pierden en Safari la cookie del lado del cliente que habría conectado el clic original con la eventual conversión, mucho antes de que la conversión suceda siquiera. El visitante no se pierde del sitio; solo desaparece la cookie puesta por JavaScript que habría conectado dos visitas separadas.

¿Cómo evitan los equipos el límite de 7 días de cookies de Safari?
Los equipos evitan el límite de 7 días de cookies de Safari trasladando el paso de poner la cookie de JavaScript del lado del cliente al servidor, ya que un encabezado de respuesta Set-Cookie desde tu propio dominio first-party no está sujeto a ninguno de los dos límites de ITP. El tracking del lado del servidor pone la cookie identificadora como parte de la respuesta HTTP en lugar de mediante una llamada de script, y marcarla como HttpOnly la saca por completo del alcance de ITP además de impedir que cualquier script del lado del cliente la lea o la manipule. Revisar cuáles de tus cookies first-party y third-party todavía las pone JavaScript es el primer paso para encontrar cada identificador que este límite puede hacer caducar sin avisar.
El otro camino es dejar de depender de cualquier cookie para la atribución. Flowsery ofrece analítica sin cookies alojada en la UE que conecta las sesiones con los ingresos sin escribir ningún identificador en una cookie, así que la configuración de Safari de un visitante y las reglas de caducidad de Apple no tienen nada que hacer caducar desde el principio.
Preguntas frecuentes
¿El límite de 7 días de cookies de Safari se aplica también a Chrome o Firefox?
No. Los límites de 7 días y de 24 horas vienen de la Intelligent Tracking Prevention de WebKit, que corre en Safari y en todo navegador basado en WebKit, incluido Safari en iOS y iPadOS. Chrome y Firefox usan sus propios sistemas de prevención de rastreo, separados, con reglas distintas y límites de distinta duración.
¿Puede un sitio reiniciar el reloj de la cookie de 7 días?
Solo si el servidor reescribe la cookie mediante un encabezado Set-Cookie, o si el visitante vuelve directamente al sitio y el script de la página vuelve a escribir la cookie antes de que se agoten los siete días; cualquiera de las dos acciones inicia una ventana nueva de siete días. Una cookie que nunca se renueva antes del séptimo día caduca y desaparece, y hay que volver a identificar al visitante como si la cookie nunca hubiera existido.
¿El límite de 7 días de cookies de Safari también bloquea las cookies third-party?
Las cookies third-party las bloquea Safari por completo bajo una regla de ITP distinta y nunca llegan siquiera a la cuestión de los siete días. El límite de 7 días apunta específicamente a las cookies first-party que pone JavaScript, que es justo la salida a la que recurrieron los rastreadores cuando las cookies third-party dejaron de funcionar.
¿Borrar los datos del sitio web de Safari reinicia el límite de la cookie?
Borrar los datos del sitio elimina la cookie de inmediato en lugar de reiniciar su límite, así que el sitio arranca desde cero la próxima vez que llegue el visitante, exactamente como si ya hubieran pasado siete días. El límite regula cuánto puede vivir una cookie existente, no cómo se comporta la cookie una vez que se ha eliminado manualmente.
¿El almacenamiento local tiene el mismo límite que las cookies?
Esta página cubre solo el límite de las cookies, porque es la regla específica que se describe aquí. Los mecanismos de almacenamiento del lado del cliente distintos de las cookies caen bajo otras partes de la Intelligent Tracking Prevention, con sus propias condiciones para cuándo se borran los datos almacenados de un dominio, así que trata los límites de cookies y los demás límites de almacenamiento como reglas separadas en vez de asumir que uno implica el otro.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
¿Por qué en algunos sitios la atribución sigue funcionando en Safari más allá de 7 días?
Un sitio sigue funcionando más allá de siete días cuando nunca dependió de una cookie puesta por JavaScript para el enlace entre el clic y la conversión, porque pone la cookie identificadora desde el servidor con Set-Cookie, o porque vuelve a identificar al visitante mediante un inicio de sesión en lugar de una cookie. Los sitios que miden conversiones sin ninguna cookie, mediante emparejamiento de sesión del lado del servidor o un enfoque de analítica sin cookies, nunca están sujetos al límite porque no hay ninguna cookie escribible por script que ITP pueda hacer caducar.
¿El límite de 7 días de cookies de Safari se aplica a las cookies que JavaScript solo lee, o solo a las que pone?
El límite solo se aplica cuando JavaScript escribe una cookie mediante document.cookie, no cuando la lee. Una cookie puesta por el servidor que un script solo lee conserva la caducidad que asignó la cabecera Set-Cookie, porque solo las escrituras del script se reescriben. Las cookies HttpOnly eliminan incluso ese acceso de lectura, pero la regla de escritura ya cubre la lectura de cualquier cookie que JavaScript pueda ver.
¿Un enlace de afiliado activa el límite de 24 horas en vez del de 7 días?
Solo si el enlace de afiliado lleva parámetros de seguimiento decorados, como un ID de clic o de campaña en la URL, y el dominio de referencia es uno que el clasificador de WebKit ha marcado con capacidad de rastreo cross-site. Sin ambas condiciones, un enlace de afiliado sigue bajo el límite estándar de 7 días para cualquier cookie puesta por JavaScript. El ejemplo de afiliado de este artículo, una comisión reclamada diez días después del primer clic, ya se queda fuera de la ventana de 7 días, así que el límite más corto solo empeoraría esa brecha.
¿El límite de 7 días de cookies de Safari también se aplica a los scripts de analítica third-party?
Sí, si el script escribe su cookie mediante document.cookie en el propio dominio de la página, porque el límite de 7 días cubre cualquier cookie del lado del cliente, sea first-party o no. Lo que importa para ITP es cómo se puso la cookie, no qué empresa escribió el script. Una etiqueta de analítica third-party que todavía depende de document.cookie para su identificador pierde ese identificador a los siete días, igual que un script de tracking first-party.
¿Puede el límite de 24 horas acortar una cookie que ya existía antes del clic en el anuncio?
El límite de 24 horas solo entra en juego con una cookie puesta justo después del propio clic cross-site decorado; no actúa hacia atrás sobre una cookie que ya existía en el dispositivo. Una cookie que JavaScript escribió antes de que el visitante hiciera clic en el anuncio sigue bajo el límite que aplicaba cuando se creó, normalmente el de 7 días estándar. El clic puede iniciar una cookie nueva y más limitada, pero no toca de forma retroactiva una que ya está corriendo.
¿Te resultó útil este artículo?
¡Cuéntanos qué opinas!
Vernos más en Google
Un clic marca Flowsery como fuente preferida y nuestros artículos aparecen más arriba en tus Noticias destacadas, el modo IA y los resúmenes con IA.
Antes de irte...
Flowsery
Analítica orientada a ingresos para tu sitio web
Rastrea cada visitante, fuente y conversión en tiempo real. Simple, potente y sin cookies.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Términos relacionados del glosario


Tamaño, caducidad, acceso y ley en almacenamiento local vs cookies
Comparamos almacenamiento local vs cookies según las especificaciones: tamaño, caducidad, envío al servidor, HttpOnly, Secure, SameSite, Safari ITP y ePrivacy.


Cómo un solo atributo ausente decide cookie de sesión vs cookie persistente
Qué separa cookie de sesión vs cookie persistente en RFC 6265 y MDN: Expires y Max-Age, sesiones restauradas, el tope de 400 días y el consentimiento en la UE.


Lo que publican siete proveedores sobre la retención de datos de session replay
Comparamos la retención de datos de session replay según la documentación de FullStory, Hotjar, Clarity, LogRocket, PostHog, Sentry y Datadog, y el GDPR.


Qué graba rrweb y cómo funcionan sus opciones de privacidad
Cómo rrweb graba una sesión como snapshot del DOM más mutaciones, no como vídeo: sus paquetes npm, la licencia MIT y opciones como maskAllInputs y blockClass.


Qué cuenta como tráfico de referencia y qué se queda fuera sin avisar
Dos reglas distintas deciden el tráfico de referencia. GA4 lee el medio, Matomo lee el host del referrer y la cabecera Referer pierde casi toda la URL.


Qué se rompe de verdad con SameSite Lax vs Strict vs None
Cómo decidir SameSite Lax vs Strict vs None con el texto del RFC y el valor por defecto que Chrome documenta, el requisito Secure y qué mata cada modo.
Artículos relacionados
Cómo funciona un píxel de seguimiento y qué no puede ver
Un píxel de seguimiento es una petición de imagen 1x1 que reporta una vista. Qué recibe el servidor, qué no lee sin script y por qué se inflan las aperturas.


Dónde los valores por defecto de la redacción de PII en session replay dejan datos expuestos
Los valores por defecto de la redacción de PII en session replay varían: rrweb solo enmascara contraseñas, Sentry todo el texto, Clarity números y correos.


Qué significa realmente el tráfico Unassigned en GA4
Un canal sin regla que lo recoja: el tráfico Unassigned en GA4 no es un valor ausente como (not set). Las reglas de Google explican la diferencia.

