資料摘要常見問答集

資料饋送的常見問題。

摘要名稱必須是唯一的?

資料摘要檔案名稱由報告套裝 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_listpost_event_list 資料摘要欄內看到多個 000 值?

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

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

為什麼某些電信業者的網域欄中會遺失資訊?

某些行動電信業者 (如 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 am)而變更。

進行STD -> DST時間轉換(「向前跳」)時,客戶僅收到23個檔案。 DST轉換中跳過的小時會忽略。 例如,如果轉換發生在2 AM,則會取得1:00的檔案和3:00的檔案。 沒有2:00檔案,因為在2:00標準時,會變成3:00 DST。

進行DST -> STD轉換時(「後退」),客戶會收到24個檔案。 不過,轉換時間實際上包含了兩小時的資料。 例如,如果轉換發生在2:00 am,1:00的檔案會延遲1小時,但包含2小時的資料。 它包含1:00 DST至2:00 STD(原本是3:00 DST)的資料。 下一個檔案從2:00 STD開始。

當未收集任何資料時,我是否會收到資訊清單檔案?

您可選擇設定資料摘要,當特定期間未收集到任何資料時傳送資訊清單檔案。如果啟用此選項,您會收到類似下列的資訊清單檔案:

Datafeed-Manifest-Version: 1.0
 Lookup-Files: 0
 Data-Files: 0
 Total-Records: 0

Analytics如何處理FTP傳輸失敗?

發生FTP傳輸失敗(登入被拒絕、連線中斷、配額不足等)時,Adobe會嘗試自動連線並傳送資料,最多三次。 如果持續失敗,饋送會標記為失敗並寄出電子郵件通知。

如果轉移失敗,您可以重新運行作業,直到成功。

如果您無法讓資料饋送顯示在FTP網站上,請參閱疑難排解工作

如何重新傳送工作?

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

AmazonS3資料饋送的BucketOwnerFullControl設定為何?

Amazon S3 的常見使用案例是 Amazon Web Services (AWS) 帳戶擁有者建立儲存貯體、接著建立具有在該儲存貯體中建立物件之權限的使用者,然後提供該使用者的憑證。在這種情況下,用戶的對象屬於同一帳戶,而帳戶所有者隱含地對對象(讀取、刪除等)具有完全控制權。 此程式類似於FTP傳送的運作方式。

AWS還使用戶能夠在儲存桶中建立屬於不同用戶帳戶的對象。 例如,假設有兩位 AWS 使用者 userA 和 userB,他們不屬於相同的 AWS 帳戶,但想在其他儲存貯體中建立物件。如果 userA 建立了一個 bucketA 儲存貯體,他/她可建立一個儲存貯體原則,即使 userB 並不擁有 bucketA,仍可明確地允許 userB 在 bucketA 中建立物件。此原則可有利,因為它不要求userA和userB交換憑證。 而是由 userB 提供其帳戶號碼給 userA,讓 userA 建立儲存貯體原則,特別指明「讓 userB 在 bucketA 中建立物件」。

BucketOwnerFullControl 提供在其他儲存貯體中建立物件的跨帳戶權限。如果userB將物件上傳至userA的儲存貯體,userB仍「擁有」該物件,且依預設,userA不會授與該物件的任何權限,即使userA擁有儲存貯體。 這是因為物件不會繼承父儲存貯體的權限。 UserB 必須明確授與 userA 權限,因為 userB 仍然是物件的擁有者。要授予此權限,userB必須使用BucketOwnerFullControl ACL上載對象,該ACL指定將儲存桶所有者(userA)授予對象(讀取、寫入、刪除等)的完全權限,即使對象為userB所擁有。

本頁內容

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now