流量渠道跟踪

流量渠道标记（UTM）

流量渠道标记，就是怎么去跟踪流量，知道流量或访客、用户是从哪里来的？

流量渠道标记一般是使用UTM，UTM的全称是Urchin Tracking Module/Urchin Tracking Manager，Urchin是就是Google Analytics的前生了，有兴趣的可以看Google Analytics的发展历史。

现在UTM成为行业术语了，如百度统计、神策、GrowiongIO、诸葛IO都支持或兼容UTM，可以说UTM就是流量跟踪、流量标记的代名词了。

什么是UTM呢？

UTM就是在着陆页的URL上面添加一些广告系列参数用于标记广告信息。

用户访问这个链接的时候，带有特定参数的信息就会发送到第三方分析工具，你就可以在报告里面看到各个渠道的效果。

UTM的参数有些呢？

UTM一共有5个参数，3个必填参数、2个可选参数，详细的如下：

utm_source、utm_medium、utm_campaign是必填参数，utm_term和utm_content是可选参数。

utm_source：标记来源，如从哪个网站来的，比如从www.ichdata.com网站过去的流量可以标记为ichdata。

utm_medium：表示媒介类型，如通过什么方式来的，如social、email、diaplay等，需要注意！需要注意！！需要注意！！！重要的事情说三遍，utm_medium是有系统预设定的字段的，你不能随便用的，一定要用下表中的预设定字符：

如果是SEM付费的，可以是utm_medium=cpc或utm_medium=ppc或utm_medium=paidsearch。

Medium是大小写是敏感的，Email和email代表两个不同的渠道。

如果没有按照上表中与设定的字符，那么Google Analytics中渠道划分（就是Channel报告），该流量就不能准确划分到对应的渠道，会出现一个Others的渠道，如果你的报告中有出现Others的渠道，就表示Medium使用错误的。

其实Medium使用错误导致渠道划分不对其实是可以通过渠道设置去修改的，在数据视图设置下去修改Channel Settings。

utm_campaign：表示广告系列，就是广告活动的名字，比如我这个是夏季活动，可以这样utm_medium=summer-sale。如果这个没填，那么Google Analytics中的Campaign的报告为空。

utm_term：一般用于标记付费搜索关键字，如用UTM去跟踪百度SEM的关键字。

utm_content：用于标记不同的广告内容或创意，区分不同的类型广告的效果。

使用示例

如果URL上没有问号：

如着陆页是：https://www.ichdata.com/index.html

那么直接添加UTM参数：

https://www.ichdata.com/index.html?utm_source=google&utm_medium=cpc&utm_campaign=summer-sale

如果URL上有问号：

如着陆页是：https://www.ichdata.com/index.html?SSID=11

那么先添加#，再添加UTM参数：

https://www.ichdata.com/index.html?SSID=11#utm_source=google&utm_medium=cpc&utm_campaign=summer-sale

批量该如何使用？

对于少量的链接，有两种添加方式：

• 一种是直接编辑添加
• 一种是通过网址构建器去实现，网址：https://ga-dev-tools.appspot.com/account-explorer/

大量的话，可以通过Excel工具，可以关注本公众号然后发送”书”获取Excel工具，包含两个，一个是Excel批量工具，一个是中文转码的：

使用注意点？

• UTM的参数是大小写敏感的，大小写不同，划分是不同的。
• 添加UTM参数的时候，前面没有‘？’的时候需要先添加‘？’在添加UTM参数，如果前面已经有？出现了，那就用‘#’，然后再添加UTM参数，兼有？和#都是UTM的系统使用字符，因此不建议在UTM中标记渠道的时候使用这个两个字符，避免被截断。
• 为了标记准确，utm_source、utm_medium、utm_campaign是3个必不可少的参数
• 渠道分组是对medium是有预定义的，一定使用预定义的字段
• UTM上有中文的话需要转码才可以使用，否则会乱码

拓展：流量分类与规则详解

上一节介绍了流量的识别原理，也知道几个特例情况，接下来要介绍流量是怎么划分成不同的渠道了。

Google分析在识别流量渠道的是时候遵循一定的规则，划分都是根据Referral和URL的特征，具体有：

详细的流程处理逻辑如图4-5所示：

图4-5 流量判断逻辑

上面这个看起来很复杂的流程图可以概括为，GA的渠道流量识别具有一定的顺序和优先级，整体的顺序是：

