這看起來像一個工作的實施,雖然它否定具有標籤管理系統的幾乎所有優點。
再營銷對用戶的權重取決於他們訪問過哪個網頁 - 對於剛剛查看過主頁的用戶而言,其價值低於查看產品類別或產品詳細信息的用戶的價值(加上您瞭解的更多信息產品的視角越精確,您可以根據客戶的喜好量身定製廣告,或理論如此)。這就是爲什麼您需要傳遞訪問網站的數據以及通過JavaScript對象查看的產品 - 「google_tag_params」。
通常這些數據將在您的網站的源代碼中提供 - 理想情況下爲數據層格式,儘管全局JavaScript變量也適用。
顯然你正在看的網站不這樣做。所以實現這個的人使用了自定義的HTML標籤來創建具有必要數據的全局JS變量。這將數據放入全局名稱空間。然後,他創建了一個JavaScript變量,用於讀取從標記創建的js變量並將其提供給Adwords標記。
有多個自定義HTML標記,其中包含google_tag_params的定義。我非常肯定,如果你看觸發器,你會發現它們被觸發在特定的頁面上 - 「主頁」只在你的網站的根頁面,產品詳細信息頁面上的「產品變量」等。這樣,google_tag_params對象包含相應頁面類型所需的數據。由於網站不提供產品數據,因此在「產品變量」標籤中有一些自定義JavaScript來從DOM中提取數據。
這是行不通的?好吧,我想是的。它是優雅的嗎?當然不是 - GTM的兩個主要優點是封裝(您需要的唯一全局變量是數據層數組,因此可以減輕命名衝突的風險)以及相當健壯的選擇器引擎。你的代碼不會使用任何代碼。
值得改變嗎?或許一點點。如果google_tag_params將在自定義JavaScript變量(採用返回值的匿名函數的格式)中創建,則會更優雅一些。此外,DOM提取代碼可以移動到自定義JavaScript變量或DOM類型變量(如果您可以拿出適當的選擇器,它將從HTML元素中讀取數據,而無需任何自定義代碼)。然而,儘管這意味着你有一個更好和更可靠的實現,這意味着一些努力獲得基本相同的結果。
然而,正確的實現將依賴於由您的頁面提供的數據層(即,它是通過服務器端代碼創建的)。 DOM提取是一件多變的事情,如果你改變你的標記,你會破壞你的Adwords跟蹤。
如果你不能通過服務器端代碼實現dataLayer,那麼務實的解決方案可能會讓事情保持原樣。它確實給你帶來了一些問題(如果你改變了標記或者引入了一個名爲「price」或「qty」的全局JS變量,那麼你的實現就被搞砸了),但顯然這已經完成了它的工作,所以爲什麼要額外的英里。
感謝Eike的一個很棒的解釋! – user3465554