随着移动端的发展，越来越多的移动端网页采用的是单页应用的形式，因为它只加载一次，用户在访问的过程中更顺畅，所以被更普遍的接受。
如果要对单页应用做跟踪，需要用虚拟页面形式，实现一般是通过dataLayer或history的形式去跟踪，我们这里介绍通过dataLayer的方式去跟踪，这种方法的适用性更强，适用于所有的单页应用技术框架。
单页应用跟踪原理
单页应用的跟踪原理是打开新的页面的时候通过数据层发送数据，如发送Page Path、Page Title，然后在GTM将其转化成PV。
基本上对于使用GTM来管理APP也是类似的原理，都是通过数据层来管理屏幕，维度，指标等
具体配置过程
页面发送的结构如下，打开每个页面都需要这样发送，这一步是需要开发去实施：
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
'event': 'Pageview',
'pagePath': '/something/contact-us',
'pageTitle': 'Contact us'
});
</script>
触发器：Custom Event—Pageview
这里的事件名称对应dataLayer里的event。
变量：dlv—pagePath & dlv—pageTitle
变量：Google Analytics（分析）设置
代码：基础跟踪代码
单页应用跟踪的常见陷阱
单页应用跟踪往往会有一些陷阱，有些会对数据有严重的影响。
着陆页数据丢失
如果你是采用History作为触发器去跟踪单页应用，那么你需要注意看着陆页报告是否有not set的情况出现，这类流量是不会被记录Pageview和Session，也就是着陆页有not set，但在报告是没有数据。
这个是因为History是立刻触发，而页面信息还没有就被发送出去，所以是not set。
解决的方式延迟发送或不用history采用页面主动发送的方式，延迟发送并不是完全解决这个问题，但能够降低出现的数量。
网址信息丢失
#号后面的信息不会被跟踪到。
如果要跟踪，需要在GTM中设置页面字段。
错误的引荐来源
如果你有做投放，那么你需要引荐来源错误的情况，可能会出现用户是从百度cpc进来，然后用户在站内点击访问第二个页面的时候，就开启新会话，划分成百度自然搜索的。
原因是：With Google Tag Manager, every single Universal Analytics Tag that fires on the site creates a new, unique tracker object. This means that the Document Location field is updated with every Tag you fire, which is a problem if the URL changes due to browser history manipulation.
国外称之为Rogue Referral
你需要关注用户探索报告，看看找到百度CPC进来的流量，从第二个页面开始就变成百度自然搜索，而且可能还会变来变去的，从时间上来说，是非常不合理的。
解决方法可以添加跟踪器和手动设置文档位置（从页面主动发送DataLayer），详细可以看解决单页应用中出现Rogue Referral的几个方法。