1、ADwords/DoubleClick/广告系列

2、UTM参数

3、自然搜索

4、社交流量

5、推荐流量

6、直接流量

7、其他

这个判断的过程是个顺序判断的过程，一个流量按照上述顺序判定后就不会在被归类到后面的任一渠道了。比如判断Adwords流量，如果是Adwords 流量，就开启自动标记功能，那么URL上带有gclid的标记的，如果一个用户是从Adwords过来，那么就先判断是否为Adwords，那么这个流量就被归因到Adwords里面去了；如果UTM标记的，那么先判断是不是Adwords，不是就判断下一个，Doubleclick，也不是，直到判断为UTM的时候，是就归类为UTM的流量。

对流量划分成不同渠道后主要是在GA里的“流量获取”→“所有流量”→“渠道”里这个报告面，如图4-6所示：

图4-6 渠道报告

渠道报告里面的流量划分是有一定的规则的，默认的规则如表4-1所列：

表4-1 渠道划分规则

从上面可以看到，渠道的划分主要是根据媒介，部分是结合来源来划分，这个规则的作用是：投放广告添加的UTM中的来源和媒介要遵循这个表里，系统已经预设定的字段，流量才能够被准确划分。如果没有，那么渠道报告里面的数据划分就是有错的了，详细的错误原理请看第二章第二节中的UTM参数的正确用法一节。

需要注意的是这些渠道定区分大小写。手动标记网址时，请使用小写形式的标记，以确保 GA能够对会话进行正确分类。例如，标记为“Email”的电子邮件广告系列与“email”渠道的系统定义不符。而且并非所有维度都允许 GA查询相关费用数据。如果在渠道分组对象中使用了这类维度，则无法获取该渠道分组的费用数据，出现数据紊乱的情况。

如果很不幸，您放出去的链接标记参数没有使用上述表格的系统字段的的话，还是有方法可以调整，使得渠道报告里的数据是准确的。调整的方法有两种：

1、渠道分组（Channels Settings）

2、自定义渠道分组（Custom Channels Grouping）

这两方法的差别是，渠道分组中的配置是显示在渠道默认报告里面，也就是对Default Channels Grouping做修改。而自定义渠道分析的分组是在“主要维度”→“内容分组”里面，需要去选择才会生效，下面介绍这两个设置方法的具体操作：

渠道分组设置方法

渠道分组的设置是视图级别的，所以在数据视图这一层级下设置，若干有多个数据视图需要设置，需要到每个数据视图下面设置一遍。

1、在GA中选择“管理”→“频道设置”→“渠道分组”→“操作”→“修改”就可以修改默认的分组，如图4-7所示。

2、单击“修改”后可以看到如图4-8所示设置面板

“名称”那里不用做修改；“定义一个新渠道”表示新建一个新的渠道；

如果要移动渠道的排序的话，将鼠标移动到等鼠标表册黑十字就可以将渠道随意移动，这里需要注意的是，渠道前面的顺序表示这个渠道的流量首先剥离出来，渠道的划分是遵循逐步剥离的原则，比如满足媒介为direct的流量划分为直接流量，那么direct的流量就已经从所有所有流量剥离出来，下一个规则只是剩余的流量里面做第二次剥离，不会出现一个流量既是A渠道的，又是B渠道的；如果要对现有的渠道规则做修改的话，可以单击右侧的那个有点像笔的符号，就可以对这个渠道的规则做调整，调整的界面如图4-9所示：

可以看到设置的条件有或和且，或表示并列关系，且表示同时具备两个条件。设置的字段里面有很多可以选择的，但是主要用到的是Landing Page URL和Source/Medium/Campaign直接有个一一对应的原则，这个原则的意思是Landing Page URL和Source/Medium/Campaign是key-value的关系，您可以从Landing Page URL的URL特征角度去划分，也可以从Source/Medium/Campaign的角度区划分，通常来说是结合使用的，更容易定位特定的渠道流量。

示例：如果我的站点的PPC的推广着陆页都带有tuiguang的字段，如http://www.ichdata.com/tuiguang/lpd1,html,

http://www.ichdata.com/tuiguang/lpd2,html,

……

在分组里面设置Landing Page URL matches tuiguang，渠道名为付费推广，那么，所有从上述页面访问的所有流量，以及后续产生的流量都会被划分到“付费推广”里面，面板设置如图4-10所示：

