真珠美学新浪HubbleData无埋点SDK在iOS端的设计与贯彻

(2) 各种子页面的controller相同?

其实做过此类页面的着力应该都通晓,很多景色下子页面都是公共的,只然而是填写的model不同而已,那么遇到这种状态,尽管是比照问题1的缓解思路,固然如约2.2得到了当下页面的controller,那么依旧不能区分出那么些页面,所以依然需要设置新的兼具辨识度的index。

实际通过pageViewController可以发现,用户可以经过左右滑行或者前后滑动来切换子页面,表达拥有的子页面都是置于在一个scrollView之中,那么就足以从这一个scrollView出手,重新规定index。下边给出HubbleData解决那一个问题的措施。

一起始想行使当前scrollView的contentOffset整除此pageViewController的页面宽度和冲天所得到的值作为区分子页面的index,可是考虑到可能contentOffset的连天变化以及子页面横跨pageViewController整数倍宽度的境界时,可能会促成获取的index不唯一的情况,所将来来使用该子页面的前奏地点整除pageViewController的照应地宽度和惊人拿到相应地index。具体的兑现如下,其中controller为当前的页面:

 if (view == controller.view || view == controller.view.superview) {
      NSInteger index_x = view.center.x / [view superview].frame.size.width;
      NSInteger index_y = view.center.y / [view superview].frame.size.height;
      NSString *path = [NSString stringWithFormat:@"%@(indexx:%ld indexy:%ld)",  
                        NSStringFromClass([view class]), index_x, index_y];
  } 

由此一律针对上述(1)所提交的五个ViewController1,优化后的到的绝无仅有的标识为:

ViewController1对应路径为:superview(0)_subControllerView(indexx:0 indexy:0)
ViewController2对应路径为:superview(0)_subControllerView(indexx:1 indexy:0)
ViewController3对应路径为:superview(0)_subControllerView(indexx:2 indexy:0)
ViewController4对应路径为:superview(0)_subControllerView(indexx:3 indexy:0)

这样虽然各样子页面的controller相同,也能由此优化后的index来分别各个不同的子页面。当然这种只是指向嵌套scrollView的子页面的情形,可是能迎刃而解大部分的此类问题,对于有些别样的与众不同境况等,需详细分析页面布局举行分析。

3.2 UIViewController的无埋点采集

着重是采集页面的生命周期,那里HubbleData采纳的是hook
UIViewController的view威尔Appear方法,按照3.1付给的章程:

 [DASwizzler swizzleBoolSelector:@selector(viewWillAppear:)
                         onClass:[UIViewController class]
                       withBlock:executeAppearBlock];

当view威尔(Will)Appear函数执行时,插入埋点的代码。HubbleData的规划格局为:

伊芙ntID设置为一定的da_screen,即不会由此伊芙ntID来区分各样页面的信息,HubbleData将依次页面的区别音讯放在了properties中,其中properties的设置为:

(1) $screenName 为当前页面的名称;
(2) $screenTitle 为当前页面的title,可为空;

并且HubbleData SDK提供了一个protocol <DAScreenAutoTracker>

即用户可以透过实现该protocol,HubbleData
SDK会将screenTitle重回的值作为页面的名目,trackProperties再次来到的特性参与对应页面的da_screen事件的性质中,作为用户访问该页面时的事件性质,screenUrl重临的字符串作为页面的Url,用于做一些页面之间交互跳转的剖析等。

而且增添了白名单设置,有一部分UIViewController的音信用户不想采访,可以因而设置白名单的方法,将部分不想征集的UIViewController过滤掉,比如说SFBrowserRemoteViewController,UIInputWindowController等序列自带的一部分。

最后会调用track伊夫nt记录该征集的风波,同上述介绍的代码埋点一样,调用的章程如下:

[[DATracker sharedTracker] trackScreenEvent:@“da_screen” withAttributes:properties];

个中properties即为上述要搜集的片段特性。

2.2 当前页面controller的取得

看上去,大多数气象下2.1的view的层级结构path已经基本确定view的绝无仅有标识字符串,不过普遍存在这么一种情状,当同一个页面跳转多少个不等的页面时,即便这六个例外的页面上都取第一个按钮的层级路径,拿到的简化后的结果都如下所示:

.../UINavigationTransitionView(0)/UIViewControllerWrapperView(0)/UIView(0)/UIButton(0)

