資料摘要常見問答

最後更新： 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 天以前的資料，一天的「每小時」檔案會合併至單一「每日」檔案中。

範例：新資料摘要是在 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 使用者 userA 和 userB，他們不屬於相同的 AWS 帳戶，但想在其他儲存貯體中建立物件。 如果 userA 建立了一個 bucketA 儲存貯體，他可建立一個儲存貯體原則來明確允許 userB 在 bucketA 中建立物件，即便 userB 並未擁有該儲存貯體。 此原則有利的地方在於不要求 userA 和 userB 交換認證。 而是由 userB 提供其帳戶號碼給 userA，讓 userA 建立儲存貯體原則，特別指明「讓 userB 在 bucketA 中建立物件」。

然而，物件不會繼承父儲存貯體的權限。 因此，如果 userB 上傳物件至 userA 的儲存貯體，userB 仍「擁有」該物件，而且依預設，userA 並未獲得該物件的任何權限，即便 userA 擁有儲存貯體。 UserB 必須明確授與 userA 權限，因為 userB 仍然是物件的擁有者。 若要授與此權限，userB 必須上傳具有 BucketOwnerFullControl ACL 的物件，這會指定儲存貯體擁有者 (userA) 被授與物件的完整權限 (讀取、寫入、刪除等)，即便該物件是由 userB 所「擁有」。

NOTE
Adobe Analytics 無法判斷貯體是否有原則來要求將新物件的完整控制權授與貯體擁有者，即便貯體擁有者的帳戶與撰寫資料的使用者不同。 而是 Analytics 會在上傳每個摘要時，自動將此貯體擁有者新增到 BucketOwnerFullControl ACL。

Analytics