Sesiones de visitantes en PrestaShop: datos, privacidad e integraciones
Conoce el seguimiento compartido de visitantes: datos recopilados, límites de atribución y consentimiento, políticas de limpieza y API de integración.
Comprende los datos de visitantes que recopilan tus módulos antes de utilizar el seguimiento compartido de sesiones. Define su finalidad, los límites de acceso y la conservación por separado de las cookies y los registros que permiten funcionar al proceso de compra.
Qué haríamos
Primero anotaríamos qué decisión debe respaldar el seguimiento y comprobaríamos si tus registros actuales ya permiten tomarla. El alcance adecuado depende de los módulos e integraciones instalados, el tema, los datos ya recopilados, los mercados y el equipo que utilizará los resultados. Acuerda quién se responsabiliza del servicio compartido antes de añadir otro recopilador.
Aplica los cambios de recopilación o del paquete en una copia privada de pruebas equivalente a la tienda en producción. Usa identidades de prueba y aísla los envíos a analítica, publicidad, correo y otras integraciones de producción. Ensaya las comprobaciones siguientes y planifica el paso a producción con el código y los ajustes anteriores disponibles y una persona designada para comprobar el resultado.
| Tu necesidad | Opción inicial | Pruebas que debes solicitar |
|---|---|---|
| Mantener operativos el inicio de sesión, los carritos o las descargas. | Investiga el flujo comercial correspondiente antes de añadir seguimiento de visitantes. | Un fallo reproducible cuyo origen se haya rastreado en las comprobaciones de autenticación, carrito o derechos de acceso. |
| Entender un abuso o una interrupción del proceso de compra. | Utiliza primero el contexto existente de la integración correspondiente; añade detalles solo para una cuestión de diagnóstico definida. | Un recorrido de prueba vinculado a los registros que explican el incidente. |
| Atribuir campañas o medir un embudo de conversión. | Define los eventos previstos y el comportamiento del consentimiento antes de activar la recopilación opcional. | Eventos y campos esperados contrastados con las escrituras observadas en cada estado de consentimiento. |
| Crear informes separados para varias tiendas. | Determina cómo se asigna cada evento a una tienda antes de crear el informe. | Una prueba que demuestre que un informe o una exportación no puede incluir actividad de otra tienda sin autorización. |
Si necesitas desarrollar un recopilador o una integración a medida, PrestaShop Custom Module Development Service puede definir el alcance del flujo necesario y las comprobaciones de aceptación.
Separa el seguimiento de visitantes de la autenticación
PrestaShop utiliza cookies, registros de carrito en la base de datos y mecanismos de autenticación y sesión para que la tienda funcione. Un paquete compartido de seguimiento de visitantes añade registros para analítica, contexto de seguridad y flujos de trabajo de los módulos participantes. No sustituye la autenticación del cliente ni almacena el contenido del carrito como archivos de sesión PHP.
El paquete myprestarocks/prestashop-session utiliza el espacio de nombres MyPrestaRocks\Session. Los módulos participantes pueden reutilizar tablas como mpr_sessions, con el prefijo configurado en la base de datos de la tienda. Compartir una tabla permite reutilizar el contexto del visitante, pero cada integración decide cuándo crearlo, actualizarlo o leerlo. Contrasta el esquema, los valores predeterminados de la API y el comportamiento de recopilación descritos a continuación con la versión del paquete que carga realmente tu tienda.
Las tablas se comparten dentro de la base de datos que utiliza la instalación. Esto no crea seguimiento entre sitios de tiendas independientes. La tabla base de sesiones no tiene columna id_shop y varios métodos de búsqueda operan sobre toda esa tabla. Aplica límites explícitos de contexto y acceso al crear informes o integraciones multitienda.
Para la integración del proceso de compra, utiliza la página de ayuda de Checkout Revolution; para la recopilación de seguridad y el mantenimiento, utiliza la página de ayuda de Security Revolution; para los flujos de productos digitales, utiliza la página de ayuda de Digital Revolution.
Conoce qué datos puede almacenar la integración
El esquema compartido admite las siguientes categorías. Los datos realmente incorporados dependen del módulo que llama y de las funciones activadas.
| Categoría | Ejemplos |
|---|---|
| Vínculos de identidad | ID/hash de sesión, ID de invitado e ID de cliente opcional |
| Red y dispositivo | Dirección IP completa, prefijo IP derivado, país, user-agent sin procesar, hash del user-agent, navegador, sistema operativo y clase de dispositivo |
| Clasificación | Indicadores de bot y de verificación JavaScript, información de red/ASN, indicadores de centro de datos/anonimizador, puntuaciones de comportamiento y marcas de tiempo de clasificación |
| Atribución | Detalle del origen y de la página de procedencia, parámetros UTM, gclid, fbclid, msclkid y ttclid |
| Contexto de visita | URL/tipo/ID de entrada, idioma, moneda, indicador de primera visita, número de páginas, última página y horas de actividad |
| Vistas de página detalladas | Vínculo con la sesión, tipo/ID de página, controlador, URL y marca de tiempo en mpr_page_views |
| Acciones del carrito | ID de carrito, producto y combinación, acción de añadir/eliminar/actualizar/vale, cantidades, nombre/precio de producto opcionales y marca de tiempo en mpr_cart_actions |
Las tablas relacionadas de eventos analíticos y agregados pueden contener datos adicionales del embudo. Incluye esas tablas en tu inventario de datos cuando una integración las utilice.
La función auxiliar de URL puede capturar la ruta y la cadena de consulta de una solicitud. Evita que las URL almacenadas contengan tokens, direcciones de correo y otros datos personales innecesarios. Por ejemplo, depura la copia para seguimiento de las URL de restablecimiento de contraseña y de retorno del pago antes de almacenarla, mediante una lista de parámetros permitidos. Conserva los parámetros originales de la solicitud para el gestor de restablecimiento de contraseña o de pago. Limita los campos recopilados a la finalidad que has definido.
Un hash determinista del user-agent o un hash de sesión no demuestra que los datos sean anónimos. Las direcciones IP completas y los vínculos con invitados, clientes o historiales de eventos requieren controles adecuados de acceso y conservación.
Trata la atribución y las etiquetas de bots como señales
Los módulos pueden buscar una sesión activa por hash o ID de invitado. El paquete también permite buscar una sesión reciente que no sea de un bot por dirección IP. Su búsqueda alternativa por IP no exige que coincida el agente de usuario. Por tanto, una red compartida, un proxy o una IP cambiante pueden volver ambigua la atribución. Por ejemplo, varios compañeros que navegan desde la misma oficina pueden tener registros de invitado distintos detrás de una misma IP pública. Reproduce el recorrido con perfiles de navegador separados, inspecciona la sesión seleccionada y comprueba qué búsqueda la proporcionó; no combines sus historiales para que un informe basado en IP parezca coherente.
Utiliza un contexto de invitado o cliente de confianza para las operaciones comerciales. Nunca utilices una coincidencia de IP, un hash de visitante, una etiqueta de dispositivo o un registro de seguimiento como autorización para acceder a una cuenta, dirección, pedido o descarga.
El trait de sesiones proporciona heurísticas de user-agent y una detección aproximada de navegador, dispositivo y sistema operativo. El procesamiento opcional de reputación y comportamiento puede añadir señales de red y actividad. Los user-agents se pueden falsificar, las etiquetas pueden ser incorrectas y las heurísticas pueden quedar desactualizadas. Revisa las clasificaciones antes de utilizarlas para restricciones con consecuencias relevantes.
El indicador de primera visita de la integración del proceso de compra comprueba si existe una fila para ese invitado. Los restablecimientos de cookies, la limpieza por conservación y un dispositivo diferente pueden cambiar el resultado. Es un indicador de reconocimiento para los registros disponibles, no una identificación garantizada de la misma persona entre días o dispositivos.
El seguimiento del proceso de compra se vincula a una identidad comercial establecida, como un cliente con sesión iniciada o un carrito que contiene productos, según sus ajustes y reglas de solicitud. El seguimiento de seguridad tiene sus propias reglas de invitados, tiempos de espera y exclusiones. No des por hecho que los módulos creen exactamente los mismos registros en todas las páginas.
Define finalidades, consentimiento y acceso
Separa las finalidades de mantener operativo el proceso de compra, detectar abusos, medir visitas y atribuir publicidad. Evalúa la base jurídica aplicable y las reglas de consentimiento para rastreadores de cada uso real. Compartir una tabla técnica no hace que todos los usos sean necesarios para el proceso de compra.
El GDPR exige limitación de la finalidad, minimización de datos, seguridad adecuada y limitación del plazo de conservación. Configura tus avisos, controles de acceso, gestión de derechos y conservación según los datos que realmente tratas.
Las funciones auxiliares de tablas del paquete son API de acceso a datos. La integración que las llama debe aplicar la finalidad, el consentimiento cuando sea necesario, la autorización y la minimización antes de recopilar o utilizar datos. La ruta de atribución publicitaria del proceso de compra lee un estado de consentimiento limitado a la tienda y gestiona su retirada por separado de la identidad comercial básica. Si se siguen escribiendo campos de atribución sujetos a consentimiento tras el rechazo, rastrea la solicitud y el módulo que los escriben: cambiar la visualización de un banner no demuestra que la recopilación en el servidor respete la elección.
- Enumera cada recopilador, tabla, campo, cookie y destinatario posterior.
- Decide qué funciones pueden ejecutarse antes de una decisión de consentimiento y cuáles requieren permiso.
- Utiliza un navegador sin datos previos para probar el consentimiento antes de elegir, después de rechazar, después de aceptar y después de revocar.
- Inspecciona las solicitudes, las cookies y las filas de la base de datos después de cada decisión.
- Verifica que la recopilación opcional se detenga cuando sea obligatorio mientras el proceso de compra siga siendo utilizable.
- Restringe el acceso del personal y a informes, y prueba la exportación o supresión de datos del cliente en todos los conjuntos de registros vinculados.
Las exenciones de consentimiento para medición de audiencia tienen condiciones específicas y pueden variar según la jurisdicción. No deduzcas una exención del alojamiento propio ni del uso de hashes. Utiliza la guía de privacidad de PrestaShop al planificar el flujo de trabajo más amplio.
Configura la limpieza y verifica la eliminación
La conservación solo se aplica cuando la tarea de limpieza pertinente se ejecuta correctamente. Un tiempo de espera de sesión determina si un registro se considera activo; es independiente de cuánto tiempo conserva ese registro la base de datos.
| Punto de entrada del paquete | Comportamiento predeterminado |
|---|---|
| SessionInstaller::cleanAll() | 24 horas para sesiones inactivas, 24 horas para la antigüedad de las vistas de página y 168 horas para la antigüedad de las acciones del carrito. |
| SessionInstaller::cleanAllSmart() | 24 horas para la inactividad de bots, 2160 horas para la inactividad general de sesiones y la antigüedad de vistas de página, y 720 horas para la antigüedad de acciones del carrito. También elimina vistas de página huérfanas. |
| SessionTable::cleanOldSessionsSmart() llamado directamente | Sus propios valores predeterminados son 24 horas para bots y 72 horas para el umbral general de inactividad. |
Son valores predeterminados de la API, no una política de privacidad prescrita. Un consumidor puede pasar valores diferentes. El mantenimiento de Security Revolution utiliza sus valores configurados de conservación de bots, sesiones reales y acciones del carrito. La limpieza de otro consumidor puede utilizar una marca de tiempo diferente, así que identifica todas las tareas que puedan eliminar filas compartidas.
La conservación basada en actividad puede mantener una sesión que se actualiza activamente durante más tiempo que un periodo fijo desde su creación. La antigüedad de las vistas de página detalladas se limita por separado mediante la envoltura inteligente. Incluye otras tablas de eventos, agregados, exportaciones, registros de aplicación y copias de seguridad en el plan de conservación; limpiar las tres tablas principales de seguimiento no define su duración.
- Registra el componente que llama realmente, los argumentos, la programación y la versión del paquete cargada.
- Elige valores de conservación para tus finalidades documentadas.
- Ejecuta la limpieza en el entorno de pruebas e inspecciona las filas eliminadas y los fallos. Incluye una sesión antigua con actividad reciente, una sesión inactiva caducada y una vista de página cuyo registro padre ya no exista; compara el resultado con el punto de entrada elegido.
- Confirma que los registros caducados y huérfanos se eliminan según lo programado en producción. Registra la última finalización correcta y las cantidades eliminadas, y asigna a alguien la investigación de los fallos; que el programador inicie la tarea no demuestra que la eliminación haya terminado.
- Comprueba que los flujos de eliminación y exportación cubran los vínculos de invitados y clientes además de las copias posteriores.
Las funciones auxiliares de desinstalación de tablas compartidas conservan las tablas mientras se detecte otro módulo instalado que incluya el paquete. Eliminar un módulo no equivale a borrar todos los datos compartidos de visitantes. Revisa los consumidores restantes antes de eliminar tablas compartidas.
Utiliza la API del paquete con límites explícitos
La API proporciona funciones auxiliares para la instalación de tablas, la búsqueda, la vinculación, el registro y la limpieza. Mantén compatibles las versiones del paquete entre los módulos participantes y prueba qué implementación resuelve el autocargador.
| API | Función |
|---|---|
| SessionInstaller::installAll() | Instala las tablas compartidas de sesiones, vistas de página, acciones del carrito y soporte de tráfico. |
| SessionTable::getActiveSessionByGuest() | Busca una sesión reciente de un invitado conocido. Ventana de actividad predeterminada: 60 minutos. |
| SessionTable::getActiveSessionId() | Busca una fila activa por hash de sesión. |
| SessionTable::linkGuestToCustomer() | Vincula registros de invitado previamente no vinculados a un cliente proporcionado por el componente autorizado que llama. |
| SessionTable::trackPageView() | Incrementa los contadores de páginas de la sesión y actualiza la actividad. |
| PageViewsTable::trackPageView() | Escribe una fila detallada de vista de página cuando se pretenda ese nivel de registro. |
| CartActionsTable::trackCartAction() | Registra las acciones admitidas de carrito o vale. |
| AttributionContext::capture() | Construye un contenedor de identidad y atribución. Revisa la entrada y los campos devueltos antes de almacenarlos o transmitirlos. |
Si un informe muestra un contador de páginas de sesión creciente pero ningún historial detallado, rastrea qué API de vistas de página llama la integración antes de considerarlo una pérdida de datos. Decide si los contadores o los eventos individuales responden a tu pregunta antes de activar más recopilación.
Estas llamadas no sustituyen la comprobación de titularidad o consentimiento. No expongas ID arbitrarios de sesión o cliente a un endpoint público. Utiliza el contexto actual autenticado o autorizado por otra vía y gestiona las tablas ausentes o las escrituras fallidas.
Antes de activar una integración, prueba la reutilización de sesiones, la vinculación de invitado a cliente, el ámbito multitienda, el rechazo y la revocación del consentimiento, los fallos de limpieza y la desinstalación mientras otro módulo siga utilizando el servicio de sesiones compartido. Evita que los fallos del seguimiento opcional interrumpan las compras o los inicios de sesión.
Ensaya el cambio y documenta el traspaso
- Antes de la primera solicitud o ejecución de prueba, verifica que las conexiones utilizan la base de datos de pruebas, desactiva las tareas programadas copiadas y aísla los destinatarios externos. Activa solo las tareas aisladas necesarias para el ensayo.
- Registra las versiones instaladas de PrestaShop y PHP, las versiones de los módulos participantes y el archivo del paquete cargado. Conserva la configuración y la estructura de la base de datos necesarias para reproducir la prueba.
- En la copia aislada, realiza las comprobaciones anteriores de consentimiento, identidad y limpieza con tu tema real y las integraciones activadas. Registra las escrituras esperadas, los registros observados y los mensajes enviados a otros sistemas sin copiar secretos en el informe de prueba.
- Desactiva un recopilador opcional y repite el recorrido de compra. Comprueba que los demás consumidores siguen funcionando y distingue entre detener la nueva recopilación y eliminar registros existentes.
- Acuerda quién despliega, quién comprueba los registros resultantes y qué resultado obliga a revertir el cambio. Utiliza una reversión de código o configuración que conserve los pedidos realizados desde el cambio; restaurar la base de datos exige un plan de recuperación separado.
- Tras el cambio, compara un recorrido controlado en producción con las pruebas del entorno de pruebas y confirma que la siguiente limpieza termina. Conserva las definiciones de registros acordadas y el procedimiento operativo junto con la documentación de traspaso de la tienda.
Qué preguntar a tu desarrollador o agencia
- ¿Puedes mostrar qué archivo del paquete se carga al activar los módulos participantes en distintas combinaciones?
- ¿Dónde se filtran los parámetros de URL antes de almacenarlos y puedes demostrar que un secreto de prueba nunca llega a una tabla, registro o exportación?
- ¿Quién recibe la alerta de un fallo de limpieza y dónde está el procedimiento para investigarlo?
- ¿Con qué destinatario hay que contactar si una exportación ya ha salido de la tienda y cómo se confirma su eliminación o corrección?
Preguntas de los propietarios
¿Esto permite grabar la pantalla?
Los registros de vistas de página y acciones del carrito describen eventos registrados, no una grabación de la pantalla. Si necesitas reproducir sesiones, evalúa los controles de captura, enmascaramiento y acceso de la herramienta correspondiente en lugar de suponer que estas tablas lo proporcionan.
¿Por qué difieren los totales de sesiones de otro informe de analítica?
Compara periodos, zonas horarias, grupos con consentimiento, exclusiones de bots y la definición de sesión antes de interpretar la diferencia como tráfico perdido. Concilia las ventas con los registros de pedidos y pagos en lugar de forzar la coincidencia de los totales de visitantes.
¿Alargar el tiempo de seguimiento evitará que se cierre la sesión de los clientes?
Investiga primero el flujo de autenticación y sus cookies. Una ventana de seguimiento de visitantes más larga no demuestra que se haya reparado el inicio de sesión de la cuenta o la recuperación del carrito.
¿Quién es responsable si distintas agencias mantienen los módulos?
Designa un responsable por parte de la tienda para el inventario compartido de datos y la aprobación de cambios. Cada mantenedor debe documentar su recopilador, quién llama a la limpieza y sus destinatarios, para poder evaluar un cambio de una agencia frente a las demás integraciones.