是无能为力展开这多少个页面上的按钮区分的,其实页面的类名是分另外一个最直白的点子。HubbleData是遵照下边的主意得到某个view所在的controller的类名的。

取得当前controller示例

将view的层级路径结合当前页面的称号,已经可以解决掉大部分的唯一标识字符串的题目了。

此地需要小心的一些是,当页面类型一样,只是填充的model不同时,比如浏览商品详情时,所进入的页面都是一个,只是model不同,近年来HubbleData对这种气象临时未做拍卖。后续可参看小说3.2节UIViewController的无埋点采集,对一部分页面,用户可以自定义诸如screenTitle的字段,定义该页面的称谓,比如screenTitle包含产品唯一ID时,此时将该字段出席唯一标识字符串中即可区分。近来这块还未做连锁处理,这里只是提供一个简短的缓解思路。

1.2 无埋点SDK设计详细流程

下图给出HubbleData无埋点SDK在iOS端的设计实现:

无埋点详细计划流程

从上图能够见见,HubbleData的无埋点是在代码埋点的基础上实现的,所处无埋点的难关也就集中在偏下多少个方面:

(1)自动获取埋点的EventID
(2)自动获取埋点的时机
(3)自动获取埋点需采集的属性

正文紧要就这六个地方进行分析,第二局部至关首要讲一下事变唯一ID的确定,第三片段首要讲一下无埋点的搜集的贯彻,重如果各类风波暴发采集的机会以及待采集的特性的配备。

HubbleData
SDK还论及到广大任何职能,包括屏幕序列可视化、代码埋点、精准渠道追踪等,这里不再介绍,后边会陆续分享相关的技巧实现。

2.1.2 三种分外情形的拍卖

2.1.1重点讲的是局部平凡view的层级结构的path构造格局,不过有一些新鲜情状需要特此外考虑处理:

  • UITableViewCell

由于UITableViewCell具有可复用的体制,当一个页面中在持续滚动的时候,cell在持续的复用,倘诺还动用2.1.1中介绍的模式来得到index索引值话,那么会唤起上上下下页面无埋点数据收集的混杂。

当得到当前UITableViewCell的index时,可以应用indexPath参数举行沟通,那个参数可精确的取得section和row的值,唯一的呼应每一个cell。唯一层级路径的款型得以自定义配置,HubbleData的设置方法为:类名+(section:
row:),下边给出一个演示:

MyTableViewCell(section:0 row:7)
  • UICollectionViewCell

UICollectionViewCell的path生成原理同UITableViewCell,HubbleData的安装格局为:类名+(section:item:),下边给出一个示范:

MyCollectionViewCell(section:0 item:7)
  • UIControl

实质上UIButton也终于一种普通view的一种,大多数情状下,使用上述的层级结构path以及页面类名的构成可以唯一的确定当前UIControl的绝无仅有标识符,不过有一种特此外动静,当作为UINavigationItem时会出现相当情况,下边的所提交的三个例子。

bar1

bar2

当点击第一个NavigationBar的左边的按钮时,得到的层级路径为:

...UIViewControllerWrapperView(0)_UIView(0)_UILayoutContainerView(0)_UINavigationBar(0)_UIButton(1)

解析可知,右侧的装置按钮的目录为0,所以左边的按钮索引为1。同时拿到的当下页面为:UINavigationController。

当点击第二个页面的同一个连串的按钮时,即一律标有数字7的item时,此时得到的层级路径为:

...UIViewControllerWrapperView(0)_UIView(0)_UILayoutContainerView(0)_UINavigationBar(0)_UIButton(2)

能够窥见此时的按钮的目录变成了2,已经不同于上述第一个NavigationBar的同一个按钮的层级路径了,经过分析,索引值为1的按钮是最右面的报表的不胜item,经过证实可以拿到其层级路径:

...UIViewControllerWrapperView(0)_UIView(0)_UILayoutContainerView(0)_UINavigationBar(0)_UIButton(1)

取得的页面为:UINavigationController。

其实这种页面很广泛,由于页面的切换,NavigationBar上的有的按钮的岗位也许顺序会打乱,导致同一个效率的NavigationItem已经无力回天确定标识唯一,即使是拿到了当前按钮所在的页面也无力回天区分,因为获取的都是UINavigationController。从下面的剖析可以看看,这种景色依然会导致严重混乱的数据收集。

