数据馈送常见问题解答

最近更新： 2024年12月9日

创建对象：

  • 用户
  • 管理员

有关数据馈送的常见问题解答。

馈送名称是否必须唯一？

数据馈送文件名由报表包 ID 和日期组成。为同一个 RSID 和日期配置的任意两个馈送具有相同的文件名。如果将这些馈送提交到同一位置，则一个文件将覆盖另一个文件。为了防止文件覆盖，您不能在同一位置创建有可能覆盖现有馈送的馈送。

在尝试创建馈送时如果存在具有相同文件名的其他馈送，会提示错误消息。 请考虑以下解决方法：

  • 更改提交路径
  • 更改日期（如有可能）
  • 更改报表包（如有可能）

数据在什么时候处理？

在处理每小时或每日数据之前，数据馈送会等待直到该时间范围（天或小时）内进入数据收集的所有点击已经写出到 Data Warehouse。之后，数据馈送会收集时间戳位于该时间范围之内的数据，对其进行压缩并通过 FTP 发送。对于每小时馈送，文件通常会在该小时之后的 15 至 30 分钟内写出到 Data Warehouse，但是没有设置具体的时间段。如果没有时间戳位于该时间范围之内的数据，则流程会在下个时间范围内再次尝试。当前数据馈送流程使用 date_time 字段来确定哪些点击属于该小时。此字段基于报表包的时区。

带 post_ 前缀的列和不带 post_ 前缀的列之间有何差异？

带 post_ 前缀的列包含与它发送到数据收集完全相同的数据。带 post_ 前缀的列包含处理后的值。可更改值的示例包括变量持久性、处理规则、VISTA 规则、货币转换或 Adobe 应用的其他服务器端逻辑。Adobe 建议尽可能使用带 post_ 前缀的列。

如果某列不带 post_ 前缀（例如 visit_num），则可能会将该列视为后处理列。

数据馈送如何处理大小写问题？

在 Adobe Analytics 中，大多数变量在用于报告时都会被视为不区分大小写。例如，“snow”、“Snow”、“SNOW”和“sNow”全都会被视为相同的值。在数据馈送中会保留区分大小写。

如果您在非后处理列和后处理列中看到同一个值的不同大小写（例如，前处理列中的“snow”与后处理列中的“Snow”），则您的实施将在整个网站中同时使用大写值和小写值。后处理列中的不同大小写是在之前传递的，并被存储在虚拟 Cookie 中，或者是在大致相同的时间针对该报表包处理的。

数据馈送中是否包含按 Admin Console 机器人规则过滤的机器人？

数据馈送中不包含按 Admin Console 机器人规则过滤的机器人。

为什么在 event_list 或 post_event_list 数据馈送列中看到了多个 000 值？

一些电子表格编辑器，特别是 Microsoft Excel，会自动舍入大数字。event_list 列包含许多逗号分隔的数字，有时候会导致 Excel 将其视为非常大的数字。它会将后几位舍入为 000。

Adobe 建议不要自动在 Microsoft Excel 中打开 hit_data.tsv 文件。而是使用 Excel 的“导入数据”对话框并确保将所有字段作为文本来处理。

是否能确保像 hitid_high、hitid_low、visid_high 和 visid_low 这样的列对于点击或访问是唯一的？

在几乎所有情况下，hitid_high 和 hitid_low 列的连接将唯一标识点击。同一概念适用于针对访问的 visid_high 和 visid_low 的连接。不过，处理异常很少会导致两个点击共享同一个点击 ID。Adobe 建议不要创建硬性要求每次点击均唯一的数据馈送工作流程。

为什么有些运营商的域列中缺少信息？

某些移动运营商（例如 T-Mobile 和 O1）不再提供用于反向 DNS 对照的域信息。因此，此数据不可用于域报告。

为什么我不能从超过 7 天之前的数据中提取“小时”文件？

对于超过 7 天之前的数据，某天的“小时”文件会合并为一个“每日”文件。

示例: 2021 年 3 月 9 日创建了一个新的数据馈送，并以“小时”形式交付了 2021 年 1 月 1 日至 3 月 9 日的数据。但是，2021 年 3 月 2 日之前的“小时”文件合并为单个“每日”文件。您只能从自创建日期起不到 7 天的数据中提取“小时”文件。在本例中，是指从 3 月 2 日到 3 月 9 日。

