資料摘要常見問答

與資料摘要有關的常見問答。

摘要名稱必須是唯一的嗎？ unique

資料摘要檔案名稱由報表套裝 ID 和日期所組成。任兩個針對相同 RSID 和日期所設定的摘要會擁有相同的檔案名稱。 如果將這些摘要提交到相同位置，其中一個檔案會覆寫另一個檔案。 若要避免檔案覆寫，您建立的摘要不能有覆寫相同位置中的現有摘要的可能性。

當具有相同檔案名稱的另一個摘要存在時，嘗試建立摘要會產生錯誤訊息。 請考量下列暫行解決方法：

何時處理資料？ processed

在處理每小時或每日資料前，資料摘要會先等候在該時間範圍內 (日或小時) 進入資料收集的所有點擊被寫出到 Data Warehouse。 上述動作完成後，資料摘要會收集時間戳記符合該時間範圍的資料、壓縮這些資料，然後透過 FTP 傳送。 若是每小時饋送，檔案通常在該小時後的 15-30 分鐘內寫入至 Data Warehouse ，但沒有固定的時間期間。如果沒有時間戳記符合該時間範圍的資料，則處理程序會在下一個時間範圍再度嘗試。目前的資料摘要程序使用 date_time 欄位來判斷哪些點擊屬於該小時。此欄位是以表套裝的時區為基礎。

有 post_ 首碼的欄與沒有 post_ 首碼的欄有何不同？ post

沒有 post_ 首碼的欄包含的資料與資料收集所收到的資料完全相同。 有 post_ 首碼的欄則包含處理完成後的值。 會造成值變更的原因包括變數的永續性、處理規則、VISTA 規則、貨幣轉換或 Adobe 套用的其他伺服器端邏輯。Adobe 建議您盡可能使用 post_ 版本的欄。

如果欄不含 post_ 版本 (例如 visit_num)，則該欄可視為後置欄。

資料摘要是否區分大小寫? case

在 Adobe Analytics 中，為了報表呈現目的，大部分的變數都不區分大小寫。舉例來說，「snow」、「Snow」、「SNOW」和「sNow」都是相同的值。資料摘要則會區分大小寫。

如果您在非後置欄和後置欄中看到同一值的不同大小寫變化形 (例如，前置欄中是「snow」，後置欄中是「Snow」)，這表示您的實作在網站中同時使用了同一值的大寫和小寫版本。 前置欄中的大小寫變化形是在之前傳入並儲存在虛擬 cookie 中，或是與該報表套裝在大約相同的時間處理。

是否會將 Admin Console 機器人規則篩選的機器人加入資料摘要中？ bots

資料摘要不會加入 Admin Console 機器人規則篩選的機器人。

我為什麼在 event_list 或 post_event_list 資料摘要欄內看到多個 000 值？ values

有些試算表編輯器 (尤其是 Microsoft Excel) 會自動為大的數字進行四捨五入。 event_list 欄含有許多以逗號分隔的數字，有時候會導致 Excel 將其視為一個大數字。這會捨去末尾多個位數至 000。

Adobe 不建議自動開啟 Microsoft Excel 中的 hit_data.tsv 檔案；另外改用 Excel 的匯入資料對話框，並確定所有欄位會被視為文字。

是否可保證類似 hitid_high、hitid_low、visid_high 和 visid_low 等欄對於每個點擊或造訪都是唯一的？ hitid

在大多數情況下，聯結 hitid_high 和 hitid_low 能以唯一方式識別點擊。 聯結造訪的 visid_high 和 visid_low 也是同樣的概念。 然而，處理異常很少會導致兩個點擊共用相同的點擊 ID。 Adobe 建議您不要建立硬性要求每次點擊都是唯一的資料摘要工作流程。

為何某些電信業者的網域欄中遺漏資訊？ domain

某些行動電信業者 (如 T-Mobile 和 O1) 不再提供反向 DNS 查閱所需的網域資訊。因此，網域報告將無法取得這些資料。

我為什麼無法擷取 7 天以前資料的「每小時」檔案？ hourly

若要擷取 7 天以前的資料，一天的「每小時」檔案會合併至單一「每日」檔案中。

範例：新資料摘要是在 3 月 9 日建立，且以「每小時」檔案傳遞 2021 年 1 月 1 日至 3 月 9 日期間的資料。然而，2021 年 3 月 2 日以前的「每小時」檔案會合併至單一「每日」檔案中。 您只可擷取從建立日期算起前 7 天內的資料。在這種範例中，是指從 3 月 2 日至 3 月 9 日。

日光節約時間對每小時的資料摘要有何影響？ dst

某些時區因為採用日光節約時間 (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-failure

如果 FTP 傳輸失敗 (由於登入遭拒絕、連線中斷、配額不足或其他問題)，Adobe 最多會嘗試三次自動連線並傳送資料。 如果持續失敗，饋送會標記為失敗並寄出電子郵件通知。

如果傳輸失敗，您可以重新執行工作，直到成功為止。

如果您無法讓資料摘要出現在您的 FTP 網站上，請參閱資料摘要的疑難排解。

該如何重新傳送工作？ resend

在您已驗證/修正傳送問題後，請重新執行工作以取得檔案。

什麼是 Amazon S3 資料摘要適用的 BucketOwnerFullControl 設定？ 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 所「擁有」。