实际上仔细分析一下,固然条分缕析得出该UIControl是在UINavigationBar上,则无需安装其相应的index值,即上述的持有navigationItem的层级结构路径都为:

...UIViewControllerWrapperView(0)_UIView(0)_UILayoutContainerView(0)_UINavigationBar(0)_UIButton

即都不做区分。

HubbleData选择扩大一种新的性能来区别各种item,其实很肯定可以看出来,这一个item的实践的action肯定是不同的,所以取其action属性来区分,最终的区分情势如下:

path(...UIViewControllerWrapperView(0)_UIView(0)_UILayoutContainerView(0)_UINavigationBar(0)_UIButton)&actions(button1Click:)
path(...UIViewControllerWrapperView(0)_UIView(0)_UILayoutContainerView(0)_UINavigationBar(0)_UIButton)&actions(button2Click:)

这么,HubbleData就足以规范的区分不同的item了,同时实现均等种功用的item,由于其action相同,所以也会准确的标识其唯一性。

  • UIAlertController

出于不同的UIAlertController在增选确定、撤废等选项时,选用的举办唯一层级路径判定的view需要展开一定的处理,同时为了保险不同的UIAlertController处于同一职位的挑选的埋点伊芙(Eve)ntID不同,那里在布局唯一标志字符串的时候还要出席该UIAlertController的message和title音信。3.5小节中会举办相关无埋点采集的牵线。

  • viewController的嵌套

貌似景观下,普通的view只需遵照一般的层系路径收集index即可,然则当存在pageViewController时,如下图所示分别交付了一个横向滚动(以公司考拉app为例)和纵向滚动(以店堂严选app为例)的app的截图的演示:

实质上可以看出,pageViewController会应用到见怪不怪app中,所以这类app在动用过程中的无埋点问题越是要考虑。

3.3 UIControl的无埋点采集

本着UIControl,HubbleData采取的是hook
UIControl的sendAction:to:for伊芙(Eve)nt:方法。由法定文档可知,在UIControl执行相应的action时都会率先调用sendAction:to:for伊夫(Eve)nt:方法,实现如下:

control

设想到UIControl的子类较多,所以HubbleData接纳了里面使用较多的三种举行了独特的解析:首如若UITextField(Field)、UIButton和UISwitch,此外的临时未做特殊分析。具体的埋点的收集计划为:

不论是哪一类UIControl,伊芙ntID均采纳的是第三有的介绍的唯一标识字符串的SHA256编码值,然则相关采访properties有所差别。

二、事件唯一ID的确定

为了贯彻在可视化圈选的时的风波的唯一性,每一个无埋点的轩然大波采访都不可能不有且仅有一个唯一的标识符来区分不同的事件。不同于代码埋点,用户可以自定义的布置自己所需的伊夫(Eve)ntID,无埋点过程中,需要SDK自己布置每一个征集事件的伊芙ntID,通过可视化圈选的操作,筛选出相应的伊芙(Eve)ntID所对应的数据音讯。HubbleData拔取的是构造view唯一标识字符串的办法去唯一的标识这样的一个风波,紧要由view的层级结构path路径、该view的处处页面类名以及view所带的部分本身定位属性等组合,并经过SHA256编码来获取唯一的伊芙ntID。

下边将完整系统介绍一些事变唯一ID的变化过程。

3.3.4 其余UIControl

此外的只是采集type,page属性,近期未做过多的处理。

四、总结

作品紧要介绍了HubbleData无埋点SDk在iOS端的设计与落实,涉及的首要性内容:事件唯一ID的确定和局部无埋点的兑现,当然在无埋点SDK的计划开发中还遇上了多种多样的问题。鉴于小说的篇幅已经较长,一些题材的解决以及关键技术的兑现,比如精准渠道追踪、hook争辨解决、代码埋点的贯彻、屏幕体系化以及可视化圈选部分的内容,本篇小说不再介绍,将会在后续随笔中持续介绍。

一、埋点简介

>三、无埋点的搜集的实现

3.5 UIGestureRecognizer的无埋点采集

在iOS开发中,平常会动用部分手势来拍卖部分点击的操作,所以也有必不可少对UIGestureRecognizer举行hook。HubbleData
并不是一向针对UIGestureRecognizer这么些类举办hook,而是hook
UIView类的addGestureRecognizer:方法,实现如下:

gesture

经过hook
addGestureRecognizer:方法,可以得到该UIView所添加的UIGestureRecognizer,那里只对UITapGestureRecognizer和UILongPressGestureRecognizer举办处理,其他的手势暂未做处理。拿到相应的UIGestureRecognizer,添加一个action,当该手势执行的时候,同样会履行该action,在action中举办埋点的操作。

此间收获的是UIGestureRecognizer所在的UIView的绝无仅有标识标识字符串编码作为伊芙(Eve)ntID,采集的性质为:

(1) type 为UIGestureRecognizer采集的事件类型,这里设置为gestureTapEvent;
(2) page 为当前页面的名称,用于前端显示用;

UIAlertController的奇特处理

此处需要对UIAlertController做一个详实的认证,因为UIAlertController在点击诸如撤除、确定的选项按钮时,也会进展手势的埋点采集,然而在iOS9和iOS10上有点有些区别。

此处先以iOS9为例,其target是效能在_UIAlertControllerView这些系统的私有类上的,要是平昔对这么些_UIAlertControllerView举行唯一标识字符串的协会,则撤销和确定选项得到的伊芙(Eve)ntID是相同的,这样将不可能精确的辨析出用户的精选,所以必须以每个选项view作为独立的绝无仅有标识字符串举行解析才能规范区分。通过拿到_UIAlertControllerView的_actionViews变量,就能博得各种选项的view,这里要做一个概括的点击坐标获取,判断所点击的区域位于的actionView,具体实现如下:

这边在基准判断时设定gesture.state ==
UIGestureRecognizerStateBegan,是由于UILongPressGestureRecognizer会连续五次调用action,因而这里需要投入事件的场所举行区分,避免举办三回相同的数额收集。

iOS10下的UIAlertController的内部贯彻做了有的改观,其target变换成在_UIAlertControllerInterfaceActionGroupView这一个系统的私有类上的,然后需要展开一定的处理,获取UIInterfaceActionSelectionTrackingController的_representationViews变量,遍历得到各类选项的view,具体落实如下:

经过上述的剖析可以发现,那样即使能分别同一个UIAlertController的例外的操作选项,不过或许无法区分出不同UIAlertController的处于同一职位的选项,所以那边还要进入UIAlertController额外的特性音信来分别。

眼前也有提过,能够很容易的想到UIAlertController的message和title可以较好的展开区分,所以在原始的层级路径和脚下页面的根基上,还要加上message和title以组合唯一标识字符串。给出一个样例:

path(UIWindow(0)__UIAlertControllerView(0)_UIView(0)_UIView(0)_UIView(0)_UICollectionView(0)__UIAlertControllerCollectionViewCell(section:0 item:0)_UIView(0)__UIAlertControllerActionView(0))&controller(UIAlertController)&message(确认退出群聊吗?)&title(退群)

2.1 控件的层级结构path构造

(1) 各类子页面的controller不同?

一经pageViewController中的各种子页面不同,虽然持续2.2节HubbleData会参与页面controller的音信来分别那些不同的子页面,但是也许会由于每个子页面参与的相继不同,导致每趟app进来的时候同一个页面的轩然大波会赢得不同的伊夫ntID,举例来表明一下,如上图1所示,比如前两个子页面是ViewController1,
ViewController2, ViewController3,
ViewController4,这类pageViewController除非设置多少个子页面同时预加载出来,那么此时的取得的层级路径为:

ViewController1对应路径为:superview(0)_subControllerView(0) 
ViewController2对应路径为:superview(0)_subControllerView(1)
ViewController3对应路径为:superview(0)_subControllerView(2)
ViewController4对应路径为:superview(0)_subControllerView(3)

然则app基本都不会预加载出富有页面,对于用户不感兴趣的页面完全没必要三次性全部加载处理,只有当用户挑选了该条款时,该对应的子页面才会加载出来,如若现在用户点击的顺序是ViewController1,ViewController3,ViewController4,ViewController2,由于addChildViewController或者addSubView的相继的变动,那么此时获取的层级路径为:

ViewController1对应路径为:superview(0)_subControllerView(0) 
ViewController2对应路径为:superview(0)_subControllerView(3)
ViewController3对应路径为:superview(0)_subControllerView(1)
ViewController4对应路径为:superview(0)_subControllerView(2)

