Preguntas frecuentes sobre las fuentes de datos

Preguntas más frecuentes sobre las fuentes de datos.

¿Deben ser únicos los nombres de las fuentes?

Los nombres de los archivos de fuente de datos se componen del ID del grupo de informes y de la fecha. Las dos fuentes que estén configuradas para el mismo RSID y la misma fecha tienen el mismo nombre de archivo. Si esas fuentes se entregan en la misma ubicación, un archivo sobrescribirá el otro. Para impedirlo, evite crear fuentes que puedan sobrescribir otra que ya exista en la misma ubicación.

Cuando intente crear una fuente con el mismo nombre de archivo que otra, recibirá el siguiente mensaje:

En ese caso, puede hacer lo siguiente:

  • Cambiar la ruta de entrega
  • Cambiar las fechas si es posible
  • Cambiar el grupo de informes si es posible

¿Cuándo se procesan los datos?

Antes de procesar datos por hora o por día, las fuentes de datos esperan hasta que todas las visitas que han supuesto recopilación de datos dentro del marco de tiempo (un día o una hora) se han registrado en el almacén de datos. A continuación, las fuentes de datos recopilan los datos con marcas de tiempo incluidas dentro del marco de tiempo, las comprimen y las envían por FTP. En el caso de las fuentes por hora, los archivos se suelen registrar en el almacén de datos dentro de los 15-30 minutos posteriores a la hora, pero no hay un período de tiempo definido. Si no ha habido datos con marcas de tiempo incluidas en el marco de tiempo, el proceso vuelve a intentarlo con el siguiente marco de tiempo. El proceso actual de fuente de datos utiliza el campo date_time para determinar las visitas que corresponden a la hora. Este campo está basado en la zona horaria del grupo de informes.

¿Cuál es la diferencia entre columnas con prefijo post_ y columnas sin un prefijo post_?

Las columnas sin el prefijo post_ contienen datos exactamente como se enviaron a la recopilación de datos. Las columnas con el prefijo post_ contienen el valor después del procesamiento. Algunos ejemplos que pueden cambiar un valor son la persistencia de variables, las reglas de procesamiento, las reglas de VISTA, la conversión de divisas u otra lógica del lado del servidor que Adobe aplique. Adobe recomienda utilizar la versión post_ de una columna siempre que sea posible.

Si una columna no contiene una versión post_ (por ejemplo: visit_num), se puede considerar que es una columna posterior.

¿Cómo gestionan las fuentes de datos la distinción entre mayúsculas y minúsculas?

En Adobe Analytics, la mayoría de las variables se consideran sin distinción de mayúsculas y minúsculas a efectos de los informes. Por ejemplo: “nieve”, “Nieve”, “NIEVE” y “nLeve” se consideran todos como un mismo valor. La distinción entre mayúsculas y minúsculas se conserva en las fuentes de datos.

Si ve diferentes variaciones de mayúsculas y minúsculas del mismo valor entre columnas no posteriores y posteriores (por ejemplo, "nieve" en la columna previa y "Nieve" en la columna posterior), la implementación utiliza valores en mayúsculas y minúsculas en todo el sitio. Se pasó anteriormente por la variación de la distinción de mayúsculas y minúsculas en la columna posterior y se almacena en la cookie virtual, o se procesó aproximadamente en el mismo momento para el grupo de informes.

¿Las reglas de bots de la Admin Console filtran bots incluidos en las fuentes de datos?

Las fuentes de datos no incluyen bots filtrados por las reglas de bots de la Admin Console.

¿Por qué veo varios valores 000 en la columna de fuente de datos event_list o post_event_list?

Algunos editores de hojas de cálculo, especialmente Microsoft Excel, redondean automáticamente grandes números. La columna event_list contiene muchos números delimitados por comas, lo que a veces hace que Excel la trate como un número elevado. Se redondean los últimos dígitos a 000.

Adobe recomienda no abrir automáticamente los archivos hit_data.tsv en Microsoft Excel. En su lugar, utilice el cuadro de diálogo Importar datos de Excel y asegúrese de que todos los campos se tratan como texto.

¿Por qué falta información en la columna de dominio para algunos operadores?

Algunos operadores de telefonía móvil (como T-Mobile y O1) ya no proporcionan información de dominio cuando se realiza una búsqueda de DNS inversa. Por lo tanto, los datos no se muestran en los informes de dominio.

¿Por qué no puedo extraer archivos "por hora" de datos que tengan más de 7 días?

Para los datos con más de 7 días de antigüedad, los archivos "por hora" de un día se combinan en un solo archivo "Diario".

Ejemplo: Se crea una nueva fuente de datos el 9 de marzo de 2021 y los datos del 1 de enero de 2021 al 9 de marzo se entregan como "por hora". Sin embargo, los archivos "Por hora" anteriores al 2 de marzo de 2021 se combinan en un solo archivo "Diario". Puede extraer archivos "por hora" solo de datos que tengan menos de 7 días desde la fecha de creación. En este caso, del 2 de marzo al 9 de marzo.

