資料摘要常見問答

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

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

Adobe Analytics不會防止資料摘要檔案被覆寫。

為避免資料摘要檔案遭覆寫，我們建議所有要傳送至相同位置的資料摘要檔案都具有唯一檔案名稱。

資料摘要檔案名稱由下列資料摘要特性組成：

為相同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查閱所需的網域資訊。 因此，該資料不適用於網域報告。

為什麼我無法可靠地擷取舊日期的每小時檔案？ hourly

為了最佳化儲存和處理，Adobe會定期將每小時的匯出整合為每日檔案。 由於這些合併執行的方式和時間，10天以前的日期的每小時輸出無法預測。 在指定的日期，可能會看到某些小時的每小時檔案和其他人的合併每日檔案。 整合至每日檔案的資料通常會指派給00小時，若直接請求該小時，其他小時可能會保留空白。

如果回填的時間超過10天，Adobe強烈建議使用每日粒度，以確保結果完整且可預測。 如果您必須請求較舊日期的每小時詳細程度，請一律在請求中包含小時00，以避免遺失合併的每小時資料。

日光節約時間對每小時的資料摘要有何影響？ 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 所「擁有」。