这个原则非常重要，经常使用在渠道规则调整里面。

3、调整完保存即可，这个设置生效期是实时的，但是数据的反馈会稍微之后一两个小时，之后看到的是渠道报告效果如图4-11所示：

自定义渠道分组设置方法

自定义渠道分组跟渠道分组的设置是一样的，也是视图级别，在GA中单击“管理”→“自定义渠道分组”→“新建渠道分组”就可以设置，如图4-12所示，设置的的方法同上。

注意：对于每个数据视图，每位用户最多只能创建 100 个自定义渠道分组。每个数据视图最多可包含 50 个渠道分组，该数值不包括默认渠道分组。

小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或者搜一下即可打开应用。

相比H5和App，小程序门槛低、受众广、互动频繁和使用场景丰富，一时间吸引无数人入坑。

微信之父张小龙从2017年发布微信小程序功能上线到现在2020年，各类小程序层出不穷，如支付宝小程序、百度小程序、字节跳动小程序、QQ小程序……目前小程序有这么几个阵营:

各个平台都有各自的特点，适用不同的场景。

我们今天要讲的小程序是微信小程序，微信小程序是第一个吃螃蟹的人，最具代表性，后面厂家基本都是借鉴微信，某宝小程序代码文档里赫然出现微信小程序团队各位开发者的名字，以示对微信的致敬。

而微信小程序怎么跟踪取决于微信开放了什么。

微信小程序开放了什么？

在渠道跟踪上，微信小程序推出了一个场景值的概念。

场景值（scene）：场景值是微信官方用来描述用户进入小程序的路径，详细的场景值如下：

上图只是截选部分场景，截止到2020年8月份有70个场景，并且不断再增加，这些场景表示小程序打开的途径方式，已经分得非常细致 ，所有场景可以看：https://developers.weixin.qq.com/miniprogram/dev/reference/scene-list.html

上述场景可以分为四类：

根据张小龙在一些公开课的发言：扫码是小程序最主要的入口。

如何跟踪？

小程序在打开的时候可以通过 onLaunch 和 onShow，或wx.getLaunchOptionsSync 中获取包括场景值在内的如下参数：

• path：就是小程序的路径，地址，可以理解为Page Path
• scene：场景值，这个是微信小程序返回给我们场景值，用上面提到的那三个函数就会自动获取，第三方检测工具可以通过这个场景值划分不同的途径
• query：自定义查询参数，可以对场景做细化，如同样是扫码，可以通过自定义参数细分成不同位置的扫码。
• shareTicket：用于跟踪转发分享，分享转发有两种实现类型，一种是通过shareTicket实现自动采集分享，一种是通过程序改写成query形式跟踪。
• referrerInfo：部分场景值下还可以获取来源应用、公众号或小程序的appId，appId就在referrerInfo里面，通过appId就可以来自具体的哪个公众号或小程序。

渠道跟踪主要就是通过scene、query、shareTicket和referrerInfo识别，上述四种分类对应的跟踪方式是：

• 扫码类一般会通过query细化来源，就是小程序码或二维码带参数，也可以在添加UTM参数，通过query去解析
• 投放跳转的主要是通过sence，部分sence会带有referrerInfo，可以知道具体来源的appid
• 分享转发有两种实现方式，一种是query，一种是shareTicket
• 微信各入口就是微信上的一些入口，如微信搜索，直接通过sence就可以知道来源。

实际情况

    实际上现在很多的小程序监测工具是兼容UTM，方便用户使用，如下所示：

pages/index/index?TDChannelId=channelname

page/index/index?utm_source=miniapp_A

/pages/Fcomponent/Fcomponent/?unitid={{UNIT_ID}}&source=shantou_fe

可以看到不同监测工具使用的字段是不一样的，但原理是一致的，在path 的结尾可以增加参数来标明来源，类似UTM的，各家用的字段不一，有的用TDChannelId，有的用utm_source，有的用source，有的UTM的三个参数全用，具体使用设置方法参照各家为准，在 App.onLaunch App.onShow wx.getLaunchOptionsSync 会根据query 解析相关参数从而知道来源信息。

小程序是基于场景值和自定义查询参数跟踪，所有第三方工具里的报告通常有两个报告，一个是基于场景值报告，一个是基于自定义查询参数query报告，UTRL上面加参数，用类似UTM的方法跟踪。

工具

