1.什么是多参数

而在埋点的需求当中，“多参数事件”的埋点又是比较常见的一种类型，当然，这个名词是友盟平台上这么称呼，在其他平台也有本质上相同但名称不同的埋点方式。那既然是“多参数事件”，首先冒出来的疑问，就是到底什么是多参数呢？ 

以网易音乐云平台举例，你想要统计全平台的用户在歌手主页，去分享一个歌手的时候一般会选择以什么渠道分享出去，以便根据数据去判断后续版本迭代时，要不要把某些比较冷漠的分享渠道拿掉。

如果你最终能查看到数据，其实你就已经可以脑补出最终你想要看到的结果大致是啥样了：

从上面就可以看出我们需要统计的都是分享渠道以及对应的次数和人数，有的人可能就会直接将这所有的分享到对应渠道的行为定义成几个不同的事件，然后就进行埋点统计了，这样不是说不可以，只是会显得比较麻烦而且如果将一个App上所有的行为都定义成事件，对于很多App都会超过500个事件的上限了（友盟限定了事件上限为500个）。

而从另外一个角度分析，无论是分享到朋友圈还是好友亦或其他渠道，本质上其实都是基于分享这个操作进行的子操作，要去统计的是某个子操作的使用次数时，实际上可以看做是对分享操作的更多补充和描述，所以在这种场景下，如果把分享定义成一个事件时，分享渠道就可以定义成参数，具体可以分享到哪些渠道就是可以取的参数值，要统计的次数、人数等都是对参数值进行的具体统计。

2.产出需求

明确了上面场景后，就可以按照之前的文章中讲到的去产出埋点的需求了，格式就大致如下：

这样将埋点当中所需的必要信息，事件id、事件名称、参数id、参数值就已经提供了，至于表格当中的其他信息，主要是为了能够让相应的人员明白各个埋点事件以及参数的含义而提供的补充信息。

3.查看数据

按照上面表格的多参数事件进行埋点，有了相应的操作后，就能够查看到对应的埋点数据信息，在友盟上如下所示：

上图显示对应的事件id + 事件名，同时会展示对应的报表数量，可以根据时间、版本、渠道等维度筛选。

 下图则显示的是该事件下的参数可以取的参数值的实际数据情况，当产生了更多参数值的数据时，就会在下面的报表当中出现。