| description |
|---|
适用于 SDK 2.x 以上，12 月 11 日上线。 |
打开你的网址，看一看你的链接，是不是经常有这样的部分：
https://www.growingio.com/projects/1/homepage/overview?platform=ios&channel=banner
“?”后面的部分我们通常叫做查询条件（Query），在这个 URL 中标记了这个页面是在哪个平台（platform）打开的，以及通过哪个渠道（channel）访问的等重要信息，不同的公司有不同的应用，这种应用非常常见，那么，我们如何把这些重要的信息利用起来呢？
现在不需要埋点和开发，可以直接将这些查询条件设置成页面级变量，即维度；不仅如此，相比与埋点信息的延时发送，GrowingIO 将页面与查询条件中的信息同时发送、采集和计算，没时差，再也不会有那么多的空值了。
作为 SDK 版本为 2.x 以上的用户，现在就可以在「事件和变量」和「web 圈选」中直接设置查询条件为页面级变量（即维度）了：
{% hint style="info" %} 遵循两个原则：
1.全局生效。一旦设置，全站采集，对域名下的所有加载了 SDK 的页面生效。
2.埋点优先。埋点页面的数据不受任何影响，只在没有埋点或延时导致埋点数据没有发出来时，会取与「标识符」相同的查询条件对应的值。 {% endhint %}
如果你之前进行了埋点，那么这个功能上线后会发生什么变化呢？
电商客户 S 为了分析商品的售卖情况，在详情页进行了埋点，将每个商品的编号、商品名称等设置成了页面级变量，已经实施后上线了，其中商品编号标识符为 id，是从内容中取值的。接下来，用户用这个页面级变量来拆分商品详情页，进行分析。
假设商品详情页的 URL 是这样的 www.s.com/pro?id=342817&city=bj ，我们可以看到查询条件中的 id 就是这个商品的商品编号， **当这个功能上线后，由于「商品编号标识符： id」与「查询条件中的：id 」是一样的，我们会从打点设置的规则和 URL 中的查询条件中同时取 id 的值，**有如下几种情况：
表格第四列「埋点取的值」 - 客户打点时的规则是从「内容」中取值；
表格第五列「URL 取的值」 - 这个功能上线后我们从 URL 中取到对应的 key 的值。
{% hint style="success" %} 对于下面表格内容的总结
1.只要埋点取到了值，就取埋点的值。（表格中的第 1 个和第 2 个情况）
2.如果一个页面上，没有埋点的值，不管是因为这个页面没有埋点，还是因为发送时间导致没有发送出来，会取查询条件中取到的值。（表格中的第 3 个和第 4 个情况） {% endhint %}
| # | 变化 | 埋点取的值 | URL 取的值 | 之前 | 之后 | |
|---|---|---|---|---|---|---|
| 第 1 个情况 |
商品详情页1 商品页内容中的值 342817 |
无变化 | 342817 | 342817 | 342817 | 342817 |
| 第 2 个情况 |
商品详情页1 商品页内容中的值 ac487 |
无变化 | ac487 | 342816 | ac487 | ac487 |
| 第 3 个情况 |
商品详情页2 商品页内容中的值 342815 ，但是因为时间的缘故，没有发出来这个值 |
补了值 | NA | 342815 | NA | 342815 |
| 第 4 个情况 |
商品订单页1 订单页没有打点，所以这里没有打点的值 |
补了值 | NA | NA |
53462 |
53462 |
- 取到的查询条件是b=时，则传 N/A，与现在一致；
- 查询条件里有 b=1&b=2 ，取 b 的值为 2 ；
- URL 中存在 ?a=1#?b=2 ，第一个?是查询条件，即查询条件为a=1，第一个#是hash，即hash（路径中的一部分）为?b=2；
- 解析移动端的数据；
****