跟踪的原理就是上面这些，但大部分人都只直接选一个工具直接用就行，目前这块主要有两类玩家提供小程序的监测工具：

• 类型一：专门做小程序跟踪，如阿拉丁
• 类型二：本来做网站分析工具或增长工具，也涵盖小程序这一块，如神策、GrowingIO、诸葛IO、国双、易观、及策、友盟、Talkingdata等

这些都可以实现小程序的渠道和行为跟踪，主要玩家还是本身是做监测的厂家，顺带也做小程序这一块，在分析逻辑或模块上比较有经验。

Google Analytics也是可以实现小程序跟踪的，原理是要用MP协议，可以参考这个：https://github.com/rchunping/wxapp-google-analytics

如何选工具

• 要能够自定义生成小程序码/二维码去标记细分场景（因为扫码只最主要的入口，如果只有一个基于场景值的合并数据而不能细分扫码来源的数据，作用是很有限）
  
• 要提供至少两个报告：场景报告和细分报告（如扫码），能够自定义

小程序前两年是火，但现在明显有些降温，局限于特定场景使用的，可以作为辅助使用，注定它是撼动不了原生APP的。

由于Google Play不能在大陆使用，说造成了现在国内安卓应用市场百花齐放，这给跟踪增加了不少难度；在正式进入正题之前，我们先来了解一下广告主和APP下载跟踪的整个流程，看这个流程主哪些参与者能够获取数据，看下图：

首先，是广告主，广告主通过广告平台去投放广告，吸引用户点击去应用市场下载APP，然后激活使用，在这个过程中，广告平台可以知道广告的展示和点击，应用市场可以知道下载，最终的激活这个数据就需要做跟踪才有的，激活的数据可以传递会前面不同的几个参与者，如应用市场，这个通常是操作系统本身才有的，如苹果的IOS和Google的google play,另一个是广告平台的，广告平台有些是目标优化或使用look alike这个功能，需要应用回传一些数据，最后一个就是广告主的，非常关心整个流程的转化，投入产出，ROI等，一般会使用第三方工具做监控，也就是我们这一节要讲到的。

目前操作系统主要是Android和IOS,虽然仍有部分使用微软的wp或其他的linux类的操作系统，但主流是安卓和苹果，可以说，手机系统，不是安卓就是苹果了.

安卓的话，谷歌官方有个应用市场Google play，一般内置在系统里面，国外用户下载APP都是通过google play下载，APP的跟踪继续沿用web的逻辑，Google play能够传递传递referral参数，能够跟Google Analytics无缝对接。 但是在国内，由于一些政策因素，谷歌的这部分服务不能在大陆使用，国内的用户连不上google play,这个机遇催生了很多的应用市场，这跟跟踪带来的一定的难度，目前采用主要形式是渠道包，也就是每个渠道带一个包，内嵌一个id，通过id去识别；另一种方法是模糊匹配了，这个是比较少用的。

IOS的话，绝大部分的用户下载APP都是通过APP Store，只有部分越狱用户通过第三方市场去下载，现在越狱的已经很少了，所以这里主要讲解APP Store的跟踪方式，IOS是个比较封闭的系统，所以你能跟踪什么，能跟踪多少，取决于苹果开放了多少。

Android端

https://play.google.com/store/apps/details?id=com.ichdata.application

https://play.google.com/store/apps/details?id=com.ichdata.application
&referrer=utm_source%3Dgoogle
%26utm_medium%3Dcpc
%26utm_term%3Drunning%252Bshoes
%26utm_content%3Dlogolink
%26utm_campaign%3Dspring_sale

iOS的发行渠道则与安卓有很大的不同，除了少数越狱的机器之外，大部分用户的App都是从 App Store下载的。iOS的“渠道”其实通常是指那些在其它App或者网页内部，提供到AppStore的链接的页面。因此，在iOS中追踪发行渠道，主要是追踪进入App Store相关页面的渠道信息。

但iOS的渠道追踪面临着一道无法逾越的鸿沟。正因为iOS的渠道分发都有跳转到App Store这一步，而Apple本身是不会提供太多信息给开发者，所以，对于整个流程的三个步骤：在某个渠道点击下载链接并跳转到App Store —> App Store内下载App —>用户激活App，这整个过程能获取到的信息的多少。取决于苹果开放了多少。目前iOS提供这几种渠道跟踪方式：

精准匹配：IDFA