可以发现,index值变了,层级路径不唯一了,那么无埋点采集的伊芙(Eve)ntID可能会由于用户挑选页面顺序的不比而各异,造成埋点数据的繁杂。

HubbleData对于此类页面的拍卖是,遭逢此类页面,即不用index标注,所以会联合的标识成:

ViewController1对应路径为:superview(0)_subControllerView 
ViewController2对应路径为:superview(0)_subControllerView
ViewController3对应路径为:superview(0)_subControllerView
ViewController4对应路径为:superview(0)_subControllerView

连续可以透过不同的页面的controller的类名获取其不同的绝无仅有标识字符串。

3.1 AOP 简介

下边讲一下无埋点的切实落实,用到的首假设AOP(Aspect-Oriented-Programming),面向切面编程,面对的是处理过程中的某个步骤和艺术。在运行时,动态的将代码插入到类的创立措施、指定地点上的编程思想就是面向切面编程。熟习iOS
Runtime的应当很领会,相关的介绍著作也很多,这里不再过多的废话。

HubbleData无埋点的落实重点就是借助AOP,hook对应类的法子,并在原实现代码的根基上插入自己定义的埋点的代码,当该类的被hook的函数执行时,就能促成无埋点数据收集的遵守。下边给出HubbleData里面Method
Swizzling的一个大概的兑现。

Method Swizzling

上述代码只是给出了一个简单的实现的逻辑结构,new_swizzledMethod也只是selector没有参数的气象(除去self和_cmd),真正在埋点的处理过程需要考虑的情状相比较多。

3.3.2 UIButton

UIControl中应用最多最广大的是UIButton,由此对UIButton的采集至极重大。在利用UIButton的时候可以肆意的装置其title等性能来表示事情逻辑的两样境况。这里可以举一个大概的事例:基本app的记名页面,在用户名和密码都未输入时、都输入时以及登录中逐条状态,登录按钮的title、titleColor等特性可能都是不同的,即每一种button的样式都代表着一种体制,不过得到的伊夫(Eve)ntID是一样的。针对此种情状,HubbleData会投入title、titleColor作为属性值,以方便后台举行进一步的辨析。

当按钮的两种情形只是二种不同的背景图片时,比如和讯仍旧微信的点赞等,其实是更换了一种背景图片,针对对这种情景处理,HubbleData则会获取图片的imageName作为内部一个属性。

(1) type 为UIControl采集的事件类型,这里设置为buttonEvent;
(2) page 为当前页面的名称,用于前端显示用;
(3) title 为当前按钮的title;
(4) titleColor 为当前title的color,会转换成字符串的形式,rgba(r, g, b, alpha);
(5) imageName 为当前按钮的背景图片的name;
(6) frame 为UIButton的frame,用于分析同类元素,会转换成字符串的形式,rect(x, y, width, height);

可以看到,HubbleData还采访了该view的frame消息,重如果用来分析同类元素用的,下图给出一个简单易行的演示:

button

当下有多少个已关注的成品,当想总结用户拥有点赞的轩然大波时,由于每个点赞的按钮都远在一个UITableViewCell中,在前边介绍的收获层级唯一路径UITableViewCell时的超常规处理,由于每个按钮所在的cell的row不同,所以拿到的各样按钮的风波的唯一伊芙(Eve)ntID都是见仁见智的,这样后端在解析的时候,无法归类同类元素。当HubbleData给出frame时,后端可以依照frame归类出同一类按钮的风波,具体的分类策略这里不再介绍。

3.4 UITableView和UICollectionView的无埋点采集

针对UITableView和UICollectionView,HubbleData采取的是先hook
UITableView和UICoolectionView的setDelegate:方法,然后找到呼应的delegate,然后再hook
delegate类中的tableView:didSelectRowAtIndexPath:方法和UICollectionView的collectionView:didSelectItemAtIndexPath:方法。这里以UITableView为例:

tableview

伊芙(Eve)ntID依据上述介绍的方法取得,只不过这里要留心的是,获取的并不是UITableView的绝无仅有标识字符串而是对应的点击的cell的唯一标识字符串。采集的properties为:

(1) type 为UITableView采集的事件类型,这里设置为tableViewSelectEvent;
(2) page 为当前页面的名称,用于前端显示用;
(3) section 为点击的cell所在的section;
(4) row 为点击的cell所在的row;
2.1.1 普通view的层级结构path构造