¿Cuál es el impacto del horario de verano en las fuentes de datos por hora?

En determinadas zonas horarias, la hora cambia dos veces al año debido a las definiciones del horario de verano (DST). Las fuentes de datos respetan la zona horaria que se ha tomado como referencia para configurar el grupo de informes. Si la zona horaria del grupo de informes no utiliza DST, la entrega de archivos continúa normalmente como cualquier otro día. Si la zona horaria del grupo de informes sí utiliza DST, la entrega de archivos se modifica en la hora en la que se produzca el cambio de hora (normalmente a las 2 de la madrugada).

Cuando se realice la transición de STD a DST, el cliente solo recibirá 23 archivos. Se omite la hora omitida en la transición a DST. Por ejemplo, si la transición se produce a las 2 de la madrugada, se obtiene un archivo para la 1 y un archivo para las 3. No hay archivo de 2 porque, a las 2 STD, se convierte en 3 DST.

Cuando se realiza la transición de DST a STD, el cliente obtiene 24 archivos. Sin embargo, la hora de transición incluye datos correspondientes a dos horas. Por ejemplo, si la transición se produce a las 2 de la madrugada, el archivo de la 1 se retrasa una hora, pero contiene datos de dos horas. Contiene datos entre la 1 DST y las 2 STD (que habrían sido las 3 DST). El siguiente archivo comienza a las 2 STD.

¿Cómo gestiona Analytics los errores de transferencia de FTP?

Si falla una transferencia FTP (debido a un inicio de sesión denegado, una conexión perdida, un error de cuota u otro problema), el Adobe intenta conectarse automáticamente y envía los datos hasta tres veces diferentes. Si no se resuelven los errores, la fuente se marca como errónea y se envía una notificación de correo electrónico.

Si falla una transferencia, puede volver a ejecutar un trabajo hasta que se realice correctamente.

Si tiene problemas para que una fuente de datos aparezca en su sitio FTP, consulte Resolución de problemas de trabajos.

¿Cómo puedo reenviar un trabajo?

Cuando haya comprobado/corregido el problema de entrega, ejecute de nuevo el trabajo para obtener los archivos.

¿Cuál es la configuración de BucketOwnerFullControl para las fuentes de datos de Amazon S3?

BucketOwnerFullControl proporciona derechos a varias cuentas para crear objetos en otros buckets.

El caso de uso más habitual de Amazon S3 es que el propietario de la cuenta de los servicios web de Amazon (AWS) crea un bucket, a continuación crea un usuario que tiene permiso para crear objetos en ese bucket y, finalmente, proporciona credenciales para ese usuario. En este caso, los objetos de un usuario pertenecen a la misma cuenta y el propietario de la cuenta tiene implícitamente un control total del objeto (leer, eliminar, etc.). Este proceso es similar al funcionamiento de la entrega por FTP.

AWS también permite a un usuario crear objetos en un bucket que pertenece a una cuenta de usuario diferente. Por ejemplo, supongamos que dos usuarios de AWS, el usuario A y el usuario B, no pertenecen a la misma cuenta de AWS pero desean crear objetos en otros buckets. Si el usuario A crea un bucket llamado "bucket A", puede crear una política que permita explícitamente que el usuario B cree objetos en el bucket A aunque el bucket no pertenezca al usuario. Esta directiva puede ser ventajosa porque no requiere que el usuario A y el usuario B intercambien credenciales. En su lugar, el usuario B proporciona su número de cuenta al usuario A y este crea una política de bucket que diga "permitir al usuario B crear objetos en el bucket A".

Sin embargo, los objetos no heredan permisos del bloque principal. Por lo tanto, si el usuario B carga un objeto en el bucket del usuario A, el usuario B sigue "siendo propietario" de ese objeto y, de forma predeterminada, no se concede ningún permiso al usuario A para ese objeto aunque el usuario A posea el bucket. El usuario B debe conceder permiso explícitamente al usuario A porque el usuario B sigue siendo el propietario del objeto. Para conceder este permiso, el usuario B debe cargar el objeto con un BucketOwnerFullControl ACL, que especifica que el propietario del bucket (usuario A) tiene permisos totales para el objeto (leer, escribir, eliminar, etc.), aunque el usuario B "posee" el objeto.

NOTA

Analytics no determina si el compartimento tiene una política que requiera dar al propietario del compartimento control total de nuevos objetos, o incluso si el propietario del compartimento está en una cuenta diferente a la del usuario que escribe los datos. En su lugar, Analytics agrega automáticamente el propietario del bloque a la ACL BucketOwnerFullControl con cada carga de fuente.

En esta página