iOS的精准匹配就是使用IDFA，IDFA的全称是Identifier for Advertising ，中文名是广告标识符，自2012年iOS6推出IDFA后，其他的MAC、UDID各种ID都被苹果禁止，只能用IDFA，通过IDFA跟踪是主流方式。

IDFA匹配的过程如下：

2016年发布iOS 10 提供了Limit Ad Tracking，用户可以主动关于IDFA，发布28天后，Adjust发布一个报告显示约20%的用户会选择关闭IDFA，详情可以看：https://www.adjust.com/blog/limit-ad-tracking-rates-per-country/，但仍没有影响IDFA成为主流的跟踪模式。

2020年9月，即将发布的iOS 14给IDFA蒙上了一层阴影，iOS 14 之后，App在访问用户设备的IDFA之前，必须获取需要用户授权，弹出这个框框让用户去选择，会增加用户拒绝的风险，用户很有可能会拒绝，所以拿不到IDFA。如果用户选择关闭导致关闭的比例再下降的话，匹配的准确率极有可能低于模糊匹配的了，关于IOS14的影响可以看：iOS 14：苹果淘汰IDFA

IDFA随着苹果隐私政策的趋于偏向用户，让用户自己选择，慢慢应该会被淘汰。

拓展：自有ID体系

其实很多的工具或平台很早开始就使用自有的ID体系的，所以不管Android Q和iOS 14的隐私规则调整，都对其没有影响，因为人家根本就不依赖与IMEI和IDFA去识别用户，但没有太高调说。

• 腾讯灯塔：QIMEI是灯塔推出的终端ID精准识别体系，包含Android/iOS两类主流终端的识别。其主要思想为：SDK将各种ID采集上报，后台利用的ID关系库、山寨库和校准算法，实时生成/找回终端唯一ID并下发。
• TalkingData：TDID是基于SDK获取的设备信息以及常量参数并结合TD的加密方案生成一台设备的标识，以便持久化来保持设备的唯一性。
• 友盟：UMID是基于友盟+自己的设备ID生产算法，在APP的生命周期保持稳定性和唯一性。
• 易观argo：在SDK初始化完成之后会自动生成一个UUID作为匿名用户标识。
• Branch：Web和APP的SDK会结合用户浏览器内的cookie和设备ID，给该用户标注虚拟ID，这些用户ID最终形成数据库，从而实现用户在没有登录移动网页端的情况下，跨平台判定APP下载的渠道归属。

模糊匹配

跟Android的模糊匹配是一样的。

模糊匹配，也叫IP+UA，是指通过将用户点击广告时的 IP、User-Agent（简称 UA，用来提取用户的操作系统、版本号、手机型号等信息）信息与激活时的 IP、UA 进行关联匹配实现归因分析。

模糊匹配的实现方式如下：

这的很多厂商都在使用的一种方式，都强调很高识别率，但是这个严重更依赖于两次收集的信息、时间差和算法，一般匹配成功率在70%~80%。对于大部分人来说，算法是黑匣子的，即使第三方工具只是做了一个简单的优先级去匹配，然后对外宣称通过大数据，人工智能的方式去匹配，你也不知道的。

由于IP和UA会可能会重复，如多个用户使用同一个 IP等情况普遍，所以准确率不高，这是一种兜底的匹配方式，一般是实在没得选了，用这种。

Cookie

通过共享Cookie，在iOS 9中新增的SFSafariViewController，这个类的API允许在app内打开一个safari浏览器，而不是一个app内部的webview。这个app内的safari和外面系统的safari是同一个，共享同一个沙盒，可以操作同一个Cookie，也就是说它可以跨App与Safari实现共享Cookie。

当用户在App中通过它打开渠道页面时，我们可以将渠道信息写入Cookie中，并设置生效时间。当用户安装并激活 App后，再次使用SFSafariViewController上报激活信息，同时将Cookie中的渠道信息上传，通过匹配，便可确定下载来源。由于渠道信息保存在设备本地，因此匹配是100%准确的。

这种方式有很大的局限性，只是在safari和app共享cookie，所以其他浏览器不适用，跟踪不到，另外还需要向用户申请权限，简单说，就是一打开要有个用户确认的界面，知道你在跟踪，对用户的体验非常糟糕。

这种跟踪方式很少应用。

SKAdNetwork