夏令时对每小时数据馈送有什么影响？

对于特定时区，由于夏令时 (DST) 定义，每年时间要改变两次。数据馈送遵循报表包所配置的时区。如果报表包的时区不使用 DST 的时区，文件传递与其他日期一样正常继续。如果报表包的时区使用 DST 的时区，则在更改时间的那个小时（通常为凌晨 2:00）变更文件传递。

进行 STD -> DST 时间过渡时（“调快一小时”），客户仅收到 23 个文件。忽略 DST 过渡中跳过的那个小时。例如，如果过渡在凌晨 2 点进行，则他们会收到 1:00 那个小时和 3:00 那个小时的文件。没有 2:00 的文件，因为在 2:00 STD，时间变成了 3:00 DST。

进行 DST -> STD 过渡时（“调慢一小时”），客户收到 24 个文件。但是，进行过渡的那个小时实际包含两个小时的数据。例如，如果过渡在凌晨 2:00 进行，则 1:00 那个小时的文件延后一个小时，但包含两个小时的数据。它包含从 1:00 DST 到 2:00 STD（实际是 3:00 DST）的数据。下一个文件从 2:00 STD 开始。

Analytics 如何处理 FTP 传输故障？

如果 FTP 传输失败（由于登录被拒绝、连接丢失、配额不足错误或其他问题），则 Adobe 最多尝试单独自动连接并发送数据三次。如果仍然失败，则系统会将馈送标记为失败，并发送电子邮件通知。

如果传输失败，您可以重新运行作业直至它成功。

如果您遇到在 FTP 站点上显示数据馈送的问题，请参阅数据馈送疑难解答。

如何重新发送作业？

验证/更正了交付问题后，请重新运行作业以获取文件。

什么是 Amazon S3 数据馈送的 BucketOwnerFullControl 设置？

BucketOwnerFullControl 可以提供在其他存储桶中创建对象的跨帐户权限。

Amazon S3 的常见使用案例是 Amazon Web Services (AWS) 帐户所有者创建一个存储桶，接着创建一个有权限在该存储桶中创建对象的用户，然后为该用户提供凭据。在这种情况下，一个用户的对象属于相同帐户，而帐户所有者隐式拥有对象的完整控制权限（读取、删除等）。此过程类似于 FTP 传递的工作方式。

AWS 还使得用户可以在存储桶中创建属于不同用户帐户的对象。例如，如果有两位 AWS 用户，用户 A 和用户 B，他们不属于同一个 AWS 帐户，但是他们希望在其他存储桶中创建对象。如果用户 A 创建了一个名为“存储桶 A”的存储桶，则该用户可以创建一条存储桶策略，明确规定即使用户 B 并非存储桶 A 的所有者，但仍然允许用户 B 在存储桶 A 中创建对象。此策略可能会有好处，因为它不需要用户 A 和用户 B 交换凭据。而是由用户 B 向用户 A 提供自己的帐号，然后由用户 A 创建一条存储桶策略，大意是“允许用户 B 在存储桶 A 中创建对象”。

但是，对象不从父存储桶继承权限。因此，如果用户 B 上传对象到用户 A 的存储桶，用户 B 仍然“拥有”该对象，默认情况下不向用户 A 授予对该对象的任何权限，虽然用户 A 拥有该存储桶。用户 B 必须明确赋予用户 A 权限，因为用户 B 仍然是该对象的所有者。要授予此权限，用户 B 必须上传具有 BucketOwnerFullControl ACL 的对象，这指定向存储桶所有者（用户 A）授予对该对象的完整权限（读取、写入、删除等），即使该对象由用户 B“拥有”。

注意
Adobe Analytics 不会确定存储桶是否具有一项要求为存储桶所有者提供新对象完全控制权的策略，甚至不会确定存储桶所有者与写入数据的用户是否位于不同的帐户中。相反，Analytics 会在每次馈送上传时将存储桶所有者自动添加到 BucketOwnerFullControl ACL。

Analytics