查询条件直接设置成页面级变量

适用于 SDK 2.x 以上，12 月 11 日上线。

打开你的网址，看一看你的链接，是不是经常有这样的部分：

https://www.growingio.com/projects/1/homepage/overview?platform=ios&channel=banner

“?”后面的部分我们通常叫做查询条件（Query），在这个 URL 中标记了这个页面是在哪个平台（platform）打开的，以及通过哪个渠道（channel）访问的等重要信息，不同的公司有不同的应用，这种应用非常常见，那么，我们如何把这些重要的信息利用起来呢？

现在不需要埋点和开发，可以直接将这些查询条件设置成页面级变量，即维度；不仅如此，相比与埋点信息的延时发送，GrowingIO 将页面与查询条件中的信息同时发送、采集和计算，没时差，再也不会有那么多的空值了。

1.将查询条件直接设置成页面级变量

作为 SDK 版本为 2.x 以上的用户，现在就可以在「事件和变量」和「web 圈选」中直接设置查询条件为页面级变量（即维度）了：

web 圈选

遵循两个原则：

1.全局生效。一旦设置，全站采集，对域名下的所有加载了 SDK 的页面生效。

2.埋点优先。埋点页面的数据不受任何影响，只在没有埋点或延时导致埋点数据没有发出来时，会取与「标识符」相同的查询条件对应的值。

2.案例详解

如果你之前进行了埋点，那么这个功能上线后会发生什么变化呢？

电商客户 S 为了分析商品的售卖情况，在详情页进行了埋点，将每个商品的编号、商品名称等设置成了页面级变量，已经实施后上线了，其中商品编号标识符为 id，是从内容中取值的。接下来，用户用这个页面级变量来拆分商品详情页，进行分析。

假设商品详情页的 URL 是这样的 www.s.com/pro?id=342817&city=bj ，我们可以看到查询条件中的 id 就是这个商品的商品编号， 当这个功能上线后，由于「商品编号标识符： id」与「查询条件中的：id 」是一样的，我们会从打点设置的规则和 URL 中的查询条件中同时取 id 的值，有如下几种情况：

表格第四列「埋点取的值」 - 客户打点时的规则是从「内容」中取值；

表格第五列「URL 取的值」 - 这个功能上线后我们从 URL 中取到对应的 key 的值。

对于下面表格内容的总结

1.只要埋点取到了值，就取埋点的值。（表格中的第 1 个和第 2 个情况）

2.如果一个页面上，没有埋点的值，不管是因为这个页面没有埋点，还是因为发送时间导致没有发送出来，会取查询条件中取到的值。（表格中的第 3 个和第 4 个情况）

#		变化	埋点取的值	URL 取的值	之前	之后
第 1 个情况	商品详情页1 商品页内容中的值 342817 www.s.com/pro?id=342817&city=bj	无变化	342817	342817	342817	342817
第 2 个情况	商品详情页1 商品页内容中的值 ac487 www.s.com/pro?id=342816&city=bj	无变化	ac487	342816	ac487	ac487
第 3 个情况	商品详情页2 商品页内容中的值 342815 ，但是因为时间的缘故，没有发出来这个值 www.s.com/pro?id=342815&city=bj	补了值	NA	342815	NA	342815
第 4 个情况	商品订单页1 订单页没有打点，所以这里没有打点的值 www.s.com/orderform?id=53462&city=bj	补了值	NA	NA	53462 ⚠️：本来用户没有打点，拿不到数据，现在有了订单编号业务意义的数据。这个业务意义与前面的商品编号不同。	53462

3.其他特殊情况

• 取到的查询条件是b=时，则传 N/A，与现在一致；

• 查询条件里有 b=1&b=2 ，取 b 的值为 2 ；

• URL 中存在 ?a=1#?b=2 ，第一个?是查询条件，即查询条件为a=1，第一个#是hash，即hash（路径中的一部分）为?b=2；

• 解析移动端的数据；