层级结构path重假使遵照页面的控件树构造而成,每个view都有superview与subviews的性能,将每一个view的superview作为树的父节点,将其subviews作为子节点,这样就能把整个app上的保有view组成一棵巨大的控件树,其中树的顶层是UIWindow,然后是每一个view节点依次向下展开。下图给出一个简便的控件树的结构图。

空中树结构

下面会详细介绍一下HubbleData的绝无仅有标识路径的构造形式。

不同类

同类

像上图1所示,即使一个view的subviews中都是见仁见智门类的,比如像下图图1所示的控件树那样,可以唯一标识UILabel和UIButton控件为:

UIView_UILabel
UIView_UIButton

只是的确的页面是不会像可以中的所有控件都是例外类型的,可以说这种至极气象基本不设有,假若仍然依照上述的法子来协会路径的话,六个UILabel都会被标识成UIView_UILabel,那肯定无法区分五个控件。由此惟有是各个控件节点的途径名称是心有余而力不足唯一标识这个控件的,这里HubbleData参与了此控件节点在父视图中的index。比如上图2,可以将六个UILabel标识为:

UIView(0)_UILabel(0)
UIView(0)_UILabel(1)

此处假如父视图是index为0的一个节点,这样就足以完全的界别出五个控件了。

这就是说余下的问题就是各种UIView index索引值的规定。

各种UIView都有subviews属性,每一个子视图都有一个被addsubView的次第,其实要拿的这些index就是子视图被add的顺序,那么该怎么拿到这多少个顺序呢,在苹果的法定表明文档中,岁UIView的subviews属性,是这般介绍的:

@property(nonatomic, readonly, copy) NSArray *subviews

You can use this property to retrieve the subviews associated with your custom view hierarchies. 
The order of the subviews in the array reflects their visible order on the screen.

即每一个子视图在那多少个subviews数组中的索引就是HubbleData要拿的index。

本着繁复的视图情势,如下图所示,遵照上述的层级结构路径构造方法得到的绝无仅有层级路径为:

UIView(0)_UILabel(0)
UIView(0)_UIButton(1)
UIView(0)_UIButton(2)  

混合

从上述的分析可知,遵照上述介绍的措施开展view的唯一层级路径标识,对大多数的页面来说早已丰裕,不过对于有些进一步灵活点的页面,由于一些事情要求等原因,开发人士通常会调用removeFromSuperview,
insertSubview:atIndex:, insertSubview:
belowSubview:等函数,都会极大的熏陶整个页面的subviews的索引值,比如现在本身将上图所示的UILabel移动到六个UIButton的末尾,那么得到的绝无仅有层级路径为:

UIView(0)_UIButton(0)
UIView(0)_UIButton(1)
UIView(0)_UILabel(2)  

混合

可以发现,唯一层级路径已经被改变,不过整个页面却并未暴发变化,不仅会发出新的轩然大波(比如UIButton(0),UILabel(2)),连UIButton(1)事件的采集也会出错,固然是见仁见智的风波,却收获了不同的eventID,所以需要提升协会的层级结构路径的稳健型。

正像刚刚提到的,不同档次的UIView不需要做index的分别,那么在赢得这么些index的时候,不是大概的从subviews这个数组中获得其相应的索引值,而是举行一个简单易行的同类归并再取索引值,一个很简单的拍卖。

for (UIView *view in subviews) {
    if ([NSStringFromClass([subview class]) isEqualToString:NSStringFromClass(class)]) { //class为待筛选的类
        [array addObject:view];
    }
}

如此这般就足以得到array中的index作为其确实的索引值,得到的层级结构路径为:

UIView(0)_UILabel(0)
UIView(0)_UIButton(0)
UIView(0)_UIButton(1) 

这儿无论UIlabel的职位位于哪个地方,都不会转移那个路子的社团样式,大大扩充了稳健型。其实也能发现,这只是只可以加强稳健型,并无法从根本上解决那么些问题,比假设我把五个UIButton的一一交换了,或者去除了第一个,此时照例会拿走一些不准确的层级路径。此题材会连续解决,会渐渐引入误差容量和相似度这么些定义,即要是在误差范围内,则会展开更为的配合,具体的化解方案本篇不在介绍。

0 引言