SKAdNetwork是苹果在2018年推出的保护用户隐私的同时还能实现安装归因的一个方案，注意这里是安装归因，不是First Open，跟前面的是不同的。

原理如下：

如果用户点击广告，广告会将带有签名的广告信息带给App Store， 当广告点击带来转化（也就是应用下载）时，会通知App Store，并将带有基本归因参数的回传ping发送到广告网络。这个过程需要广告平台的支持，广告平台需要在苹果注册才能将带有签名的信息传递给App Store。

由于那时还能用IDFA，这种方式基本是被雪封的节奏，很少有工具会提供这种匹配方式，几乎没有广告平台去注册支持，因为它支持的功能可以说只能用于安装归因，不能用于再营销。

总结

总结一下，各种匹配方式的优缺点如下：

一般是使用IDFA精准匹配为主，模糊匹配为辅。也有部分产品也提供归因工具回传的方式。

动态流量主要是在投放程序化广告、Ad-Network、AFF的时候，不能提前预知流量来源于哪个域名，如投放程序化广告的时候，根本就不知道下一次广告来自于哪个域名，如可能来源于A.com、B.com、C.com……所以不可能提前就设置好UTM参数去跟踪，因为UTM中Source是要填来源于哪个域名，不懂UTM怎么用的可以看：渠道流量标记（UTM）

如我的着陆页是：https://www.ichdata.com

做程序化广告可以添加medium和Campaign：https://www.ichdata.com?utm_medium=cpc&utm_campaign=summer-sale

但是不知道来源于哪个网站的，所以Source为空

其实还是可以实现动态参数的跟踪，拿到该域名，这里讲的是通过Google Analytics来跟踪，有两种方式来实现：

• 方式一：通过Referral获取来源于哪个域名，用标准UTM格式重写网页地址
• 方式二：通过Referral获取来源于哪个域名，通过网址获取其他广告参数，覆盖Source、Medium和Campaign字段

方式一

原理：通过Referral获取来源于哪个域名，用标准UTM格式重写网页地址，实际上Google Analytics接收到的页面地址就是重写后的了，是标准UTM格式，从而实现跟踪动态流量。

这种方法是不规则站内搜索跟踪的变形，有兴趣可以看看不规则站内搜索跟踪的实现方法：https://www.ichdata.com/use-google-tag-manager-for-site-search-tracking.html

实现过程

下面来看看具体的实现过程：

假设我现在投放的着陆页的URL是这样的：

https://www.ichdata.com?utm_medium=cpc&utm_campaign=summer-sale&tt=change

现在我需要获取来源于哪个网站，获取来源网站的域名，并添加到utm_source上面去。

在Google Tag Manager中创建一个变量，命名为Source作如下设置：

这个就是获取流量来源的域名了。

然后再获取其他的UTM参数，这里需要获取Medium和Campaign。

创建第二个变量，命名为Medium，做如下设置：

创建第三个变量，命名为Campaign，做如下设置：

创建一个触发器，命名为Change Page URL，然后做如下设置：

tt=change是动态流量的标识，着陆页上带有这个的就是动态流量，需要改写URL的。

最后来配置Tag的了,创建一个Tag命名为标准UTM重写URL，然后做如下设置：

主要就是在Field Name中设置Page，Value就是标准化UTM参数，去覆盖Page这个字段，在Google Analytics中看到的就是标准化的UTM页面了。

还需要注意触发器是Change Page URL，只有带有tt=change动态流量的标识才会改写URL。

做到这里，还需要设置一步，就动态流量的页面排除出Google Analytics的基础跟踪，将触发器Change Page URL排除掉，不然会发送两次的：

方式二

原理：通过Referral获取来源于哪个域名，通过网址获取其他广告参数，覆盖Source、Medium和Campaign字段，这里的做法是直接覆盖UTM的每个字段。

实现过程

下面来看看具体的实现过程

大部分的设置是跟方式一是一样的，只不过在创建Tag后的设置不一样，我们这里直接将创建Tag的设置。

创建一个Tag命名为重写URL，作如下配置：

在Field Name中直接设置Source、Medium和Campaign。如果是动态流量，就自动获取值覆盖过去。

在Google Analytics的基础跟踪将触发器Change Page URL排除掉，不然会发送两次的：

这样就实现了动态流量的跟踪，做程序化广告的时候就可以知道流量来源于哪个域名，可以从域名角度分析动态流量的质量情况。