这取决于。
如果您在 GA 代码 ( _setDomainName
) 中明确设置域,并且它被设置为您的旧域,那么 GA 代码将不会触发。这是因为 GA 将无法写入其 cookie。因此,您需要确保这不是在您的新域上设置,或者将其设置为正确的值。
除此之外,还要注意代码将“工作”,因为它将继续跟踪。但是,GA 使用第一方 cookie。这意味着您已经建立的访问者(在旧域上设置)的 cookie 不会转移到新域。这意味着任何已经访问过您的网站并拥有 cookie 的访问者基本上都会以新访问者的身份开始。
不幸的是,保留当前访问者并不是一件容易的事,除非您愿意暂时做一些客户端重定向,而不是服务器端重定向。
为什么?
所以事情就是这样.. 你看,GA 在确保访客信息在携带时不会被篡改方面非常狡猾。
通常它的完成方式是您_setAllowLinker
在页面代码中使用,然后_link
在给定链接的 onclick 中使用。这使得 GA 将其 cookie 信息附加到目标 URL 以传递到新域。(注意:如果您确实想进行客户端重定向,那么您基本上只需调用_link
页面加载调用而不是 onclick。它将处理重定向)。
所以这就是事情变得狡猾的地方。除了 cookie 和值之外,GA 还传递了一个__utmk
参数,简而言之,它是由其他参数和一小部分当前域的灵魂合并生成的哈希值。ga.js 中有一些复杂的 js 技巧来实现这一点,到目前为止,我还没有找到带有服务器端代码的逆向工程版本。
现在,假设您将自己的灵魂卖给魔鬼以学习如何重现他们的魔术,那么您现在面临下一个问题:在重定向中传递这些东西。
.htaccess
在服务器配置文件或 w/e中获取其他 cookie 并将它们作为参数传递是“足够简单的” 。但是该环境中没有可用的脚本语言,因此您必须使用RewriteMap
引用外部脚本。这还不算太糟糕,尽管它确实使事情有些复杂。哦,RewriteMap
也不能在其中声明,.htaccess
所以你不能在那里填充;必须把它放在服务器配置文件中。如果您已经在那里执行重写规则,那么很容易,但是如果您正在执行重写规则,.htaccess
那么请注意这一点。
所以总结一下:
__utmk
您必须对在 中生成的确切方式进行逆向工程ga.js
,并将其移植到服务器端脚本
- 您必须使用
RewriteMap
调用该脚本来生成该值
- 将 __utm
X
cookie 和 __utmk 参数添加到重定向的 URL
- 此外,在您的新域上,您需要添加
_setAllowLinker
到您的页面 GA 代码,以便它会查找 URL 参数并使用它们
替代这个烂摊子?如前所述,如果您愿意暂时使用 GA 的_link
页面加载调用作为从 siteA 到 siteB 的重定向方法,这将允许 GA 代码将参数(包括生成的__utmk
变量)附加到目标 URL 并成功迁移新网站的访问者。
注意:您还需要document.referrer
在推送中将 附加到您的目标 URL _link
,然后在您的新域上添加一些代码以获取它并_setReferrerOverride
使用该值弹出,以便 GA 将记录原始引荐来源网址而不是虚拟重定向页面.
您甚至可以RewriteCondition
检查__utm
cookie 是否存在,如果存在,则将访问者重定向到具有 GA 重定向的单个页面。如果它不存在,让 RewriteRule 像往常一样重定向到新域。这将减少使新访客不得不跳过箍的情况。
让它客户端重定向多长时间?这取决于您最长的转换周期。您网站的转化/目标是什么?例如,您有购买渠道吗?访客购买商品平均需要多长时间?一天?一个月?选择最长的转化周期,然后等待那么长的时间。可能会有一些边缘情况从裂缝中掉下来,但这应该比失去所有这些情况更容易接受。或者,如果您愿意,可以无限期地保留它。
如果你不想这样做呢?好吧,选择一个好时机来处理被擦除的访问者信息板,打开重写规则,然后处理它。