目前在承受店铺的HubbleData的埋点SDK的开发任务,产品的雏形其实在几年前就曾经有了,集团内部的例如考拉、易信、LOFTER、美学、漫画等多款产品都已接入使用。

下图给出HubbleData SDK某个应用的部分分析的显示页面:

(1)概览示意图

事件

(2)事件分析示意图

事件

(3)实时分析示意图

事件

除此以外HubbleData平台还有所留存分析、漏斗分析、粘性分析、数据看板等多种职能,方便有关负责人员对产品用户作为展开更进一步的商量分析。

老版本的SDK的统筹是代码埋点实现的,即使对于一些相比成熟的出品,代码埋点完全可以达成产品方的要求,可是对于有些新启动或者需频繁转移的急需的新产品等,考虑到其珍爱的资金大,代价高等缺点,HubbleData无埋点SDK的规划就显得更为重大了。

我根本负责iOS端无埋点以及可视化圈选的工作,小说首要系统讲授一下HubbleData无埋点SDK在iOS端的设计与贯彻和有些息息相关题材的缓解,后续将本着所有埋点的兑现流程与可视化圈选等情节再作分享。

3.3.3 UISwitch

接近于UIButton,只但是这里要收集switchState,即当前的开关状态,具体的收集属性为:

(1) type 为UIControl采集的事件类型,这里设置为switchEvent;
(2) page 为当前页面的名称,用于前端显示用;
(3) switchState 为switch的开关状态;

1.1 二种埋点的落实模式简介

埋点的艺术分为三类:代码埋点、可视化埋点和无埋点。这里大概的牵线一下两种埋点情势:

(1)
代码埋点即是在代码的关键部位植入所要收集数据的N行代码,需要挖开产品自己,深刻摸底产品的事体逻辑及项目社团,下边代码模拟呈现的即是点击提交订单的时候HubbleData
SDK代码埋点;

代码埋点示例

(2)
可视化埋点即用可视化交互的法子圈选出所要采集数据的控件,当用户作为暴发时,即可收集到对应的埋点数据。相比较于前方的代码埋点而言,可视化埋点可以缓解代码埋点代价大成本高的问题,可是无法灵活的自定义埋点属性。

可视化埋点流程

(3)
无埋点也叫全埋点,即不需要用户积极埋点,可以收集用户拥有的操作行为,同样应用可视化圈选,用户可以得到所想采集的埋点数据,可以缓解可视化圈选中数据不可回溯的题材。下图给出了无埋点数量收集的简单流程。

无埋点数据收集流程

HubbleData
SDK的规划重点是代码埋点结合无埋点的数额搜集形式,其中也涉及到可视化埋点中的屏幕系列化及事件绑定机制,本文紧要介绍一下无埋点的宏图与实现。

3.3.1 UITextField

UIText菲尔德(Field)(Field)是UIControl的一个子类,由于UITextField(Field)涉及到用户的隐情相比多,比如用户名、密码、聊天文本等,所以HubbleData不会对该类的UIText菲尔德(Field)举行埋点的采集。

HubbleData重要收集的是UISearchBar中的UITextField(Field),即UISearchBarText菲尔德(Field)(Field),并得到搜索的文件内容,这对于一些电商类的App来说,可以较好的剖析用户感兴趣的货色等,这是作为HubbleData
SDK无埋点的一个急需。

hook住sendAction:to:forEvent:后,如果对UISearchBarTextField的所有actions都进行hook的话,那么_searchFieldBeginEditing、_search菲尔德(Field)(Field)EndEditing等有着的action暴发的时候都会展开数据的采集,会采集到许多无效的音信,导致采集的多少错乱。HubbleData
SDK只有当_search菲尔德(Field)(Field)EndEditing
action爆发时才会举办埋点,收集的properties为:

(1) type 为UIControl采集的事件类型,这里设置为searchBarEvent;
(2) page 为当前页面的名称,用于前端显示用;
(3) searchText 为_searchFieldEndEditing发生时采集到搜索框的搜索文字(此字段不为空);

这样就能对搜索框举办无埋点采集,并能收集搜索的公文内容。此格局只是在_searchField(Field)EndEditing爆发时募集数据,有可能该action执行时从没尽兴真正的查找操作,可能会与工作数据库的数码有出入,不过也可以相比准确的剖析用户感兴趣的寻找内容。